Where the money lands when you press Cash — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for you if a payment button you need is not on your screen, or if somebody in accounts has asked why a bill from your shop turned up against a cash book you have never used. In about twelve minutes you will know what has to exist before a button appears, what your branch’s settlement settings decide and what they only pre-select, and the one check that tells you whether your takings and your Z Report are counting the same bills.

Step 1 — Know why a payment button exists at all

After this step you will stop looking for a setting that hides buttons. The buttons on your payment panel are the settlement methods linked to your branch, and nothing else. If a method is not linked to your branch, there is no button — no message, no greyed-out control, simply an absence. That is why a shop that has just opened has an empty payment panel and why a new tender type appears at one branch and not another. Nobody hid it; it was linked to their branch and not to yours. The fix is on the settlement method’s branch link, and it is not something the counter can do.

Reference: POS General — Before you can use it

Step 2 — Know what every method needs behind it

After this step you will recognise a failure that happens after the sale rather than during it. Each settlement method carries a cashbook and a general ledger code. Those are what turn a button press into money in a named bank or till account and a line in the accounts. If either is missing, the bill still finalises — your customer walks out perfectly happy — and the job that runs afterwards fails with a message naming the missing cashbook or code. The sale is recorded, the money is not placed, and nothing at the counter tells you. That is a genuine end-of-month surprise, and it belongs to whoever set the method up.

Reference: POS General — Before you can use it

Step 3 — Understand what the branch default really does

After this step you will stop expecting it to control the posting. Your branch has a default settlement method for each kind of tender — cash, card, voucher, e-wallet and the rest. It is a convenience: it decides which button is already selected when the payment panel opens, so the common case takes one tap fewer. It does not decide where the money posts. That is decided entirely by the cashbook on the settlement method the cashier actually used. This matters because it makes the default harmless to change and useless as a fix: correcting the default will never move a posting that has already happened.

Reference: POS General — Branch Settings — what each tab actually reaches

Step 4 — Explain the zero-total bill in the wrong cash book

After this step you will be able to answer a question accounts will eventually ask. A bill has to balance: the items and the settlement must agree, or it refuses to finalise. So a bill that nets to exactly zero — a full return taken against a sale on the same document — would have nothing to settle with. BigLedger fills that in for you, adding a settlement line of zero so the bill can close. The method it chooses is the most recently created cash method linked to your branch. Not your default, not your till cash. The newest one. If a float or an administrative cash book was added lately, that is where these land.

Reference: POS General — Branch Settings — what each tab actually reaches

Step 5 — Check that your takings and your Z Report agree

After this step you will catch a mismatch on the day rather than at month end. The Z Report filters on the terminal device you choose in its form, and every bill carries whichever device the browser it was written on had registered. Bills written without a device — a browser whose stored device was cleared, a machine set up in a hurry — are simply left out of any run for a specific device. So when the Z Report and the bill listing disagree, run the Z Report again with the device left on all devices and compare. If the total changes, the money is not missing; the filter is.

Reference: POS General — Troubleshooting

Step 6 — Know the two corrections you cannot make yourself

After this step you will not spend an afternoon on either. The first: a settlement line that has already been matched in bank reconciliation blocks any change to that bill until somebody unmatches it, so a correction that worked last week can refuse this week purely because reconciliation has caught up. The second: the settlement on a finalised bill can only be edited where both the setting and the permission for it are in place, and even then not once it is reconciled. When either applies, raise it with the finance desk with the bill number and the tender, rather than voiding and retyping, which makes two problems.

Reference: POS General — Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Know why a payment button exists at all"]
  s2["Step 2 — Know what every method needs behind it"]
  s3["Step 3 — Understand what the branch default really does"]
  s4["Step 4 — Explain the zero-total bill in the wrong cash book"]
  s5["Step 5 — Check that your takings and your Z Report agree"]
  s6["Step 6 — Know the two corrections you cannot make yourself"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: The settings that reach you, the ones that stop at the company, and one that reaches nothing · Back to the series · Play this as a presentation