Design the returns flow properly, from the customer pressing the button to the money and the stock landing back where they belong.

A return is an order, not a flag

The design mistake that causes everything downstream is representing a return as state on the original order - a returned boolean, or a quantity column that gets decremented. It cannot hold the facts. One order line can be returned in two separate consignments weeks apart, one of which is restocked and one written off; the refund for one may be to the original card and for the other to store credit; and both need their own timestamps, their own carrier tracking and their own inspection notes.

So a return is its own entity, referencing the order lines it covers, with its own lines, quantities, reason codes, financial outcome and lifecycle. It has a status machine of its own: requested, authorised, in transit, received, inspected, resolved, or expired when the customer never sends it. The original order stays immutable, which is what lets you answer "what did we sell in March" without the answer changing every time someone posts a parcel.

Authorisation is where policy lives, and it should be explicit

Return authorisation is the gate where policy is applied once, in one place, rather than reimplemented in the app, the website and the contact centre. The checks are unglamorous and all of them matter: is the item within its return window, measured from delivery rather than from order; is the category returnable at all, since perishables, personalised goods and opened hygiene products usually are not; is the quantity requested actually within what was delivered and not already covered by an earlier return; and does this customer's return history warrant review.

Authorisation also produces a plan, not just a yes. It fixes the return method - carrier collection, drop-off, in-store, or keep-the-item where the goods are worth less than the freight - and it decides who pays the transport. That last decision follows the reason: a faulty or wrongly-sent item is your cost, a change of mind is conventionally the customer's, and which of those applies is a claim by the customer at request time that inspection may later contradict.

Consumer law sets a floor here in many jurisdictions, and the floor is not your policy. In the EU and UK, distance selling gives a statutory withdrawal right with its own window and its own rules about refunding the original outbound delivery charge, whatever your marketing page promises. Keep the statutory minimum and the commercial policy as separate inputs, because the commercial one changes every peak season and the statutory one must not be editable by a merchandiser.

Refund before or after the goods arrive

This is the genuine trade in the question and it does not have a single correct answer, so the strong response is to describe the positions and the conditions that select between them.

Refunding on receipt, meaning when the goods are physically scanned into the returns centre, keeps your exposure low and is the conservative default. Its cost is the customer's experience: she has posted the item, she has no money, and the parcel spends days in transit and more days in a queue at the returns dock. That wait is a leading driver of "where is my refund" contacts, which are expensive and repeat.

Refunding on carrier acceptance, meaning when the return is first scanned into the network, cuts that wait substantially at the price of a window in which you have refunded goods you have not inspected. Refunding on request, before anything moves, is the most generous position and is defensible for low-value items where the freight exceeds the goods, or for high-value customers where the lifetime value dwarfs the exposure.

The workable design is not one policy but a policy per segment, with the exposure measured. Fast refunds for trusted customers and low-value goods, receipt-based refunds for high-value items and for accounts with an abnormal return pattern, and a monitored figure for value refunded but never received. If that figure is not on someone's dashboard, you are not running a policy, you are running an assumption.

Inspection decides disposition, and disposition decides the money

The unit arriving back is not inventory yet. Inspection assigns a disposition, and the branches lead to different financial outcomes, so this step cannot be skipped for operational convenience.

Disposition	What happens to the unit	Financial effect
Restock as new	Back into sellable stock at the same location	Inventory value restored in full
Restock as open-box	Sellable at a reduced price, often a separate variant	Restored at a written-down value
Repair or refurbish	Held in a work-in-progress location	Cost of repair added before resale
Return to vendor	Shipped back under supplier terms	Recovery claimed from the supplier
Scrap	Destroyed or recycled	Written off entirely

Two things follow. Restocking must be an explicit event that increases on-hand at a named location, not a side effect of the refund, because the two happen at different times and sometimes only one of them happens at all. And the reason the customer gave and the reason the inspector recorded are different data, both worth keeping: a spike in "not as described" that inspection classes as undamaged points at your product page, not at your supplier.

The refund amount is where partial returns go wrong

Here is the specific thing that separates a returns design that reconciles from one that quietly leaks money. Refunds are computed from the list price of the returned line, and that is wrong whenever anything was applied at order level.

Consider an order of three items totalling 100, with a 20 percent order-level voucher, so the customer paid 80 plus delivery. She returns one item listed at 40. Refunding 40 hands back more than she paid for that item, and doing this at scale is a margin leak nobody attributes to the returns system because each individual refund looks correct. Refunding 32 is right, but only if the apportionment was recorded at the time of sale.

The rule is that every order-level amount - percentage vouchers, fixed-value discounts, delivery charges, loyalty redemption, tax - is apportioned to lines when the order is placed and stored on the line as the paid amount. Refunds then read that stored figure. Doing the apportionment at refund time instead means recomputing against a promotion that may have expired, changed or been deleted, which is how two partial returns of the same order end up refunding more than the order was worth.

The related case is a conditional promotion whose condition the return breaks. Return one item from a buy-two-get-one-free set and the remaining two no longer qualify for anything, so the correct refund may be zero or even a rebalancing of what the retained items cost. There is no automatic answer; what there must be is a decision recorded per promotion type at the time it is created, because working it out during a support call guarantees inconsistency.

The accounting has to sit in the right period

The last piece, and the one engineers most often leave to finance, is that a return crossing a reporting boundary cannot be handled by reversing the original sale. The sale happened in March, the return happens in April, and rewriting March is not available.

What happens instead is that expected returns are provided for at the point of sale. Under IFRS 15 and its US equivalent, revenue is recognised only for the goods you expect to keep, with a refund liability for the portion you expect back and a corresponding asset for the goods you expect to recover. The actual return then settles against that liability rather than restating revenue. The engineering consequence is that your system owes finance two things it will not ask for until year end: a return rate per category good enough to size the provision, and a clean link from each refund to the original sale.

Refunds must be paid from the apportioned amount stored on the line at the time of sale, never recomputed from a promotion that may since have changed. Everything else in a returns design is recoverable; a refund arithmetic error is a leak that reconciles perfectly line by line and never in total.