Reports

“Two reports over the same period give different totals. Which is right?” At a till the answer is usually both: every end-of-day screen in this module adds the bills up again each time you run it, and each one adds a different set. This page is for the branch supervisor who closes the day and the finance person who checks it the next morning. It says where each figure comes from, why figures that should agree do not, and how the day gets closed so that it stays closed.

Meet the example. GadgetSphere Sdn Bhd’s branch GS-KV-03 closes on a Saturday having taken RM 18,420.50 over two tills: RM 4,310.00 in cash, RM 11,960.50 on cards and RM 2,150.00 by e-wallet. The figures below follow that day.

Where each end-of-day figure comes from

Nothing in this module stores a report. Every Z Report and every Cashier Collection is summed again on the server each time you press Search, from the bills as they stand at that moment. The cashbook line and the journal are different: a job writes them after the bill is FINAL, and they stay written until something replaces them. Knowing which kind a figure is tells you whether it can move after you have read it.

The figure	Worked out when, from what	So it can move when
Takings on the till’s Z Report (one row per payment method)	Live. The payment lines of FINAL cash bills whose transaction date falls from Date From to the end of Date To, for one branch, and for one device or session if you pick one	A bill dated to that day is finalised, voided or re-tendered later — including one that arrives late from an offline till (below)
The per-cashier split under the takings	Live. Each payment line is credited to the login that created the bill, found through that person’s e-mail sign-in. A line whose creator has no live e-mail sign-in is left out of the takings, and no row says so — a known issue, reported to engineering, and one that occurs in live data	It does not move; it is missing from the start. Cashier Collection keeps those lines, so compare the two totals
Total Net Sales and the sales block	Live. The goods lines of the same FINAL bills, counter returns subtracting, with member-point discount split from ordinary discount	As for the takings
The Cash Drawer Float block and Variance	Live, and only when session float control is on and you pick a session: the drawer movements of a session that started and ended inside your date range. The Variance is then worked out in your browser as the last drawer’s movement minus Total Net Sales	A session still open, or one that closed after midnight, shows no float block for a single day
Contra on the till’s Z Report	Live, and only when contra is switched on. Dated by the contra record’s own date, not the bill’s	A contra applied today against yesterday’s bill lands on today’s report
Void, draft and return counts	Live counts. The void and draft counts are not narrowed to a session; the return count includes bills of any posting status	These are counts, not money: none of them changes a ringgit of takings
The Z Report in Daily Cashier Reports	Live. One date, four document types: cash bill, sales invoice, sales return and sales refund note; a refund note’s payment subtracts	An invoice raised on terms adds to its sales block and nothing to its takings, because it carries no payment line
Cashier Collection (either applet)	Live. One row per payment line on FINAL documents, at the amount keyed. The till’s reads cash bills; Daily Cashier Reports’ reads six types and turns payment vouchers and refund notes negative in your browser	You filtered on Create Date instead of Transaction Date, or on neither (today only)
The cashbook line	Written by a job once the bill is FINAL: the tender less the payment method’s charges, dated the bill’s transaction date	A settlement adjustment replaces it
The journal	Written by a job once the bill is FINAL, from the GL codes as they are at that moment. A re-post deletes the bill’s journal and writes a new one	Somebody re-posts the bill after a GL default was fixed

FINAL comes first, the books follow. Pressing FINAL commits the bill and puts one job in a queue; the journal, the cashbook line and the stock movement are written by the jobs that one sets off. So for a short time — longer on a busy evening, and indefinitely if a job fails — a bill is on the Z Report and on Cashier Collection but not yet in the cashbook or the ledger. A cash-up done at the counter and checked against the books five minutes later can differ by the last few bills for that reason alone.

The Daily Summary is not a till report. The Sales Report applet’s Daily Summary totals the payment lines of receipt vouchers and payment vouchers only, by settlement type — cash, cheque, card, e-wallet. A cash bill is neither, so a branch that only rings up cash bills gets an empty Daily Summary however busy the day was. It is the report for money collected against invoices, and it does not read a cashbook either.

Why two figures that should agree do not

When two end-of-day numbers differ, the cause is nearly always one of the following. Only the last row is missing money.

