The Refund That Balanced the Drawer and Broke the Books
A refund reversed the sale, returned the stock and balanced the drawer perfectly. It also left cash overstated on the balance sheet by the amount refunded, and a matching phantom balance in receivables — for the life of the tenant, in silence.
The most durable accounting defects are the ones that pass the check people actually run. A till that reconciles every night for three years is not evidence of correct books. It is evidence that the till reconciliation and the books are measuring different things.
What a sale posts
A sale at this till posts two journal entries, not one. First the sale itself: a receivable is raised and revenue is recognised. Then the settlement: cash comes in and the receivable is cleared.
That two-step is correct and it is how it should be done, because a sale and its payment are genuinely two events even when they happen a second apart. It also means a refund has two entries to reverse.
The refund reversed one.
A refund of 1,000, before the fix
The last row is the reason this survived. Every control a shop runs daily passed, and the one that would have failed is run yearly by somebody else.
The till always reconciled — which is precisely why the defect could run undetected for the life of a tenant.
The earlier half of the same story
Three days before that was found, a related defect was fixed: a return refunded the customer and put the stock back on the shelf, and the original revenue and cost of sales stayed on the books permanently.
So the trial balance overstated both revenue and cost of sales, for the entire life of the tenant, by the total of every return ever processed. The margin percentage happened to stay roughly plausible, because both sides were inflated together — which is the kind of coincidence that keeps a defect alive.
The detail that makes the fix correct rather than merely present
The return now reverses both legs — revenue and cost — but the cost leg is conditional on whether the goods actually came back.
Goods returned to stock return their value to inventory, so reversing the cost is right. Goods written off as damaged do not: the cost has genuinely been consumed and only the revenue should reverse. Treating those two identically would have replaced one wrong number with a different wrong number.
Returned to stock
- Revenue reverses
- Cost of sales reverses
- Inventory value increases
- The unit is sellable again
Written off as damaged
- Revenue reverses
- Cost of sales stays consumed
- Inventory value unchanged
- The loss lands in the right period
Our position
Both defects are fixed and both are published with their evidence, because the class of error matters more than either instance. If you run a till that posts to a ledger — ours or anyone's — reconcile the till to the cash account monthly rather than trusting that a balanced drawer implies balanced books. The two can disagree for years without either one looking wrong.
What AWRA OpsHub does today
- Two journal entries per sale — the sale and its settlement — which is the correct treatment.
- A return that reverses both, including the settlement leg, so cash is no longer overstated.
- A cost-of-sales reversal conditional on whether the goods came back to stock, so a damaged write-off leaves the cost consumed.
- One cost basis shared by till margin analytics, stock valuation and the accounting integrity check, after those three had disagreed.
- An internal integrity screen comparing the ledger against stock, open orders, debits against credits, and the general ledger against the payments register.
What it does not do
- Bank reconciliation. No statement import, no feed, no auto-matching, no reconciliation record — the integrity screen is a different thing and is not a substitute.
- Manual journal entries, so a correcting entry cannot be posted by a person.
- Any dimension on a journal entry — no branch, department or project — so the trial balance cannot be sliced.
- A period posting lock. A closed month is recorded as closed and does not bar movement.
- Any automated check that a new posting path has a matching reversal path.
Not ours, by choice
- Both defects described here were live and both are fixed. We publish them with file references because a vendor who has never found one of these has not looked.
- The absence of manual journal entries is the single clearest reason this ledger is not a statutory book of account, and it is stated that way in the gap file rather than softened.
- Nothing here is Fijian. Fiji is here as a small-market retail context where the same system typically runs the counter and the books, which is exactly the arrangement that makes this class of defect expensive.
What is not built for Fiji 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 Fiji. 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 tax rate with a date on it, a credit note that carries tax, a Fijian payroll engine, 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.
Rates that know which date they belong to
Two builds, and the smaller one is the one that costs a real business real time. A credit note that carries lines and a tax rate, defaulting from the invoice being credited, so a credit reversing a supply taxed at 9% records that rather than leaving it in a journal narrative — today our credit note is a single amount with no tax columns at all. Then effective-dated rates: a rate history per country rather than one rate per country, so "what was the rate on this date" is a question the system can answer. That second one is a genuine data-model change, every consumer resolves a country to exactly one profile today, and we would rather quote it honestly than bolt a date onto a config file and call it done.
Fiscalisation data, banks and payments
Sales data produced in the format the Revenue and Customs Service's monitoring system expects, alongside the approved equipment you already have rather than in place of it — the approval attaches to certified equipment and is the Service's to grant, not something a web application can claim. Plus bank feeds and local payment rails wired into the Payments Register.
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
A Fijian payroll engine with income tax tables and provident fund contributions computed on live employee records, producing the returns in the layout the authority expects rather than rebuilt each month in a spreadsheet.
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 integratedFour questions about refunds and the ledger
How many journal entries does one sale post?
A good answer sounds like
Two — the sale and the settlement.
What it actually means
If the answer is one, ask what happens to the receivable. If it is two, ask the next question.
Does a refund reverse both of them?
A good answer sounds like
Yes, and they can show it.
What it actually means
The exact question that found ours. It is answerable in one screen and almost nobody asks it.
Does a damaged return reverse cost of sales?
A good answer sounds like
No — only a restocked one does.
What it actually means
A vendor who treats these identically has one of two wrong numbers, and does not know which.
What would tell me if the till and the ledger disagreed?
A good answer sounds like
A named report, run monthly.
What it actually means
The drawer reconciliation is not that report. Ours could not have caught either defect on this page.
Reconcile the till to the cash account
Not the drawer to itself — the till's cash total to the cash account in the ledger, monthly. It is the one check that finds this class of defect, and it takes ten minutes.
Talk about till and ledger integrityFrequently asked questions
How were these found?
By reading the posting paths line by line while auditing a module for blog copy, rather than by a report or a customer complaint. Neither produced a symptom anybody would have reported, which is the whole point of the page.
Do I need to correct historic data?
If a tenant processed refunds before the fixes, the historic entries are as described and correcting them is a data exercise rather than an upgrade. That is a conversation to have specifically, with the figures in front of you.
Is there a report that would have caught this?
The internal integrity screen compares the general ledger against the payments register, which is the closest thing, and it is exactly why that comparison exists. The daily drawer reconciliation would never have caught it, and that is the check most shops actually run.
