What a Refund Has to Undo
A refund at the till has to undo four things: the money, the stock, the revenue and the cost of sales. For a long time this product undid two of them and the drawer still balanced every night — which is precisely why nobody found it.
Handing money back across a counter is the simplest transaction in retail and the one with the most moving parts underneath it. Four things have to move, in opposite directions to the sale, and three of them are invisible to everybody in the shop.
The four reversals
The money. The customer gets it back, and the till records a negative payment. Everybody sees this one.
The stock. The goods come back onto the shelf, or they do not — a return can be restocked or written off as damaged, and that is a decision at the counter.
The revenue. The sale is no longer a sale. The income recorded at the time has to come off.
The cost of sales. The value that left inventory when the goods were sold has to go back — but only if the goods actually came back. A return written off as damaged has consumed its cost; only the revenue reverses.
That last conditional is the detail that separates a correct implementation from a plausible one, and it is now handled: the cost leg is reversed only where the item is restocked.
Four reversals. The shop can see one of them.
What was wrong, and why it survived
For a long period, a return refunded the customer and returned the stock, and the revenue and cost of sales stayed on the books. Permanently. Every refund ever given left both figures overstated for the life of the organisation.
And then, after that was fixed, a second and narrower defect: a counter sale posts two journal entries — one raising a receivable against revenue, one settling it with cash — and the return reversed only the first. So cash and bank were overstated by every refund, and receivables carried an equal phantom credit that never went away.
Both are fixed. The reason to publish them rather than quietly move on is the thing they have in common.
The till always reconciled. The negative payment row is written either way, so the drawer balanced at the end of every shift, every day, for years. The one check anybody in the shop performs was passing while the accounts were quietly wrong.
That is the transferable lesson, and it applies to any system you are evaluating: a reconciliation that passes tells you the thing it checks is consistent. It tells you nothing about the three things it does not check.
The third one, which was a different shape
Store credit was offered as a refund method at the till. It appeared in the interface and it was accepted by validation on both the web and the API.
It produced nothing. No payment record, no movement on the customer's balance, no obligation of any kind. The revenue reversed, the stock went back on the shelf, and the amount the shop owed the customer survived only in that customer's memory.
It could not even have been redeemed, because store credit was not an accepted tender on a sale — only on a refund. A one-way door into nothing.
Also fixed. And it is the clearest example we have of a category of defect worth naming: an option in a dropdown is a promise, and a promise nobody implemented is worse than an option nobody offered.
Why a small retail economy is where this hides longest
Because in a shop where the owner counts the drawer personally every evening, the drawer is the audit. It is checked more often and more carefully than any report, and when it balances the day is closed.
That is a genuinely good control, and it is complete for what it covers. What it cannot cover is the ledger, and the ledger is where three of the four reversals live.
So the practical advice is not to distrust the drawer. It is to add one more check that the drawer cannot perform.
Three checks a shop can actually run
- Compare monthly refunds to the movement in revenue. Total refunds for the month against the reduction in recorded sales. They should relate; if refunds are rising and revenue is not falling, something is not reversing.
- Watch for a receivables balance that should not exist. A counter business selling for cash should not accumulate receivables. A creeping balance there is the signature of a settlement leg that is not being reversed.
- Check that restocked returns actually restocked. The decision at the counter drives whether stock and cost come back. A month of returns with no corresponding stock movement is a process problem, not an accounting one.
Three questions about returns in any point-of-sale system
Show me every journal entry a refund produces.
A good answer sounds like
Reversals of revenue, of cost, and of the cash settlement.
What it actually means
Ask for the entries, not the receipt. This exact question is what would have found both defects on this page years earlier.
What happens differently when a return is not restocked?
A good answer sounds like
Revenue reverses, cost does not.
What it actually means
A system that reverses both regardless is putting value back into inventory that is physically in a bin.
Which refund tenders are actually implemented?
A good answer sounds like
A list shorter than the dropdown, honestly given.
What it actually means
Store credit was in ours and did nothing. Check every option in the list, not just the ones you plan to use.
What AWRA OpsHub does today
- Returns at the till reversing revenue and, where the goods are restocked, cost of sales.
- The cost reversal conditional on restocking, so a damaged return reverses revenue only.
- The cash settlement leg reversed as well as the revenue leg, so cash and receivables are not left overstated.
- A negative payment record on the session, so the drawer reconciles correctly.
- Store credit implemented as a real tender rather than an option that produced nothing.
- Cash sessions with expected and counted cash and a stored variance.
What it does not do
- Any approval or threshold on a refund at the till.
- A reason code on a return, so the difference between damaged, wrong item and changed mind is free text or nothing.
- Any report of refunds by cashier or by reason.
- A link from a return to the original sale beyond the return record itself.
Not ours, by choice
- The two defects described here are fixed. They are published because the reason they survived — a reconciliation that passes while the ledger is wrong — is more useful than the fixes.
- The drawer reconciliation is a genuine control and it is complete for cash. It is not evidence about anything else, and it never was.
- Nothing here is specific to Eswatini. It is what a nightly drawer count can and cannot see; a small owner-managed retail economy is where the drawer is trusted most.
What is not built for Southern Africa today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Southern Africa. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a revenue authority pipeline, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax pipelines and return output
Return output in the shape your revenue authority expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Banks, EFT and card acquirers
Bank statement feeds, EFT and debit-order files and card acquirer settlements pulled into the Payments Register so receipts match invoices without re-keying.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
Payroll tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedAdd one check to your month end
Refunds against revenue movement, and a look at any receivables balance in a cash business. Five minutes, and it covers the three reversals your drawer cannot see.
Set up the checkFrequently asked questions
Do I need to do anything about the old defects?
Both are fixed going forward. Whether historical figures were affected depends on when your organisation started and how many refunds were given, and it is worth asking us directly rather than assuming either way — the answer is specific to your data.
Should a cashier be able to refund without approval?
Nothing in the product gates it, so that is a policy decision rather than a setting. In a small shop the drawer count is the control, and it works — but it only catches the money, so pair it with the monthly refund total.
What is the single most useful question to ask any vendor here?
Show me every journal entry a refund produces. Not the receipt, not the screen — the entries. Two serious defects in this product survived for a long time because nobody asked it, and the same question would find the equivalent in any system.