The two figures	Why they differ	What to do
The till’s Z Report against the Z Report in Daily Cashier Reports	The till’s counts cash bills; the other counts four document types, so a standalone sales return, a refund note or a paid invoice changes one and not the other. A return taken at the counter is return lines on a cash bill, so it is on both	Agree with finance which screen is the day’s figure, and write it down. Each choice has a cost, set out below
The per-device Z Reports against the all-devices one	Device is a filter. A bill or session with no device — opened through the API, or on an older build — is on the all-devices report and on none of the per-device ones	Run All first; then register the terminal
The Z Report’s takings against Cashier Collection	The Z Report leaves out payment lines whose creator has no e-mail sign-in, and shows contra; Cashier Collection keeps every line and shows no contra	If they differ by exactly one person’s takings, look at that person’s sign-in before anyone recounts cash
Card takings against the card cashbook	The cashbook line is the tender less the method’s charges — what the acquirer actually pays you	Expect it lower by the fee, every day. RM 11,960.50 of card takings on a method charging 1.2% is RM 11,816.97 in the cashbook
The Z Report against the cashbook or ledger, by a few bills	The posting jobs have not run yet, or one failed	Wait, then run Missing Journal (below). A bill still missing is a failed job, not a missing sale
Total Net Sales against the takings	Sales is what was sold; takings is how it was paid. Contra, and in Daily Cashier Reports any invoice on terms, sit in one and not the other	Reconcile the drawer against the Cash row of the takings, never against Variance
The Variance line against the drawer count	Variance subtracts every tender’s sales from a cash-only movement, so at a counter that takes cards it is negative by roughly the card and e-wallet takings	Leave it out of the cash-up; it is arithmetic, not a shortage. The drawer procedure is Balancing the Drawer
Yesterday’s signed Z Report against yesterday’s Z Report run today	The report is live: since it was signed, a bill dated yesterday arrived, was voided or was re-tendered	Find which with the two date columns (next section) and the settlement-adjustment listing
The Z Report’s points discount against the members’ points	Points are taken off a member’s balance by a separate job, and only where the company’s member-point configuration names the cash bill. A redemption accepted at the till and never deducted under the default configuration is a known issue, reported to engineering	Membership › Reports
Takings against the counted drawer, after all of the above	Money is missing	The evidence list at the end of this page

Which Z Report is the day’s figure is a decision, not a fact. The till’s report carries the session and drawer blocks and sits on the till’s own menu, but it leaves out refund notes and invoices that took money at the counter. The Daily Cashier Reports one includes them and can be opened by someone with no till session, but it has no drawer block and covers one date at a time. A group that uses both without saying which is authoritative will spend its month-ends explaining the gap between them.

Use the two date columns to catch a bill dated to a different day

Both cashier screens carry Transaction Date and Create Date — on the till’s Cashier Collection as two filters you must choose between, and in Daily Cashier Reports as adjacent columns. The server stamps the create date when the bill is first saved; the transaction date is the day the bill says it belongs to, and it is the date every report, the cashbook line and the journal use. They are almost always the same day, and the interesting cases are the ones where they are not.

Three ways the dates come apart

Somebody backdated it. A cashier holding POS_EDIT_TRANSACTION_DATE can change the date on a bill that is not yet FINAL. The date picker goes back seven days at most and never forward.
The till was offline. A till in offline mode keeps its FINAL bills in a queue and sends them, oldest first, when it reconnects. A bill the server has never seen keeps the date it was rung up on, and the picker’s seven-day limit plays no part — a till that was offline for a week brings in bills a week old. A bill the server already held as a draft is re-dated to today instead.
It came from somewhere other than the counter. The seven-day limit belongs to the till’s date picker, and the server does not repeat it, so a bill created through the API carries whatever transaction date the caller sends.

For example, a till at GS-PEN-01 loses its connection on Thursday afternoon and carries on selling in offline mode. It reconnects on Friday morning and sends 14 bills worth RM 3,280.00. Each keeps Thursday as its transaction date and gets Friday as its create date, so the Thursday Z Report signed that night is RM 3,280.00 short of the Thursday Z Report run on Friday — and Friday’s is untouched. Nobody did anything wrong, and the only trace is the two date columns.

