Till over or short at close: hunting end-of-day discrepancies in LS Central
The count is done, the system expected one number, and the drawer holds another. Before anyone says the word "theft" — and before anyone touches the statement — work the problem in the right order. Most end-of-day differences in LS Central are counting errors, unrecorded cash movements, or transactions that never arrived. This guide stays on the operational side of the counter: what to recount, what to check, and where the system keeps the proof. The finance side — calculating, reconciling, and posting the statement — is covered in our statement reconciliation guide; do the hunt here first, then hand over a difference you can explain.
First: rule out the count itself
A discrepancy is counted money versus system money. Either side can be wrong, and the counted side is wrong surprisingly often: a strap of bills stuck together, coins counted into the wrong denomination, a bag counted twice or not at all. LS Central's Safe Management documentation treats the physical count as one half of a reconciliation — Safe Statements are generated at end of day specifically to reconcile the system-expected amount with the cashier's physical count — so treat your first count as a claim, not a fact.
- Recount from zero, by denomination. Empty the drawer and rebuild the count denomination by denomination. Do not "adjust" the first count — a second count that starts from the first count's total just repeats its mistakes.
- Count every bag, including the ones in the safe. In Safe Management, cash moves in bags, and a bag can sit uncounted at statement time — the documentation calls out uncounted bags as a named end-of-day exception. A bag nobody counted is cash the system knows about and your count doesn't.
- Check under the tray and in the drawer corners. Bills slide under the cash tray. It sounds trivial; it closes real differences.
- Have a second person count if the difference survives. Two independent counts that agree move the problem from "counting" to "system or process" — which is where the rest of this guide works.
If the recount matches the system, you never had a discrepancy — you had a miscount, and the correct action is to declare the recounted figures and note the miscount. If it doesn't match, read the difference before you chase it.
Read the difference before you chase it
The shape of a difference is evidence. Use it to pick your hunting ground instead of checking everything at random:
| Shape of the difference | Points at | First place to look |
|---|---|---|
| Cash short, another tender over by a similar amount | A sale tendered to the wrong tender type | The day's transactions for that terminal, filtered by tender |
| Short by a round amount | An unrecorded pickup, float movement, or paid-out | Pickup and float entries made during the shift |
| Short or over by exactly one sale's value | A missing or duplicated transaction | Transaction numbers for the terminal — gaps or duplicates |
| Small, odd amount (coins and small bills) | Change given incorrectly during the day | Nothing in the system proves this — see the decision rules below |
| Whole terminal missing from the totals | Transactions never reached the central database | Whether that terminal was offline, and its transaction queue |
One structural point before the hunt: a tender type only produces a counted-versus-system difference if it is set up to be counted. On the Tender Type Card, if Counting Required is not marked, LS Central automatically fills the counted amount with the transaction amount when the statement is calculated — that tender can never show a difference, because it was never really counted. If a tender you expected to count shows no difference line at all, that setup is the first thing to verify.
The hunt, cause by cause
Work these in order — cheapest and most common first.
- Uncounted or double-counted bags. List the day's bags for the terminal and match them, one by one, against what was physically counted. Bags support re-counting after they have been sealed, so a suspect bag can be reopened and recounted rather than argued about.
- Pickups and float entries not recorded. Cashiers perform pickups and float entries through the POS during the shift, and every one of those movements belongs in the record. Cash that was picked up into the safe but never entered as a pickup is still "expected" in the drawer — and the drawer will read short by exactly that amount. Compare the physical bags in the safe against the pickup entries for the day.
- Transactions that never arrived. If a terminal traded offline, its transactions may still be queued locally. LS Central has a specific defence here: with the Check for Missing Transactions option selected in the Functionality Profile, statement calculation compares the highest transaction number in the central database against the highest on each POS terminal and shows you which terminals are missing transactions, with the option to stop the calculation. If that check fires, the difference is not a cash problem at all — wait for the transactions, then recount the totals. (Our offline mode guide covers verifying the queue drained.)
- A Z-Report that closed the day early — or never ran. A Z-Report resets the day's totals so the next trading day starts fresh; sales rung after it belong to the following day, not this one. The POS can be set to check this: with POS Check Z-Report enabled, the terminal checks whether the Z-Report was printed for the last business day and prompts the user to run one when it finds transactions not marked as Z-Report executed. A "shortage" that is really yesterday's late sale sitting in today's numbers resolves itself once you place the transaction on the right day.
- Trace the amount through the audit records. Safe Management is built so any amount can be traced back to its originating POS transaction: Safe Ledger Entries record every movement — transaction, transfer, journal entry, statement, correction — and Trans. Difference Entries record the differences the system itself detected. If a specific amount is in dispute, search the ledger entries for that amount and that terminal before concluding the money is simply gone.
When the till is over, not short
An overage feels like good news and gets investigated half as hard. Don't let it. Extra cash usually means a customer was short-changed, a sale was never rung through, or a pickup was recorded that never physically happened — each of those is a real problem wearing a pleasant disguise. LS Central's Safe Management documentation treats "too much money" as an exception scenario in its own right, alongside "too little money," and the hunt is the same: recount, check bags and pickups in reverse (a pickup entered but not taken leaves the drawer over), and trace the amount in the ledger entries. An overage you cannot explain gets documented exactly like a shortage.
Escalate or accept: the decision rules
- Difference found and explained (miscount, uncounted bag, unrecorded pickup, late transaction): correct the operational record, declare the true count, and note what happened on the day. Done at store level.
- Difference survives the full hunt: document it — amount, terminal, cashier, what was checked — and hand it to the manager who runs the statement. There is a system limit on what can pass at that stage: the Max. Diff. To Allow Post field defines the maximum difference between the counted amount and the transaction amount. Know that the limit exists; changing it is not a closing-time decision. Note also that when Safe Management is in use for a store, it controls difference handling and that field becomes non-editable on the store setup.
- The system warns you during declaration: if a statement line ends up with a counted amount of zero against a non-zero transaction amount, LS Central warns you. Treat that warning as a hard stop — zero counted almost always means the tender was never counted, not that the drawer was empty.
- A pattern repeats (same terminal, same cashier, same shape of difference, several days running): stop treating each day as an isolated accident. That is a training, setup, or supervision issue, and it escalates as a pattern, with the documented days attached — not as a series of small write-offs.
What success looks like
The close is under control when: every terminal's count was done twice or verified by a second person; every bag in the safe is accounted for against the day's bag list; pickups and float entries match the physical movements; no terminal has unarrived transactions; and any remaining difference is written down with its amount, its shape, and the checks performed — ready for the statement step in the reconciliation guide, not buried inside it.
FAQ
Should the count be done before or after the Z-Report? The declaration is the count of what the day actually took. An X-Report — a snapshot of the day's till activity that can be run at any time without resetting anything — is the right tool for a mid-shift check; the Z-Report closes the day and resets the totals, so anything rung after it lands in the next trading day.
Can a bag be recounted after it is sealed? Yes — bags in Safe Management support re-counting, which is exactly what the recount step uses when a bag's contents are in dispute.
The difference is tiny. Can it just be left? Tiny differences still get documented with the same one line as big ones. The decision about what may be accepted sits with whoever posts the statement, inside the Max. Diff. To Allow Post limit — it is not made silently at the till.
Keep readingNext: reconciling LS Central statements →