The Return Counter: Refunds, Exchanges & the Credit You Can't Give
A return is the only counter transaction that runs the whole system backwards — stock, revenue, cost and cash all reverse at once. Most of that is built and enforced. One tender on the dropdown is not, and choosing it hands a customer a promise the system does not record.
A customer comes back with a shirt, a receipt and a reason. What happens next touches more of a retail system than any other transaction at the counter: one shirt goes back on the shelf, one line of revenue has to stop being revenue, the cost of that shirt has to stop being cost, and money has to leave a drawer that was balanced five minutes ago. Get any one of the four wrong and the error compounds quietly, because nobody audits refunds until the annual count disagrees with the ledger.
Most of that sequence is built here and genuinely enforced. This article walks the whole path, names what the system will refuse to let you do, and is direct about the one option on the refund screen that is a promise rather than a feature.
What a return actually is, structurally
A return is not a negative sale. It is its own record, attached to the original sale, holding its own numbered document, its own reason, its own tender and its own lines — and each line points back at the specific sale line it reverses.
That structure matters more than it sounds. Because a return line references the exact line it came from, the system can compute what is left to return on that line, and refuse anything beyond it. You cannot return three of an item that was sold in twos. You cannot return the same unit twice across two visits. That check is arithmetic on the original sale, not a warning a supervisor can wave through.
The five things one return has to do
Take a 2,400-shilling shirt, sold this morning for cash, coming back this afternoon. Here is every consequence, in order, and where each one lands.
The document
A return record with its own sequential number, a mandatory reason, the tender used to refund, the operator who processed it and the timestamp. The reason is required — you cannot process a blank return.
The stock
A restock flag, set per return. Ticked, the shirt goes back to the same warehouse and location the sale drew it from. Unticked, the shirt is gone — damaged, soiled, unsellable — and stock is unchanged.
The revenue
Reversed for the returned portion, always, whether or not the goods come back. The customer is not being charged for a shirt they no longer have.
The cost
Reversed only if the goods were restocked. A restocked shirt puts value back into inventory, so cost comes back out. A written-off shirt was genuinely consumed, so the original cost stands. This distinction is deliberate and it is the correct one.
The cash
A negative payment row against the original sale, stamped with the cash drawer session that is open at that counter — so the drawer at closing time expects less cash, by exactly the refund, without anybody adjusting a float by hand.
The restock flag is the only judgement call in the list. Everything else follows from it automatically, which is the right division of labour: the operator decides whether the goods are sellable, and the system decides what that means for four other records.
Following the money on one return
Worth doing once with real numbers, because the cost leg is where people expect a mistake and there is not one.
One honest caveat on the 1,450. The cost is reversed at the current unit cost basis, not the cost the shirt carried when it was sold, because a per-line cost is not stored on the sale. On stable costs the two are identical. On a fast-moving cost — a devaluation, a new supplier, a landed-cost run in between — they differ, and inventory comes back at today's cost rather than the cost that left. Nothing hides this; it is simply the basis available.
Refund tenders: three that work, one that does not
The refund screen offers cash, M-Pesa, card and store credit. The first three each write a negative payment against the sale, so the money leaving is recorded on the same transaction the money arrived on, and the cash one lands inside the open drawer session.
Store credit does not exist. It was on the dropdown; it wrote no payment row, touched no customer balance, and created no record anywhere of the amount owed. The revenue was reversed and the goods went back on the shelf, so the shop was out a shirt's margin and out the shirt's value, with a customer walking away holding a claim that lived only in their memory and a handwritten note. There is also no way to spend store credit at this till — a POS sale must be settled in full in cash, M-Pesa or card — so even a perfectly recorded credit would have had nowhere to go.
What changed, and what to do until it is built properly
Store credit is now refused at the point of processing rather than accepted and lost, in both the web and API paths. Refusing is not a fix for wanting store credit; it is a fix for silently manufacturing an obligation nobody can see. Until a credit balance exists that the till can also redeem, handle it the way a shop with a paper book does: refund to a real tender, or raise a customer invoice for the goods they will collect later, so the claim sits on an account with a number on it.
Refund to a real tender
- Recorded as a negative payment on the sale, visible on the sale and inside the drawer session.
- Reconciles — expected cash drops by the refund and the ledger now agrees with it.
- Proof is a numbered return document that matches what the customer actually received.
- Already settled, so nothing is owed and nothing has to be remembered.
- Right almost always, including when the customer would have preferred credit.
Promise credit for later
- Recorded nowhere, unless you raise a customer invoice or an account entry yourself.
- Does not reconcile — the drawer balances perfectly while an unrecorded liability accumulates.
- Proof is a return document that overstates what the customer was given.
- Not redeemable at this till in any case: a sale must settle in cash, M-Pesa or card.
- Only defensible if you raise the customer invoice in the same minute, so the claim has a number.
Exchanges
An exchange is modelled honestly: a return, plus a new sale, with the return holding a reference to the sale it was exchanged into. The wrong-size shirt comes back with its own document, the right-size shirt goes out on a fresh sale, and the link between them survives so a manager can see why a sale exists with no money attached to it.
This is better than a single "swap" transaction, because the two halves may not be equal. A 2,400 shirt exchanged for a 2,900 shirt is a 2,400 reversal and a 2,900 sale with 500 collected, and each half is priced, taxed and costed on its own terms. A single swap record would have had to invent an answer for the difference.
What the system refuses, and why that is the point
Four refusals, each of which prevents a category of loss that shops usually discover months later.
| Attempt | Result | The loss it prevents |
|---|---|---|
| Return more units than were sold on that line | Refused, naming the item | Refund fraud by inflating quantity on a genuine receipt |
| Return the same units twice across two visits | Refused — already-returned units are subtracted | The same goods refunded to two people, or twice to one |
| Return an item that was not on the original sale | Refused — lines must belong to this sale | A cheap receipt used to refund expensive goods |
| Restock when the sale has no warehouse | Refused, with the reason given | Stock appearing with no shelf to appear on |
| Refund to store credit | Refused (see above) | An obligation to a customer that no report can show you |
The gap worth knowing: restocking into a hold
A restocked return goes back as available stock — immediately sellable to the next customer. That is right for a wrong-size shirt in its packaging. It is wrong for anything that needs a look first.
The system does have proper holds. Stock can sit as quarantined, inspection-pending, damaged, expired or returned, and held stock genuinely cannot be issued or sold — the allocation queries filter on availability everywhere, so a hold is a wall rather than a label. What a return cannot do is place one. There is no "restock into inspection-pending" on the return screen: the choice is available, or nothing at all.
Sealed, unworn, obviously resellable
Restock and move on
Tick restock. Stock goes back as available, cost reverses into inventory, and the shelf is honest. This is the majority of returns in most shops.
Needs checking before it goes out again
Restock, then place the hold as a separate step
Tick restock so the quantity and the cost are right, then use the hold action to move that quantity to inspection-pending. Two steps, correct outcome, and a visible reason recorded against the hold. The risk is the gap between the steps — write the hold into the till procedure, not the shop's good intentions.
Damaged, soiled, unsellable
Do not restock
Leave restock unticked. Revenue reverses, cost stays consumed, and stock never lies about having a shirt it does not have. This is the correct accounting for a write-off and it needs no separate adjustment.
You are unsure and the customer is waiting
Do not restock
An item you did not restock can be received back in as a positive adjustment once you have looked at it. An item you restocked and should not have is now on somebody's shelf as sellable. Wrong in the recoverable direction.
Where the ledger was wrong, and now is not
This one was found while verifying the article and is worth stating plainly, because it affected every shop that has ever given a refund.
A POS sale posts two entries: the sale itself raises a receivable and credits revenue, and the payment then clears the receivable and debits cash. A return reversed the first of those and not the second. Revenue came off, the receivable was credited back — and the cash that physically left the drawer never left the ledger. Two consequences, both permanent and both growing: the cash and bank accounts were overstated by every refund ever given, and receivables carried a phantom credit balance of exactly the same total.
The drawer reconciliation was always right, because the negative payment row was there — which is precisely why this could run for a long time without anybody noticing. The till balanced. The trial balance did not. The settlement leg is now posted on cash, M-Pesa and card refunds, mirroring the sale.
A refund that reconciles at the till and not in the ledger is the most patient kind of error. Nothing looks wrong at closing time, every night, for years.
What we do and do not do
What AWRA OpsHub does today
- Returns against the original sale, line by line, with quantities capped at what remains returnable — enforced, not advisory.
- A required reason, a sequential return number, the processing operator and timestamp on every return.
- Restock to the sale's own warehouse and location, following the same allocation rules as any other receipt.
- Revenue reversed for the returned portion, and cost reversed only when the goods came back — the write-off case is handled correctly.
- The refund lands in the open drawer session as a negative payment, so expected cash at close drops by the refund automatically.
- Exchanges linked — the return carries a reference to the replacement sale.
- The settlement leg now posts to the ledger on cash, M-Pesa and card refunds.
What it does not do
- No store credit. There is no customer credit balance, and the till cannot accept one as a tender. The option is now refused rather than silently discarded.
- No restock into a hold status. Returned goods come back as available. Holds exist and are enforced, but placing one is a separate action after the fact.
- Cost reverses at the current basis, not the cost the goods carried when sold — no per-line cost is stored on a sale.
- A POS return never reaches a customer statement, because a POS sale never does either. Statements are built from invoices and payments.
- No approval threshold on refunds. Any operator who can process a sale can process a return, of any value, with no second signature.
- No refund reason analysis report. Reasons are captured as free text per return, so grouping them is an export-and-pivot job.
The two that would change how you write your till procedure are the missing refund approval and the restock-to-available default. Both are procedural gaps you can close with a rule and a supervisor, and both are worth closing before you hand the return screen to a new cashier.
A till procedure that fits what is built
- Refunds above a value you set require a supervisor present — the system will not ask, so the rule lives on the wall behind the counter.
- The reason field gets a real reason, from a short list you agree in advance, so an export can be grouped later.
- Restock is ticked only for goods you would put out again today, unexamined.
- Anything needing a look is restocked and then held to inspection-pending in the same minute, by the same person.
- Anything unsellable is not restocked — never restocked-then-written-off, which double-counts the movement.
- Store credit is not offered verbally at the counter. If you intend to give it, raise a customer invoice so the claim has a number.
- Cash refunds happen only at a counter with an open drawer, so the refund lands in a session that will be counted.
- The day's returns are reviewed against the day's sales by someone who did not process them.
Related reading
- Float, drops and the drawer that will not hand over — where a cash refund actually lands, and the shift-change problem behind it.
- How to stop stock shrinkage in Kenyan retail — returns fraud is one of the five faces, and this is the counting discipline that catches it.
- Counting the shop without closing it — the count that would eventually expose a restock flag used carelessly.
- Returns and credit notes: three records, one event — the invoice-desk equivalent, where a credit note carries an amount and no lines at all.
See the counter, the drawer and the returns path
Sales, returns with restock control, cash sessions with float, drops and variance, and per-counter reporting — with the honest edges named above.
Explore point of saleFrequently asked questions
Can a cashier refund more than the customer originally bought?
No. Each return line points at the specific sale line it reverses, and the returnable quantity is the units sold on that line minus the units already returned across every earlier visit. Anything above that is refused, with the item named in the error. This is arithmetic on the original sale rather than a warning, so it cannot be waved through at the counter.
What happens if we choose store credit as the refund tender?
It is now refused. Previously it was accepted and produced nothing: no payment row, no customer balance, no record of the obligation — the revenue reversed and the goods went back on the shelf while the customer left holding a claim the system had never heard of. There is also no store-credit tender on a sale, so the credit could never have been spent. If you want to give credit, raise a customer invoice for the goods to be collected later so the claim has a document number.
Does a return put the stock back automatically?
Only if you tick restock. Ticked, the quantity returns to the warehouse and location the original sale drew from, and the cost of those goods comes back out of cost of sales into inventory. Unticked — damaged or unsellable goods — revenue still reverses but the cost stays consumed and stock is unchanged, which is the correct treatment for a write-off and needs no extra adjustment.
Can returned goods be held for inspection instead of going straight back on sale?
Not from the return screen. A restocked return comes back as available and immediately sellable. The system does have real holds — quarantined, inspection-pending, damaged, expired, returned — and held stock genuinely cannot be sold or issued, but placing the hold is a separate action taken after the restock. Build it into the till procedure as one two-step task, because nothing prompts for it.
Does a cash refund affect what the drawer should hold at closing time?
Yes, automatically. The refund writes a negative payment stamped with the drawer session open at that counter, and expected cash is computed as the opening float plus cash sales minus cash drops — where cash sales are net of refunds. Nobody adjusts a float by hand. Cash refunds do require an open drawer at that counter, for exactly this reason.
Is there any approval required before a large refund?
No. Any user who can process a sale can process a return of any value, and no second signature is requested or recorded beyond the operator who processed it. This is a genuine control gap for a shop with several cashiers. Set a value threshold as a written rule and review the day's returns against the day's sales with someone who did not process them.
Do returns show up on a customer statement?
No, and neither do the sales they reverse. Statements are built from customer invoices and payments received, so counter transactions of any kind sit outside them. A customer who buys at the till and a customer who is invoiced on account are two different pictures in this system, and a shop doing both should expect to reconcile them by hand.
