Name the till difference and report it
Steps 6 and 7 of the end-of-shift count: the count and the expected figure differ, and you need to say why. You work down four possible causes, cheapest first, then report the difference with its evidence instead of correcting a bill to make it agree. It follows Steps 2 to 5, where you counted and worked out what you expected. The common mistakes for the whole shift are on the front page. The running example is a Saturday on the counter at GS-KV-01: a RM 500.00 float, a RM 285.00 card sale rung up as cash, a RM 129.00 cash refund and a RM 218.00 cash sale still waiting offline; Meet GadgetSphere sets it out.
- Step 6: name which of four things the difference is, before you call it a shortage.
- Step 7: report the difference — never quietly correct it.
Step 6: Name which of four things the difference is, before you call it a shortage
A drawer that does not agree is a question, not a number. There are four answers and they need four different actions. Work down the list — the cheap ones first — and expect more than one of them on the same night. Tonight’s RM 71.50 is three of them added together.
1 — A tender was keyed to the wrong method. Somebody paid by card and it was rung up as cash, or an e-wallet went in as cash. The drawer is then short by exactly that amount and the day’s total is perfectly correct.
How you find it: the Z Report’s takings block gives you cash, card and each e-wallet separately, so the mistake shows up as two equal and opposite errors. Tonight’s power bank makes the report’s Cash row RM 285.00 too high and its card row RM 285.00 too low — so your drawer is RM 285.00 short against a report that is itself wrong. The check that proves it is the card terminal’s own settlement total for the day: it says RM 285.00 more than the Z Report’s card row, and that settles it. It is not money.
Who fixes it: a supervisor, using Settlement Adjustment on that bill — it needs both the setting and the permission, so a cashier cannot do it and should not try. It rewrites the journal and the cashbook on the bill’s original date, so tell whoever reconciles the bank before it is done. The corrected payment keeps the bill’s session, so the next run of your Z Report moves the RM 285.00 from Cash to Card.
2 — A document the report does not have. Either goods went back over the counter and the paperwork did not, or a bill exists and has not reached BigLedger yet.
How you find it: for refunds and voids, the Z Report carries a void count, and the Cash Bill Listing
filtered to today and status VOID gives you the bills themselves. Count the voids you remember against the
voids on the report. A refund handed over in cash with no document is money out of the drawer with nothing
to show for it, and it looks exactly like theft on paper. Tonight’s earbuds are the opposite case: the
refund has its own bill, so it is already inside the Cash row as minus RM 129.00 and accounts for nothing
in the difference. That is what a recorded refund buys you. Two things decide whether you get it. A bill
that only takes goods back is accepted at the till only where POS_ALLOW_SALES_RETURN_HIGHER_THAN_SALES is
switched on. And a refund recorded in the back office instead — a Sales Return or a Sales Refund Note, paid
out of this drawer — is not a cash bill, so this Z Report never counts it, and the drawer is short by it
until somebody writes it on the slip.
For a bill still in the till’s offline queue, the drawer is over by that bill — the cash is in your hand and the report has never heard of it. Tonight’s RM 218.00 sale is exactly that. When the till reconnects it sends the queued bills by itself, oldest first, and nobody has to press anything. A bill that never reached BigLedger before keeps the date you rang it up, so tomorrow’s re-run of tonight’s report includes it. A bill BigLedger already held as a draft — the connection dropped half-way through the sale — is re-dated to the day it is sent, so it lands on tomorrow’s report and in tomorrow’s accounts, and tomorrow’s drawer looks RM 218.00 short for money that was counted tonight. Write the bill number and amount on your count slip either way, and whoever checks tomorrow can tell which happened.
3 — A change error. Somebody handed back RM 50 instead of RM 5.
How you find it: not from the drawer’s figures. The till keeps what you keyed as received and the change it worked out, on each bill — but that is the change it told you to give. What actually went across the counter is not a fact any system holds. So the receipt will say Change RM 5.00 whether you gave RM 5 or RM 50. What you have is the bill, the time, and the customer. This is why a difference that is not a round number, and not matched by an opposite difference on another tender, is usually this one — tonight, the last RM 4.50.
4 — A genuine shortage. Everything else has been eliminated and the money is not there.
At that point the job is not to fix it. It is to report it, with the evidence you have already collected: the exported Z Report, the printed count slip, your cash-out slips, and which of the three causes above you ruled out and how.
Tonight’s arithmetic, written on the slip before you leave:
| Part of the difference | Kind | Evidence |
|---|---|---|
| −RM 285.00 | 1 — card keyed as cash | Card terminal settlement total RM 285.00 above the card row; the bill number |
| +RM 218.00 | 2 — offline bill not yet in BigLedger | The bill number from the till’s queue and the time it was rung up |
| −RM 4.50 | 3 — change error, most likely | Not round and matched by nothing; no proof possible |
| −RM 71.50 | Nothing left over, so no genuine shortage |
Step 7: Report the difference — never quietly correct it
This is the rule that protects the person who found the difference, and it is worth stating plainly because the product only half-enforces it.
A cashier does not adjust a bill to make a drawer agree. The two things that would change a day’s figures — Settlement Adjustment and VOID — are both permission-gated, which is BigLedger’s own way of saying they belong to somebody else. If a cashier holds them, that is a configuration decision your branch made, and it should be undone.
And the person who benefits from a correction never authorises it. BigLedger models this directly in one place: a sell-below-price request names an approver in advance, the approver authenticates with their own Akaun login, and the till refuses anyone else with “User is not the assigned approver.” Extend the same habit to cash: the person who counted the drawer is not the person who signs off the difference.
What to hand over, and to whom. Before you leave, give your supervisor:
- the Z Report exported to PDF for your branch, date and session;
- the printed closing count with the denominations on it;
- your cash-in and cash-out slips;
- one line saying what you counted, what you expected, and which of the four causes you believe each part of the difference is.
Your supervisor’s part is to compare the two numbers and either accept the explanation or escalate it. That comparison is the control. Nothing in BigLedger performs it, schedules it, or notices that it did not happen, so if nobody owns it at your branch, the blind count you just took was only a count.
The next morning, the supervisor re-runs the same report and checks the explanation came true. At GadgetSphere it goes like this. The till is switched on at a quarter to ten and sends the RM 218.00 bill, which keeps Saturday’s date. The supervisor moves the power bank to Card with a Settlement Adjustment. Then Saturday’s Z Report for your session, run again, shows a Cash row of RM 4,059.40 — RM 4,126.40, less the RM 285.00 that was card, plus the RM 218.00 that arrived. Expected is now RM 500.00 + RM 4,059.40 − RM 2,035.00 = RM 2,524.40, against your RM 2,519.90. The difference that is left is the RM 4.50, and that is the one that goes in the branch’s log. The run is a recomputation, so it agrees with your note because the explanation was right, not because anybody edited the figures.
What the drawer touches after you lock up
The count itself posts nothing — no journal, no cashbook line, no document. But each bill in it does, and the shape of that is set up long before anyone counts a drawer.
What has to exist first. Session and float control switched on, for any of Steps 1 to 5. A drawer attached to the terminal. And payment methods linked to the branch, each naming the cashbook its money goes to — the counter’s payment buttons come from the branch’s linked methods, and a method with no cashbook behind it still takes the customer’s money at the counter while its cashbook line fails in the background.
What each cash payment line becomes. A line in the cashbook the payment method names, dated with the bill’s date, carrying the bill’s branch, net of any charges on the method; and its share of that bill’s own journal. There is no single day’s-takings journal — every bill posts its own. So the RM 285.00 correction in Step 7 restates Saturday’s cashbook and journal, not Sunday’s, and an offline bill that is re-dated moves its cashbook line and journal to the day it was sent, with the Z Report.
One cash method for every branch means one cashbook for every drawer. The cashbook comes from the payment
method, not from the branch. If GadgetSphere links a single Cash method to all 22 branches, all 22 drawers
post into one cashbook, told apart only by the branch on each line — fine for the ledger, awkward for the
person who has to agree GS-KV-01’s cash with GS-KV-01’s deposit. To give a branch its own cash account,
CASH-PRI-KV01, give it its own cash method, naming that cashbook, linked to that branch alone. The cashier
sees one Cash button either way.
What becomes possible once the drawer is explained. The deposit. The RM 2,000.00 handed over at four, and whatever leaves the drawer tomorrow morning, are banked with a Bank In cash transfer out of the branch’s cash cashbook, and that is the line Bank Reconciliation later matches against the statement. A drawer nobody explained is a deposit nobody can explain either, because the deposit comes from the count, not from the Z Report.
What it is used alongside. The card terminal’s settlement slip, every night — it is the only outside evidence for kind 1. The Missing Journal check the next morning, so the day’s bills are known to be in the accounts before anyone reconciles them (how you know the day’s takings reached the accounts). And Banking the Day’s Takings, which starts where this guide stops.
When you are done, run the whole shift’s success check.
Related documentation
- Balancing the Drawer: the whole shift, with its success check and the common mistakes.
- POS General applet: the session, Cash In / Cash Out and the Z Report.