Core Concepts

What actually happens when I press Finalise? At the counter that question has a longer answer than anywhere else in the product, because the receipt prints before most of the answer has happened. This page gives it in four ideas: what one Finalise sets off and where each figure it produces comes from, what the bill writes to the books and what it leaves to the month-end, which rules the till reads and which it ignores, and how a wrong bill is reversed — including what the void check means today when e-invoicing is on. Learn these once and the till’s reference page stops being a list of screens.

One bill, followed through

Saturday afternoon at GS-KV-03. A member buys a pair of wireless earbuds and a case: RM 1,000 of goods, RM 60 of SST, RM 1,060 on her card. The cashier presses Final, the receipt prints, and she is out of the door in under a minute. Behind the counter the bill has only just started.

Nine consequences, one keystroke. Every row below the first is a separate job that your tenant switches on separately, which is why the rest of this page keeps saying “where that job runs”. The figures are illustrative; the arithmetic is the product’s.

1. FINAL is the only moment that matters

A cash bill has a posting status. DRAFT means nothing has happened: the bill is editable, the ledger has not heard of it, and no stock has moved. FINAL is the event — but it is not a save and it is not one call. Pressing Final writes the status, allocates the branch and device running numbers, and queues a job that asks what else should run. Everything a cashier thinks of as “the sale” — the journal, the cashbook line for each settlement, the stock movement, the member’s points, the e-invoice pool row — is done afterwards by separate processors, each in its own transaction. VOID queues a different job with a narrower fan-out: thirty-two subscribers are registered for Finalise and eleven for Void, of which ten apply to a cash bill.

What decides which of the thirty-two run for your bill is a lookup, not a list. Three things settle it: which processors are linked to Finalise centrally; whether your tenant holds a trigger configuration for each one — there is no default-on, and nothing at the counter shows which are held; and whether the company carries an include or exclude list that narrows the run further. So “FINAL posts the journal” is true of a normal installation and is not a law: a counter with no journal subscriber behind it finalises cleanly and produces no journal, ever, and no GL mapping will change that. The mechanism is on POS General › What FINAL sets off.

Three consequences people meet the hard way:

• Nothing stands between a cashier and FINAL except having the applet installed. There is no sign-off step (see §3).
• It is not instant, and “it did not post” is usually “it has not finished yet”. On a busy Saturday a stock line or a journal can appear a moment after the bill itself. Telling the two apart before escalating is a real skill and it is worth teaching: how work actually runs.
• A void is not a rewind. Several things Finalise starts have no void counterpart at all — the traded-in unit register among them, which means a voided trade-in leaves its unit standing. What a void undoes, what it leaves on purpose, and when BigLedger refuses one outright are on What a void undoes.

One thing the till deliberately never sets off: the webhook. The document webhook and the sales-contract processor are queued only for a sales invoice, so an integration subscribed to document events hears nothing when a shop sells something. Cash bills reach an integration through the API and the e-invoice chain instead.

Why it is built this way. The moment of sale is kept cheap and uninterruptible, and everything expensive, fallible or regulated happens on the reporting side, asynchronously, with a sweeper behind it. The cashier’s screen never pays for nine postings; a failed journal never holds up a queue of customers; a tenant that runs no loyalty scheme simply has no points subscriber; and a new subsystem is a new subscriber rather than a change to Finalise. The cost of that design is the one this page keeps returning to — a bill can be FINAL, printed and handed over while its journal is not there yet or has failed — and the product’s answer to it is a set of screens that infer a missing posting from its absence (§6), not an alert.

2. What a cash bill posts

The cash bill’s document type carries amount signum +1 and quantity signum −1 on every line: money in, stock out. At FINAL that is Dr the settlement methods’ cashbook GL codes / Cr Sales and Output Tax, and a stock movement out of the line’s location. There is no cost-of-sales line on the bill’s journal — the sales journal has seven lines it can post to, and cost of goods sold is not among them. The ledger gets its cost of sales from the month-end run.

That makes it the retail twin of the Sales module’s invoice — the same journal handler, the same point generation — and the two are counted together by the sales reports and the commission run. The full family of sales documents and what each one posts is on the Sales module’s core concepts.

Where did this number come from?

At the counter that question has a different answer for every figure. Some are stored when a job runs; some are worked out the moment you open a screen; one is worked out in your browser from the server’s sums.

Two of those rows cause more cash-up arguments than the rest together. The cashbook is lower than the till by a computable amount — the method’s charges, which the acquirer’s own figures will also show, and which is why the cashbook is the figure Bank Reconciliation can match. And the Z Report’s Variance line is not a drawer variance on any counter that takes a card. The whole cash-up, in order, is POS General › Reconciling a cash-up.

3. The one approval at the till, and the one hard stop

