Balancing the Drawer

You have just served your last customer. The drawer is full of notes you have not counted, the Z Report is one button away, and the shop wants to lock up. By the end of this guide you will be able to count the till, work out what you should have found, and — if the two numbers differ — say which of four things the difference actually is before anyone calls it a shortage. It takes about ten minutes the first time and five after that.

Read this one before you need it. The night you are RM 450 short is the wrong night to be learning where the figures come from.

Meet GadgetSphere

GadgetSphere Sdn Bhd runs 22 consumer-electronics branches across Malaysia. You are on the counter at GS-KV-01. You opened this morning with a RM 300 float, you have taken cash, cards, e-wallets and a few point redemptions all day, and at four o’clock you handed RM 2,000 to the branch manager to bank. The drawer now holds RM 1,847.55 and you are about to find out whether that is the right number.

What BigLedger holds, and what only you hold

This is the part no screen tells you, and everything below depends on it.

The fact	Where it lives
The float you started with, note by note	Stored. The opening count is saved as a denomination record against the session
Every sale, and how it was tendered	Stored, on the bill
Money you took out or put in mid-shift	Stored as an amount, a direction and free text — and it never reaches the Z Report (see below)
The total you counted at the end	Stored — the total only. The closing denominations are not saved
The change you handed back	Never recorded anywhere. The till takes the settled amount, not the amount tendered
What you should have found	Nowhere. No screen and no report subtracts one of these numbers from another
Why a difference happened	Nowhere. The Remarks box on the closing screen is not saved

So the arithmetic at the end of a shift is yours, the explanation is yours, and the evidence for both is whatever you wrote down while the shop was open. The rest of this guide is about making that cheap instead of expensive.

If there is no Session menu at your till, your shop runs without sessions and floats. That is a supported way to run a counter — the till still records every sale and every tender, and the Z Report still gives you takings by payment method. You lose the opening and closing figures and the float movements; you lose nothing about the sales. Skip Steps 1 to 3 and start at Step 4, comparing your count against the Cash row of the takings block.

Step 1: Count the float into the drawer, and let the till store the denominations

POS General › Session › Create

Key the Opening Amount, or open the Float Count tab and key how many of each note and coin you have — RM 100 down to five sen — and let it total for you. The float count is the version worth doing, because the denominations you key at opening are saved: one stored line per denomination, against this session. That is the one moment in the shift where BigLedger can prove exactly what was in the drawer.

The session records who opened it and on which terminal. From here until someone closes it, the drawer is yours.

Do not put an explanation in the Remarks box on this screen. It is on the form and it is not saved — neither here nor on the closing screen. Anything that has to survive the night goes on paper or into the branch’s own log.

Step 2: Write down every note that leaves the drawer, because the report will not

POS General › Cash In / Cash Out

When you take RM 2,000 out to bank, or drop RM 200 of small notes in because you are running out of change, record it: pick CASH OUT or CASH IN, key the amount, and write a remark that will still mean something at nine in the evening. “To branch manager for banking, counted by me” is a remark. “Drop” is not.

Two things about this screen are worth knowing before you rely on it.

There is no reason code. You get a direction, an amount and free text. So a banking drop, a float top-up and petty cash taken for a courier are the same kind of record, and only your wording separates them. That convention is the whole control, so agree it once at the branch and write it the same way every time.

Your cash-in and cash-out records do not appear on the Z Report. The till writes these lines against the session and never against the drawer, and the report’s float block joins on exactly that drawer reference — so the block returns the opening and closing figures and nothing in between. This is not something you can configure around. The record that survives is the one you make on paper, and the person who needs it is whoever compares your count to the day’s takings in Step 5. Write the amount, the time, the reason and who took the money, and keep the slip with the shift’s paperwork.

Step 3: Hand the till to one named person, not to a shift

A drawer that two people used is a drawer nobody can answer for. BigLedger records who opened the session and which login pressed CLOSE; it records nothing about the people in between, and the Z Report attributes each payment to the login that keyed it.

So when the counter changes hands mid-trading:

The person leaving counts the drawer and closes the session.
The person arriving opens a new one with that count as their opening float.
Both of them sign the printed count.

That takes four minutes and it is the difference between “the drawer was RM 60 short at some point today” and “the drawer was RM 60 short during the second shift.”

