Cash Sales Workflow

You are on the counter. Someone puts a pair of earbuds on the desk, taps their card, and expects to be out of the shop in under a minute. By the end of this guide you will know how to open your till at the start of a shift, ring a sale through, take any tender the shop accepts, and close the day so that the cash in the drawer matches what BigLedger says it should be. The selling part takes about thirty seconds once you have done it twice. The opening and closing take five minutes each and they are what keep you out of trouble.

Everything here happens in one applet: POS General.

The shift, at a glance

Open your session and count your float (Step 1, on this page).
Ring the sale (Step 2), take the payment (Step 3) and press FINAL (Step 4).
Fix a mistake without panicking (Step 5) and close the day (Step 6).
Run the success check at the end of your shift.

The shift runs across three pages: Step 1 is on this one, Steps 2 to 4 are on Ring, Pay and Finalise, and Steps 5 and 6 are on Fix and Close.

Meet GadgetSphere

GadgetSphere Sdn Bhd runs 22 consumer-electronics branches across Malaysia. You are on the counter at GS-KV-01 in Klang Valley. The shop takes cash, cards, e-wallets, gift vouchers and member points. Today’s sale is a pair of wireless earbuds at RM 249 and a USB-C cable at RM 39 — RM 288 net, RM 17.28 SST at 6%, RM 305.28 to collect. The customer wants to pay RM 100 in cash and the rest on a card.

The one thing to understand before you start

A counter sale in BigLedger is a single document called a cash bill. It is not an order followed by an invoice followed by a receipt — it is one record that does all three jobs at once. When you press FINAL:

the items come out of stock at your branch’s location;
the sale is posted to the ledger — revenue and SST (cost of goods sold is a month-end journal, not part of the bill);
each payment you took is written into the cashbook behind that payment method, ready to be reconciled against the bank;
and, if your company is registered for e-Invoice, the bill is queued for submission to LHDN.

There is no separate “post” or “issue invoice” step afterwards, and no sign-off. FINAL is the whole thing — which is why the rest of this guide is mostly about what to check before you press it. (Strictly, FINAL starts all of that rather than doing it: the journal, the stock line and the rest are done a moment later by background jobs. On a busy Saturday, “it has not posted” is usually “it has not finished yet”.)

Before your first shift

You do not set these up — your branch manager or the finance team does — but it helps to know what they are, because when one is missing the error message you see at the counter points straight at it.

Your branch has settlement methods linked to it. These are the payment buttons. If the settlement panel is empty, nobody has linked your branch in Cashbook → Settlement Method → Branch.
Your branch has a default location. The bill must sell from it. If it does not, FINAL is refused with “The location does not match the branch’s default location.”
The company’s default GL codes are mapped — SALES, DEBTOR, OUTPUT_TAX, SALES_RETURN, SALES_DISCOUNT (and COGS for month-end). At GadgetSphere those are SALES-ACCESSORY, DEBTOR-TRADE-RETAIL, LIAB-SST-OUTPUT, COST-ACCESSORY and so on. A missing one does not stop FINAL, and what happens next depends on which one. A missing DEBTOR fails the posting job behind any bill that needs a receivable line, silently — a bill paid in full whose every line found an account never reads it, but one where another code is missing does — which is why the third check in What success looks like is there at all. A missing SALES or OUTPUT_TAX fails nothing: the line is left out and the customer’s receivable takes up the amount, so on today’s sale with no sales code the ledger shows RM 288 less in sales and RM 288 credited to trade debtors. (If the walk-in customer has no AR/AP type, there is nothing to take it up and the posting fails instead.) Finance notices it as trade debtors moving on a day of cash sales; the time to catch it is a test bill before go-live, with its journal read line by line.
A rounding item exists. Malaysian cash rounding to the nearest 5 sen is added to the bill as a line, using the item set in Default Selection. Without it, cash bills that need rounding cannot balance.
You have a walk-in customer. Every bill needs a customer; the default one is pre-selected so you never have to think about it.

Step 1: Open your session and count your float

POS General > Session > Create

Start here, before your first customer. Opening a session records who is on the till, on which terminal, and how much money was in the drawer when you started.

Give the session a code and a name — your branch’s convention, something like KV01-AM-15SEP. Enter the Opening Amount: the cash you counted in the drawer.

Use the Float Count tab. It is slower, and it is the version that survives an argument at 9 pm — because the denominations you key at opening are stored, one line per note and coin. It is the one moment in the whole shift where BigLedger can prove exactly what was in the drawer. (At closing time it cannot: only the total is kept. See Balancing the Drawer.)

Do not type anything important into the Remarks box. It is on the session screens and it is not saved — not here and not at close. Anything that has to survive the night goes on paper.

If there is no Session menu, your tenant has session and float control switched off. That is a legitimate setup — and you can skip straight to Step 2. You lose the opening and closing float figures; you do not lose anything about the sales themselves.

And one rule that has nothing to do with the screen: the drawer has one owner at a time. The session records who opened it and which login closed it, and nothing about the people in between. If somebody takes over your till mid-shift, count it, close the session, and let them open their own with your count as their float — four minutes, and it is the difference between “this branch was short today” and “this shift was short.” Nothing in the product enforces this: the permissions that look as though they would (POS_CLOSE_SESSION, POS_FLOAT_CASH_IN_OUT, POS_ATTACH_DRAWER) are registered and no screen checks them. And never share a login — every attribution the till records, on every bill, void and override, is the login that keyed it.

Next: ring the sale, take the payment and press FINAL.

What success looks like

Thirty seconds at the end of your shift:

Z Report Cash row + opening float + cash in − cash out = cash you counted. A difference of a few sen is rounding; a difference of tens of ringgit is one of four things and it is easier to name today than tomorrow — Balancing the Drawer, Step 6 walks the four. If there is a difference, do not adjust anything to make it go away: report it, with your count slip and the exported Z Report, to somebody who did not count the drawer.
Open Cash Bill Listing, filter to today, status FINAL. Every bill you rang is there. Anything still showing as a held draft is a customer you parked and forgot.
Ask finance to run one posting check on today’s bills — because you cannot run it from the counter. The POS applet has no Posting tab and the Cash Bill Listing has no posting-status column, so nothing on your screen distinguishes a bill whose journal was written from one whose journal failed. Both read FINAL. The check lives in two other applets, and it takes finance under a minute:
- One bill — Financial Report › Error Checking › Trace Document, Server Doc Type INTERNAL_SALES_CASHBILL, and the Doc No from your listing. It reports whether the journal and the cashbook line exist, with a Resolve button that posts the missing one.
- A whole trading day — Ledger And Journal › Error Checking › Missing Journal, same document type, Date From and Date To both set to today. It lists every FINAL cash bill with no journal behind it, with Branch and Amount, so the total that is missing is on the screen before anything is repaired.
The bill stays FINAL either way; what is unmapped is a GL code or a settlement method’s cashbook, and the repair only works once the mapping exists — before the month closes. The full routine, including what the badge will not tell you, is on the applet page: how to tell whether the posting happened.

Common mistakes

Each part’s mistakes are on its own page, beside the steps they spoil:

Ringing, paying and finalising (Steps 2 to 4): waiting for something else to reduce the stock, adding the member after the bill is finalised, scanning the wrong number of serials, reading an identity number back out loud, forcing a bill to balance by changing the price, and backdating a bill for yesterday.
Fixing and closing (Steps 5 and 6): closing the shift without running the Z Report.