Nothing is approved. BigLedger’s document-approval engine covers three document types only — Purchase Order, Purchase Requisition and Stock Requisition. No cash bill consults it. The one approval-shaped thing at the till is the sell-below-price request: a cashier who tries to go under a floor price can raise a request naming an approver, and a supervisor holding the approve-sell-below-price permission releases that one line. It routes nothing and signs off nothing else. The floors and the ceiling apply to basic (stock) items only: a service, a GL-code item or any other kind of line is not checked against them and raises no request, so a pricing rule for those lines is the supervisor’s to check after the sale.

It is worth knowing exactly what that release is, because it is the product’s only built-in separation of duties. The approver authenticates on the cashier’s own terminal with their Akaun login — an e-mail address or mobile number and a password, together — and the till releases the line only if the authenticated person is the approver the request named; anyone else is refused with “User is not the assigned approver.” The grant is kept as a one-time request-history row naming who approved what. So the record is trustworthy, and the trade-off is that a supervisor types their own credential at a shop-floor terminal. Decide that consciously rather than discovering it.

Everything else that separates a cashier from a supervisor — discount, void, edit price, sell below cost, close session, cash in and out — is a plain client-side permission on POS General with no approver step at all. Whoever holds it can use it on their own work, silently. That is the gap your branch procedure has to cover, and how to cover it is on Best practices.

No credit limit, one hard stop. A cash bill has no credit limit to check. The one hard stop on a customer is the blacklist, which rejects the bill with Customer is blacklisted due to credit limit / credit term. That is somebody’s credit-control decision arriving at the counter, not a fault — the cashier’s job is to name who can resolve it, not to find a way past it by selling to a different entity. A customer’s spending limit is not checked at FINAL either: it is computed by a job after the bill, which suspends the entity rather than refusing the sale, so a bill that breaks a limit always goes through and the counter’s own quota check is what stops the next one.

Member labels are not read at the counter

This is the one that costs marketing a launch. A pricebook can carry a Member Label rule, and the till’s calculator treats that rule as satisfied whatever labels the member holds — it tests the date range, the branch, the entity type, the customer code, the member class and the employee and customer categories, and nothing else — so a label rule widens a price set at the counter instead of narrowing it. A commission scheme’s Member Label rule is weaker still: it passes for any member who holds any label at all. The web store and the OCR receipt processor do compare labels, which is why a label looks like it works in testing online and then pays every member at the till. The rule that survives contact with the counter: a label is an online and marketing segment; a class is a counter segment. If the behaviour you want is a price or a commission at the till, qualify by member class — the whole table of who reads a label is on Member labels.

4. How a wrong bill is reversed

    flowchart TD
  Q{"What went wrong?"}
  Q -->|"The whole bill was a mistake,<br/>same day, at the till"| V["VOID the cash bill<br/>(ten subscribers, not thirty-two)"]
  Q -->|"Goods are coming back later"| R["Sales Return<br/>stock in, sale reversed"]
  Q -->|"Money back and goods back"| RN["Sales Refund Note"]
  

VOID is the till’s own action. Sales Return and Sales Refund Note are documents of the Sales module.

Which of these to use is a judgement, not a lookup, and it is made in front of the customer: is the original sale wrong (void), or was it right and the goods are coming back (return)? Getting it wrong is not a posting error you can see — it is a day’s figures that quietly stop meaning what the branch thinks they mean.

The walk-in who comes back wanting an e-invoice in his company’s name is the case that shows why the choice matters. The account on a FINAL bill does not change, so the reflex is a return, a new invoice under the company’s account and a contra between them. Read that through the table at the top of this page: stock goes back in and out again, and the return is a stock-in at the return’s cost, so the item’s moving average shifts for every branch; no money actually moves, so a refund and a fresh receipt through the cashbook would be two phantom lines a bank reconciliation can never match; the member’s points follow the account; and three reportable documents replace one. If only the name on the tax document has to change, change the e-invoice buyer and leave the bill alone — in the My E-Invoice Admin pool while the receipt is still waiting to be reported, or by the customer in the portal. The reversal is for the case where the account must change. The routes, and the fact that the cheap ones expire once the receipt has been consolidated, are on the consolidated e-invoice page.

When e-invoicing is on, the void rules split by document. A sales return, refund note, invoice, credit note or debit note cannot be voided from any Void button or through the void API while the company’s e-invoice status is enabled, whether or not it has been submitted; the one route to a void is the e-invoice cancellation’s Void original document, which voids the document once LHDN accepts the cancellation, and after the 72-hour window the correction is a credit note (Cancelling and correcting a validated e-invoice). The cash bill is the exception, and today the exception is wider than designed. The refusal for a cash bill was meant to bite only while its e-invoice was Submitted and in flight; since 25 September 2026 the check looks the submission queue up by the wrong key, finds nothing, and answers eligible for every bill (a known issue, reported to engineering). So what happens today is this: pressing VOID on a cash bill succeeds whatever its e-invoice status — queued, Submitted or Valid — the bill reverses, the void takes the bill out of the submission queue only while it has not been submitted, and a Valid e-invoice stays Valid at LHDN with no sale behind it. Nothing on the till warns you. The sequence to teach is therefore the same one the till lesson already teaches: cancel the e-invoice first, within 72 hours of validation, and void the bill only once the cancellation is accepted — and after 72 hours, do not void at all; raise a credit note.