Live data shows all of these outcomes: nearly every bill carries the same date in both columns, a small share were created one to seven days after the date they carry, and a smaller share more than a week after. A few were even created before the date they carry. Each deserves the same question.

A bill whose create date is Tuesday and whose transaction date is Saturday was dated backwards on purpose, or by a till catching up. Sometimes that is right — a till that was offline, a sale reconstructed from a manual receipt. Sometimes it is a shortage being moved into a day that has already been signed off. The product gives you the fact and not the judgement: comparing the two columns is how the question gets asked at all, and nothing asks it for you.

What the date change moves, and what limits the damage

A bill dated to Saturday moves on every report together — the Z Report, the cashbook line and the journal all take the bill’s transaction date. That is the point of backdating, and it is also why the bill is invisible on the day it was actually sold. Saturday’s Z Report, already printed and signed, no longer matches Saturday’s Z Report run on Tuesday.
Backdating needs the permission, and only works before FINAL. Check who holds it before you conclude anything.
If the bill lands in a month you have already reconciled and reported, its journal lands there too, and that bank reconciliation and anything you sent the accountant are now behind the books. A fiscal period actually closed in BigLedger refuses the bill at FINAL instead.

Who checks, and how they know they got it right

Who does this: the supervisor or branch manager reviewing the day, or whoever audits a branch. When: alongside the next morning’s cashbook check, not as a separate exercise — filter Cashier Collection on Create Date for yesterday and look for any row whose Txn Date is a different day. How they know they got it right: every bill where the two dates differ has a written reason against it, the reasons are ones somebody other than the cashier can verify, and a re-run of each affected day’s Z Report has been compared with the copy that was signed.

Closing the day so that it stays closed

The product adds up; it does not sign anything off. A day is closed when a person has compared three records that are each kept somewhere else, and kept the evidence. At GadgetSphere that is two people.

At close, the branch supervisor:

Runs the till’s Z Report for the day with Device on All and exports it to PDF. That PDF is the only fixed copy of the day — the screen will give a different answer tomorrow if anything dated today changes.
Counts each drawer against the Cash row of the takings, plus the opening float, less any cash dropped mid-shift — taken from the cashier’s own slip, because a mid-shift drop does not reach the float block. RM 4,310.00 of cash takings on a RM 500.00 float means RM 4,810.00 across the drawers before drops.
Signs the PDF and the count sheet together.

The next morning, finance:

Opens Cashbook › Enquiries › Query Cashbook Transaction for each payment method’s cashbook and compares the day’s movement with that method’s row on the signed Z Report. Cash agrees to the sen; card and e-wallet are lower by exactly their charges.
Runs Ledger And Journal › Error Checking › Missing Journal for cash bills. An empty list means every FINAL bill has its journal.
Re-runs the same Z Report and compares it with the signed PDF. Any difference is a bill that moved: check the two date columns, voids and the settlement-adjustment listing until it is explained.

How they know it held: the three records agree once the charges are added back, the missing-journal list is empty, and the re-run matches the signed copy or every difference has a written reason. BigLedger runs none of these comparisons on a schedule and raises no alert when they fail, so each one needs a name against it in the branch’s routine.

When a figure looks wrong

What you see	Why	What to do
Cash bills are missing from the till’s Z Report	A device was picked, and those bills were written without one or on another device	Run it with Device on All
The Z Report misses one cashier’s whole day, and Cashier Collection has it	That person’s sign-in has no live e-mail user name, so their payment lines drop out of the takings	Report it to BigLedger support with the cashier’s login, and take that day’s figures from Cashier Collection
No Cash Drawer Float block	No session was picked, session float control is off, the session is still open, or it closed after midnight	Pick the session and set Date From to the day it opened and Date To to the day it closed. The money blocks stay confined to that session; the void and draft counts do not
Variance shows a shortfall every night	It subtracts card and e-wallet sales from cash movement	Count against the Cash row
Yesterday’s Z Report has changed since it was signed	A bill dated yesterday arrived late, was backdated, voided or re-tendered	Filter Cashier Collection on Create Date for today and compare Txn Date; check the settlement-adjustment listing
The Daily Summary shows nothing for a busy trading day	It reads receipt and payment vouchers, not cash bills	Use the Z Report and Cashier Collection for the till
The card cashbook is lower than the card takings by the same percentage every day	The method’s charges are taken off at posting	Expected. If the card-fee expense account is empty as well, the company has no `SETTLEMENT_CHARGES` default and the fee went to trade debtors (Configuration §2)
A bill is on the Z Report and not in the cashbook or ledger an hour later	Its posting job failed	Trace the bill, fix the cause and resolve it (POS General › How to tell whether the posting happened)
The branch drop-down on either report is empty	Your role’s read permission for that report has no branch targets	Add the branches to the permission’s targets: `API_TNT_DM_ERP_Z_REPORT_READ` for the Z Report, `API_TNT_DM_ERP_REPORT_CASHIER_COLLECTION_READ` for Cashier Collection

