Promotional Pricing vs. Coupons

Arcus gives you two ways to run a deal, and they are deliberately different mechanisms. Picking the right one keeps your margins, invoices, and customer-facing documents correct. They are not duplicates of each other, and they can be used together.

​

At a glance

​

Promotional pricing — changes the unit price

A promotional price lives on the product’s Pricing Policy. When you set one, the pricing engine picks that price for the product at the matching scope (pricing level, attached account, variant, or quantity break) while the promotion is active. Use a promotional price when you want to:

• Drop the price of one product (or one variant, or one customer tier) for a limited time.
• Have the lower price flow straight into margin, the order line, and PDFs without showing a separate discount line to the customer.
• Cap how many times the promo can be used, or run it only between two dates.

The promotion automatically stops applying when its end date passes or its max-uses count is reached — a daily sweeper deactivates expired promos, and each use is burned atomically so you never oversell a limited promo.

​

Coupons — add a discount or fee line

A coupon lives under Settings > Adjustments & Coupons. It adds an adjustment line to the order rather than changing any product’s unit price. Use a coupon when you want to:

• Give the customer a code to enter (or auto-apply a discount when conditions are met).
• Discount the whole order, or a set of products or categories.
• Add a fee (handling, small-order surcharge) as a visible line.
• Set minimum order value or quantity requirements, restrict to first orders, or limit to certain channels, delivery methods, or customer tiers.
• Control stacking — whether multiple coupons can combine, and up to how many.
• Route the discount to a specific GL account. By default a coupon’s discount posts to Sales Discounts (4200). Under a coupon’s Advanced options you can point it at a different account instead — useful for classifying give-aways separately from ordinary promotions, e.g. a “Sample Items” coupon mapped to a Samples Expense account for vendor samples shipped to customers. This is an accounting classification only; it never changes how the coupon evaluates, stacks, or applies.

​

How they stack

Promotional pricing and coupons stack, in a defined order:

1. Promotional price first. The pricing engine resolves each line’s unit price, applying any active promotional price.
2. Coupon second. Coupons then discount the order on top of those already-promotional line prices.

Because the order total is rebuilt as subtotal + adjustments + shipping + tax, the promotional price is already baked into the subtotal, and the coupon’s discount is applied once on top. The math reconciles exactly — there is no double-discount and no double-count, even for a product-scoped coupon stacked on a promotional price.

​

Which one should I use?

• “I want this product cheaper for a while, no code, customer just sees a lower price.” -> Promotional price on the product’s Pricing Policy.
• “I want to hand out a code, or auto-apply an order discount, with a visible discount line.” -> Coupon under Settings > Adjustments & Coupons.
• “I want both” -> Set the promotional price on the product and create the coupon. They combine in the order above.

​

Return fees ride the same rules

A return fee (restocking, handling, processing, or a return-shipping deduction) is configured in the same builder: create a Fee rule and set Applies to: Returns. The rule can scope to specific products or categories exactly like a discount, and it is deducted from the customer’s refund when an RMA includes an in-scope item. Return-fee rules carry four extra controls:

• Fee type routes the fee to its own income account (restocking / handling / processing / shipping deduction).
• Fee taxable posts sales tax on the fee itself when your jurisdiction requires it (most do not); “Inherit” uses your entity’s Returns settings.
• Minimum / Maximum fee ($) cap the resolved dollar amount per rule, on top of your entity-wide restocking guardrails.
• Waive on merchant-fault returns (on by default) resolves the fee to $0 with a disclosure when the return reason is defective, damaged in transit, wrong item shipped, or not as described.

Rules with auto-apply resolve on every eligible RMA automatically; rules without auto-apply appear in the RMA fee editor’s “Add saved return-fee rule” picker so your team applies them case by case. A rule that applies to Returns never touches an order, and an order rule never touches a return.