5. When it goes wrong — what you see, why, what to do

6. How you know a bill finished

Nothing on the till answers this: the counter shows FINAL, prints and moves on, and the Cash Bill Listing has no posting column. The thirty-second check lives in two other applets, and it is worth running once on the first bill of every new branch and every new settlement method, before the first night’s cash-up depends on it.

1. One bill. Open Financial Report › Error Checking › Trace Document, choose the cash bill as the server document type and type the bill’s Doc No from the Cash Bill Listing. You get the bill’s date, amount, posting status and posting journal, and the Missing Journal and Missing Cashbook checks either side of it. Both checks passing and a posting journal shown mean the chain ran.
2. The money. Open Cashbook › Enquiries › Query Cashbook Transaction on the settlement method’s cashbook, type the same Doc No in the keyword box, and read the line: its amount should be the tender less that method’s charges, dated the bill’s transaction date. Click the row and the Journal tab beside it is the double entry.
3. The stock. Stock Balance for that item at the branch’s default location is one lower.
4. A whole day, when you would rather not do this bill by bill: Ledger And Journal › Error Checking › Missing Journal for the cash bill type and the trading date lists every FINAL bill of the range with no journal behind it, with branch and amount, so you can total what is missing before fixing anything. An empty list is the result you want.

What none of these tells you is whether a subscriber is switched on at all — each infers a failure from an artefact that is absent, and nothing raises an alert when a posting job fails. So the distinction to establish before changing anything is the first row of the table above: one bill missing its journal is a repair, every bill missing it is the subscription.

Who runs this, and when: the branch supervisor, as the third of the three daily reconciliations, and finance, on the first trading day after any change to a settlement method or a company default GL code. How they know they got it right: the Missing Journal list for the day is empty and the Cash row of the Z Report agrees with the drawer by the arithmetic above.

7. Where the cash bill sits in the product

What must exist first, and how you find out it does not. A branch with a default location — FINAL refuses a bill whose location is not it. Settlement methods linked to the branch, each naming a cashbook and a GL code — without a link there is no payment button; with a link and no cashbook the bill finalises and the posting fails with a missing-cashbook message in Trace Document. A receivable default GL code for the walk-in customer’s AR/AP type — the one company default whose absence actually raises an error on a cash bill; an unmapped sales, return or output-tax code raises nothing and lets trade debtors absorb the line. And a settlement-charges code the moment any method carries a charge. The ordered list is Configuration.

What becomes possible because the bill exists. The month’s consolidated e-invoice, built from the pool rows FINAL bills leave behind; bank reconciliation against cashbook lines that already carry the acquirer’s net; loyalty — points earned on the bill and redeemed as a settlement or a points-discount line; commission, which credits the bill to whoever the sales agent resolution chose; and the Sales module’s reports, which count cash bills beside invoices.

Its sibling, and when to choose which. The sales invoice is the same journal handler with credit terms: choose it when the customer pays later, when the document must be dated more than a week back (the till’s backdate stops at seven days), or when an integration must hear about the sale, since only the invoice raises the document webhook. Choose the cash bill when the money arrives with the goods. The other pair worth naming is the two Z Reports: the till’s, which reads cash bills only and carries the session and drawer blocks, and Daily Cashier Reports’, which reads four document types and carries neither. They disagree by design on any day with a standalone return or an invoice.

What breaks elsewhere if this is wrong. A settlement method pointing at the wrong cashbook breaks bank reconciliation for every branch that links it, since one method is shared by all of them. A missing charges code moves card fees into trade debtors and corrupts the ageing’s agreement with the ledger. A cost-of-sales expectation at the till — looking for a COGS line on the bill’s journal — sends finance hunting for a posting that is a month-end job. And a bill backdated into a day already signed off moves the Z Report, the cashbook line and the journal together to that day, which is the point of backdating and also why the bill is invisible on the day it was sold.

What it pairs with in practice. The journal and cashbook subscribers travel together — the cashbook line is the reconciliation’s half of the same posting — and a tenant that holds the journal subscriber and not the cashbook one has sales in the ledger and nothing for the bank side to reconcile against. Membership is the pairing that changes the counter most: once a member is on the bill, point lines are written on save and the points subscriber posts the transaction, and the member class becomes the dimension the till actually prices by. And e-invoicing pairs with the void rules above: switching it on is the day the cash bill’s void stops being a plain reversal.

Read next