How you know the reports are telling you the truth

Run this once at a new branch, and again after any change to a payment method or a company GL default. Ring up one RM 10.00 item at GS-KV-03, settle it by card, and wait a minute.

The till’s Z Report for today, Device on All, shows RM 10.00 more on the card row than it did before.
Cashier Collection for today, filtered on Transaction Date, shows the bill once, for RM 10.00, under your name.
The card method’s cashbook shows one line for the same bill, for RM 10.00 less the method’s charge, dated today.

If 1 and 2 agree and 3 is missing, the posting is the problem, not the report. If 2 shows the bill and 1 does not, check the device and your sign-in.

What these reports depend on, and what depends on them

What must exist first. A bill reaches the money blocks only at FINAL; a DRAFT bill appears in the draft count and nowhere else. Device filtering only works if every till is registered as a device of its branch. The float block needs session float control on and cashiers who open and close sessions. The cashbook comparison needs every payment method pointed at the right cashbook. The branch lists need branch targets on each person’s report permissions.

What becomes possible. A signed Z Report and a matching cashbook are what the bank reconciliation of the card and e-wallet accounts starts from, because the cashbook already carries the acquirer’s net figure. The Sales module’s reports read the same cash bills for what sold, at what margin and by whom.

The sibling, and when to use which. The Z Report answers what did this branch take, and does the drawer agree. Cashier Collection answers which bill, which method, which till, which person — use it when the Z Report total is wrong and you need the lines. The Sales Report answers what sold and at what margin, over any period. None of them is the ledger.

What breaks elsewhere if this is wrong. A payment method pointed at the wrong cashbook leaves every branch that uses it unreconcilable, and the Z Report will not show it, because it never reads an account. Nor does the daily collection summary, which reads receipt and payment vouchers only; the check that does is each method’s cashbook in Cashbook › Enquiries › Query Cashbook Transaction against the Z Report’s takings for that method (Reconciling a cash-up, Step 4). A settlement adjustment made after the day was reconciled rewrites that day’s cashbook lines and unmatches them in the bank reconciliation. A bill backdated into a reported month moves that month’s journal.

What it pairs with in practice. The Z Report pairs with the drawer count at close, and with the cashbook enquiry the next morning. Neither pairing happens by itself.

Assembling evidence about a shift

When a shift is in question — a shortage, a run of voids, a discount pattern — the platform holds six things, each on its own screen. This is the list to pull, in this order:

What	Where	What it tells you
The audit trail	POS General › Audit Trail (`POS_SHOW_AUDIT_TRAIL_REPORT` and its menu setting)	Who changed what on a bill, before and after
The void list	Cash Bill Listing, filtered to VOID for the date and branch	Which bills were reversed and by whom
Discounts	The Z Report’s own split of ordinary discounts from member-point discounts	Whether the pattern is pricing or loyalty
Price overrides	The one-time approval request history	Which lines were released below a floor, and which supervisor authorised each
Session events	Session listing — open, close, cash in and cash out	Who held the drawer and when it changed hands
Settlement adjustments	The Settlement Adjustment listing, with its own posting status and error columns	Which bills were repaid under a different method after the fact

None of this is automatic. There is no exception report, no cashier scorecard, no alert on a run of voids, and no record at all of a drawer being opened outside a cash sale. A branch that wants this review has a person doing it on a named day with the six screens above — and the evidence that it happened is the exported set, kept with the month’s paperwork.