Returns & Exchanges at the Counter: Reasons, Restocking & the Refund Trail
Returns are where retail policy meets retail reality, usually with a queue forming behind. The four decisions every return contains, why restocking must be a deliberate choice rather than an automatic one, and how to keep refunds from silently becoming till shortages.
A customer comes back with an item and a story. The cashier looks for a supervisor, the supervisor is with a delivery, the queue lengthens, and eventually somebody hands back cash and puts the item on the shelf. Nothing is written down beyond the cash movement, and by evening the till is short by an amount nobody can explain and the stock figure is wrong by one unit.
Every part of that is fixable, and none of the fixes are about being stricter with customers. Returns go wrong because four separate decisions get collapsed into one hurried moment, and because the outcome is recorded as a cash event rather than as a return.
Four decisions, not one
Whether the return is accepted is only the first question, and it is the one everyone focuses on. The other three determine whether your records survive the transaction.
| Decision | The question | What goes wrong when it is implicit |
|---|---|---|
| Accept | Do we take it back at all, and against which original sale? | A return with no original sale is indistinguishable from goods appearing from nowhere |
| Reason | Faulty, wrong item, changed mind, expired, damaged in transit? | Without reasons you can never tell a supplier quality problem from a sales-floor problem |
| Refund | Cash, reversal to the original tender, credit note, or exchange? | Cash refunds against card or mobile-money sales quietly drain the drawer |
| Restock | Does this go back on the shelf, or is it written off? | Automatic restocking puts damaged and expired goods back into saleable stock |
The restock decision is the one most systems get wrong by making it automatic. A returned item is not automatically resaleable — an opened medicine, a spoiled food item, a garment that has been worn, a device with a cracked screen. If the system puts every return back into stock as a matter of course, your stock figure inflates with goods you cannot sell and the write-off happens months later at a stocktake, attributed to shrinkage.
A returned item is not automatically saleable stock. Systems that restock every return silently convert damaged goods into inventory, and the write-off eventually shows up as shrinkage nobody can explain.
The return must know its original sale
This is the structural requirement everything else rests on. A return recorded against the original sale inherits the price actually paid, the tender used, the items on that receipt and the date — which answers, without argument, the four questions a return dispute usually contains.
A standalone refund with no linked sale answers none of them. It cannot prove the item was bought here, cannot establish what was actually paid for it after a discount, and cannot tell you whether it is inside your returns window. It is also the shape that abuse takes, in every retail business, everywhere: refunds for goods that were never sold.
In AWRA OpsHub a return carries its own return number and is created against the original sale, with the reason, the refund tender, the restock decision, an optional linked exchange sale, who processed it and when. Partial returns are supported and the original sale's return state is updated, so a receipt that has been half-returned is visibly that rather than looking untouched.
Exchanges are two transactions wearing a coat
An exchange feels like a single event to the customer and to the cashier, which is exactly why it is the most commonly mis-recorded transaction in retail. Structurally it is a return plus a new sale, and the two need to exist as records even though they happen in one conversation.
-
Record the return against the original sale
With its reason and its restock decision. The returned item has its own fate, which is frequently different from the fate of the replacement.
-
Record the replacement as a sale
At its own price, moving its own stock. This is what keeps both stock figures and both margins correct.
-
Link the two
The return carries the exchange sale reference, so the pair reads as one event when anybody reviews it later.
-
Settle only the difference in cash
The customer pays or receives the gap. Recording it as one net transaction is what destroys the stock movement on both items.
Why the shortcut is tempting and wrong
The shortcut — record nothing, swap the items, take the difference — leaves both items with wrong stock figures and produces a cash movement with no transaction behind it. It takes ten seconds less at the counter and costs an unexplainable variance the same evening.
Refunds and the till
A cash refund reduces the cash in the drawer without reducing sales, which means an unrecorded refund reads at close as a shortage of exactly that amount. This is the single most common cause of a manufactured accusation against a cashier.
The same shift, recorded and unrecorded
Illustrative, in KES. Nobody did anything wrong here. A refund was given, correctly, and not recorded as a return — so the shift closes short by exactly the refunded amount and the conversation becomes an accusation. Recording returns properly is a till-integrity control as much as a stock one. The full close is covered in POS shift reconciliation.
The second issue is tender. Refunding cash against a sale paid by card or mobile money moves real money out of the drawer against a receipt that never put money in it. It is sometimes commercially necessary, but it should be a deliberate, recorded exception rather than the default — which is why the refund tender is captured on the return rather than assumed.
A policy your staff can actually apply
Most returns policies fail not because they are too generous or too strict, but because they are unusable at a counter with a queue. A policy is only real if a cashier can apply it alone in twenty seconds.
- Name the window in days and put it on the receipt. Arguments about "how long ago" end instantly when the date is printed.
- List the categories that are never returnable — opened medicines, perishables, underwear, cut lengths — visibly at the counter.
- Say who may authorise an exception, and make sure that person is reachable during trading hours. An escalation path to someone who is out is not a policy.
- Standardise the reasons. Five or six is plenty, and consistent reasons are what make the monthly pattern readable.
- Set a rule for refund tender — reversal to the original tender by default, cash by exception, recorded either way.
The reason codes deserve the extra minute. Returns coded consistently for three months tell you things nothing else will: which supplier's goods fail, which item is being oversold by staff who do not understand it, which line has a sizing problem. Returns coded as "customer returned it" tell you nothing at all, forever.
What we do and do not do
What AWRA OpsHub does today
- Returns created against the original sale, each with its own return number.
- A reason, a refund tender and a restock decision captured on every return.
- Exchange support — the return can reference the replacement sale, so the pair reads as one event.
- Partial returns, with the original sale's return state updated so a half-returned receipt is visibly that.
- Restocking that respects the warehouse behind the sale, so returned goods land where they came from.
- Who processed it and when, recorded on the return, and the refund visible in the shift reconciliation rather than as an unexplained shortage.
What it does not do
- No enforced returns window. The system does not refuse a return because the sale is 90 days old — your policy is applied by people, not by the till.
- No approval gate on refunds. A refund is attributable after the fact; requiring supervisor authorisation beforehand is a supervisory practice.
- No automatic supplier claim. A return coded as a supplier defect does not raise anything against the supplier; that remains a procurement conversation.
- No customer returns history check at the counter. Nothing warns a cashier that this customer has returned nine items this month.
The last two are where a bigger retailer will want more. Both are visible in the data after the fact — the reason codes and the customer link are recorded — so the analysis is available even though the intervention at the counter is not.
Our take
Record every return against its original sale, make restocking an explicit decision rather than a default, and standardise five or six reason codes. Those three habits protect your stock figure, remove manufactured till variances, and hand you a monthly readout of which suppliers and which lines are actually causing the returns.
See returns and shift reconciliation
Returns linked to the original sale with reason, tender, restock decision and exchange support — and refunds that show as cash out rather than as a shortage.
Explore shift reconciliationFrequently asked questions
Can we stop the system accepting a return outside our policy window?
No — there is no enforced returns window, so a return against an old sale will process. Your policy is applied by people, which means it has to be written where they can see it and short enough to apply in twenty seconds. Put the window on the receipt: most disputes about timing end the moment the customer and the cashier are looking at the same printed date.
Should returned goods automatically go back into stock?
No, and this is the decision worth being deliberate about. Restocking is captured per return precisely because a returned item is not automatically saleable — opened medicines, perishables, worn garments and damaged devices should be written off rather than shelved. Systems that restock everything inflate your stock figure with unsaleable goods and defer the write-off to a stocktake, where it gets recorded as shrinkage and blamed on nobody in particular.
How should we handle an exchange?
As two records in one conversation: a return against the original sale, and a new sale for the replacement, with the return referencing the exchange sale so the pair reads as one event. Settle only the price difference in cash. The tempting shortcut — swap the items and take the difference without recording anything — leaves both stock figures wrong and produces a cash movement with no transaction behind it.
A customer paid by M-Pesa and wants cash back. Is that a problem?
It is a decision rather than a problem, and it should be recorded as one. Cash out of the drawer against a sale that never put cash in it will show at close, so the refund tender is captured on the return to make the movement explainable. Set a default — reversal to the original tender where practical — and treat cash refunds on non-cash sales as an exception somebody authorises, because it is also the pattern most open to abuse.
What is the value of return reason codes?
Three months of consistent coding tells you what no single return ever could: which supplier's goods fail, which item staff are overselling because they do not understand it, which line has a sizing or labelling problem. Five or six reasons is plenty — more than that and cashiers pick whichever appears first. The discipline costs a second per return and turns returns from a cost you absorb into a diagnostic you read monthly.