Nothing stops the wrong person closing your session. POS_CLOSE_SESSION, POS_FLOAT_CASH_IN_OUT and POS_ATTACH_DRAWER exist as permissions and no screen in the current till checks them — the Session menu appears for everyone once session and float control is switched on. So “only supervisors close a session” is a rule your branch keeps, not one the product enforces. And never share a login: the attribution on every bill, every void and every price override is the login that keyed it, and a shared login makes all of it worthless at once.

Step 4: Count the drawer before you look at any figure

POS General › Session › Close

The closing screen asks for a Closing Amount and shows you nothing else — no opening float, no takings, no expected total, no variance. That is not an oversight to work around. A count you make without knowing the answer is worth more than one you make while looking at it, because it is the only version that can detect a difference rather than reproduce one.

So: count first, key what you counted, and resist the temptation to run the Z Report in another tab beforehand.

Use the Float Count tab and then Print › Receipt (PDF) before you press CLOSE. This matters more than it looks: BigLedger stores your closing total and discards the denominations, so the printed slip is the only record of what the drawer was made of. When the difference turns out to be a missing RM 50 note rather than RM 47.35 of change errors, that slip is what tells you.

Step 5: Work out what you expected, because nothing in BigLedger will

POS General › Z Report — one branch, one date, Device set to All

Run the Z Report and take the Cash row of the takings block. Then do this arithmetic on paper:

  Opening float                RM   300.00
+ Cash takings (Z Report)      RM 3,547.55
+ Cash in                      RM     0.00
− Cash out (your slip)         RM 2,000.00
= Expected in the drawer       RM 1,847.55

Compare that to what you counted. That is the whole method, and there are three traps in it.

Do not use the printed Variance line. The Z Report prints a figure called Variance and it is not your variance. It is (Closing − (Opening + Cash In − Cash Out)) − Total Net Sales, which takes a cash-only movement and subtracts every sale from it — cards and e-wallets included. At any counter that takes a card, that line is negative by roughly the non-cash takings, by the design of the arithmetic and not because money is missing. Compare cash to the Cash row and ignore the line underneath.

Run it with Device on All. Every Z Report query filters on the device when you pick one, and a bill rung up on a terminal that is not registered is excluded from any device-specific run. If the takings look low before you have counted anything, this is the first thing to check.

A session that is still open has no float block at all. The block filters on the session’s start and end dates, and an open session has no end date. Close the session, then run the report.

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.

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. A card sale keyed as cash 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: if the terminal says RM 285.00 more than the Z Report’s card row, you have found it, and 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.

2 — A void or a refund that did not get recorded. Goods went back over the counter and the paperwork did not.

How you find it: 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.

3 — A change error. Somebody handed back RM 50 instead of RM 5.

How you find it: you cannot, from BigLedger. The till never records change — the cashier keys the settled amount, which must equal the bill to the cent, and what was handed across the counter is not a fact the system holds. There is nothing to query and no report to run. What you have is the receipt, 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.

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.

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 and date;
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 it 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.

What success looks like

Thirty seconds, before you lock the drawer:

The session is closed, and the Closing Amount on it is the number you actually counted — not a number you adjusted to make something agree.
A printed count slip exists with the denominations on it, and its total equals that Closing Amount.
Your expected figure and your counted figure are both written down, next to each other, on something your supervisor can read tomorrow.
The Z Report is exported, run for the trading date with Device on All.
If there is a difference, it has a name — wrong tender, missing void, change error, or unexplained — and a person other than you has seen it.

Common mistakes

Running the Z Report before counting. It turns a blind count into a copying exercise. The only reason to count at all is to find a difference you did not already know about.

Reading the Variance line as the variance. It is negative at every counter that takes a card, by design. Half the “my drawer does not balance” calls are this line.

Expecting cash in and cash out on the Z Report. They will not be there. The paper slip is the record.

Typing the explanation into the Remarks box at close. It is not saved. Write it on the count slip.

Letting the shift change without closing the session. You will find the difference; you will not find which half of the day it belongs to.

Correcting a bill to make the drawer agree. It restates the day in the ledger, it undoes any bank reconciliation on that line, and it turns a RM 60 question into an audit finding.

Treating a round-number difference as a change error. Change errors are rarely round. RM 50.00 exactly is usually a note, a missing tender, or a drop nobody wrote down.