Balancing the Drawer: Count and Expect

Record the cash, hand over the till, count it and work out what you expected

Steps 2 to 5 of the end-of-shift count: from the first cash drop to the figure you expected. You record every note that leaves the drawer, hand the till over by closing your session, count blind, and work out on paper what the drawer should hold, because nothing in BigLedger does. It follows Step 1, where the float was counted in. 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. No Session menu at your till? Your shop runs without sessions: skip Steps 2 and 3 and start at Step 4 (why).

Step 2: write down every note that leaves the drawer, because the report will not.
Step 3: hand the till to one named person, not to a shift.
Step 4: count the drawer before you look at any figure.
Step 5: work out what you expected, because nothing in BigLedger will.

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.

Tonight that slip reads two lines: RM 2,000.00 at four to the branch manager, and RM 35.00 at five for the courier, with the courier’s receipt stapled to it. Together they are RM 2,035.00 out, and that figure appears nowhere else. Neither line posts anything to the accounts either — the banking only reaches the ledger when somebody raises the deposit (Banking the Day’s Takings), and the courier only when somebody records the expense.

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.”

A session close is a shift close, and there is no separate day end. The till has no end-of-day function: the day is closed by the last session closing and by somebody running the Z Report for the whole branch and date. Those are two different reports from one screen — with a session chosen it answers what did this drawer take during this shift, and with no session chosen it answers what did the branch take today, across every session and every till, with no float block at all. The cashier balances against the first. The supervisor who checks the day reads the second, and it is their job to see that the shifts' Cash rows add up to it.

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 4.50 of change errors, that slip is what tells you.

Tonight you count RM 2,519.90, print the slip, key RM 2,519.90 and press CLOSE. The session now has an end time, which is what the report in the next step needs.

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

POS General › Z Report — your branch, today’s date in both boxes, Device set to All, and your session in the Session box

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

  Opening float                RM   500.00
+ Cash takings (Z Report)      RM 4,126.40
+ Cash in                      RM     0.00
− Cash out (your slip)         RM 2,035.00
= Expected in the drawer       RM 2,591.40
  Counted                      RM 2,519.90
  Difference                   RM    71.50 short

Where the RM 4,126.40 comes from. It is worked out at the moment you press SEARCH: the sum of every cash payment line on a finalised cash bill at this branch, dated today, keyed during this session — at the amount each one settled, never the amount you were handed. So it contains the RM 285.00 power bank that was really a card, because the bill says Cash. It contains the refund as minus RM 129.00, because a cash refund is a cash payment line going the other way. And it does not contain the RM 218.00 offline sale, because that bill is still in the till’s queue and BigLedger has not seen it yet.

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

Choose your session, or the float block is not there. The Opening, Cash In, Cash Out and Closing lines appear only when a session is chosen, and choosing one also narrows the takings to the lines keyed during it. Run it with no session and you get the whole branch’s day — the right report for a supervisor, the wrong one for your drawer.

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. Tonight it reads Opening RM 500.00, Cash In and Cash Out RM 0.00 (the slip’s RM 2,035.00 never reaches it), Closing RM 2,519.90, and a Variance of −RM 7,850.35: RM 2,019.90 of drawer movement less RM 9,870.25 of sales by every method. 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 keeps sessions that started on or after the first date and ended before the day after the last, and an open session has no end. Close the session, then run the report. A session that closes after midnight needs both dates in the range.

Export the report to PDF before you go. Tomorrow’s run will give a different answer, and Step 7 is the reason that is good news.

Next: Steps 6 and 7, name the difference and report it.

What success looks like for this part

Your count slip, printed before CLOSE, shows the closing denominations; every Cash In and Cash Out has its paper slip; and you have the expected figure on paper: the opening float, plus the Z Report’s Cash row for your session with Device on All, plus cash in, less cash out.

Common mistakes

The common mistakes for the whole shift, from running the Z Report before counting to letting the shift change without closing the session, are listed together on the front page.