One Invoice, Followed Through

One sales invoice, followed through all four ideas

The scenario is an ordinary credit sale, followed through the four ideas in Platform Concepts. Read it when you want to see all four at work on one document, or when a figure on an invoice of your own needs explaining and you want to know which idea it comes from.

The sale

GadgetSphere Sdn Bhd (company code GS) sells one ultraportable laptop from branch GS-KV-01: RM 4,200 plus RM 252 SST at 6%, RM 4,452 in all. GS has e-invoicing switched on. Here is what each idea says about that one invoice.

Before Finalise, it is a generic document. The sales invoice is a header and its lines in the same record a purchase invoice or a cash bill uses; only its document type, INTERNAL_SALES_INVOICE, says what kind it is. It gets its tenant number at the first save. The customer’s name, contacts and address are copied onto the invoice when you pick the customer, so a change to the customer record next month leaves this invoice as it was issued. The branch sits on the header and on every line, which is why the revenue code is SALES-LAPTOP with no branch in it: the journal line already knows its branch.

Settings and permissions have shaped it before anyone presses anything. There is one Sales Invoice settings document for the whole tenant, so a toggle saved at a Penang branch governs this Klang Valley invoice, and the same toggle reaches all three companies. Whether the server checks stock at Finalise is one of those toggles; while nobody has saved the panel, the server checks. Who may still change the sales agent after Finalise is a setting, for everybody. Who may back-date the transaction date is a permission, granted to a role.

Pressing Finalise sets off the rest, in this order:

The checks. The stock check, where it is on, runs first. If GS-KV-01 has no laptop to sell, Not Enough Stock for item … comes back and nothing is saved.
The status. The invoice becomes FINAL, and the company and branch numbers are stamped on it.
One queue row, for the primary job. Your screen comes back here, before anything has posted.
The fan-out. The primary job looks up which follow-on jobs your tenant subscribes to — up to thirty-two — and queues each one: journal, stock, knock-off, e-invoice, membership points. Those run in no order you can rely on.
The one fixed sequence. The stock job moves the laptop out, the stock balance job updates the row for GS-KV-01, and the costing job writes the cost back onto the invoice line. That is a chain, so it always runs in that order.

The journal job writes three lines: debit DEBTOR-TRADE-RETAIL 4,452.00, credit SALES-LAPTOP 4,200.00, credit LIAB-SST-OUTPUT 252.00. There is no cost-of-sales line; month-end processing writes that. The e-invoice job puts the invoice into a pool, and a scheduled run submits it to LHDN.

Where each figure on and around this invoice came from:

Figure	Stored or worked out	When, and from what
The tenant number	Stored	At the first save, from the counter for that document type
The company and branch numbers	Stored	At Finalise; a draft has neither
The customer’s name and address on the invoice	Stored, a snapshot	Copied when you picked the customer. The customer’s receivable type, which picks the debtor account, is read live at posting
The three journal lines	Stored	Written by the journal job after Finalise, from the GL codes on the item and the company’s defaults
The cost on the invoice line	Stored, and rewritable	The company’s moving average as at the line’s date, written by the costing job; a purchase keyed later but dated earlier rewrites it
Stock on hand at `GS-KV-01`	Stored row	Updated by the stock balance job after each Finalise
What the customer still owes	Worked out	Each time you run the statement, from the open amount stored on the invoice and the payments knocked off against it
The aging for a past month	A monthly snapshot	Taken in the early hours of the 1st of the next month

Two things can go wrong after Finalise, and neither appears on your screen. If GS has no default GL code for its trade debtors, the journal job stops with MISSING_DEFAULT_GL_CODE: DEBTOR and the invoice is left without a ledger entry. If no GL code for sales or output tax is found, on the item or as a company default, that line is left out and the debtor line absorbs it, so the journal still balances and is wrong. Nobody is told in either case.

Undoing it is narrower than it looks. Because GS has e-invoicing switched on, the Void button refuses this invoice. Inside 72 hours of LHDN validating it, the route is the e-invoice cancellation, whose Void original document choice voids it once LHDN accepts. After that, raise a credit note. A void also needs every document raised from this one voided first, newest first. Where a void does go through, on a company without e-invoicing, it is a second set of entries, not a delete:

a reversal journal dated with the original transaction date, so a January invoice voided in March changes January;
an opposite stock line marked VOID, so Stock Movement shows two lines and the balance is right;
the payment applied to it unpicked, so the receipt becomes an unapplied credit again;
the document’s aging snapshots removed for every month, not only this one;
the number kept, never handed back.

A void fans out to ten follow-on jobs against Finalise’s thirty-two, and each void job is a subscription of its own. Holding the posting job is no guarantee of holding its reversal.

What these pages will not tell you, and who finds out instead

Which follow-on jobs your tenant subscribes to. That is a per-tenant fact. Your Scheduler listing shows the scheduled jobs. For the subscriptions, the thirty-second check on one test invoice shows whether the journal and stock jobs run for you, and BigLedger can confirm the rest.
That a job failed. A failed posting raises no alert. The person who keeps the books finds it by running the Stock Flow Report in the Financial Report applet on a fixed day each week, and a difference column that is not zero is the sign.
Whether to void or correct. A void lands in the original period. The accountant decides, by looking at the document’s date against the last period you closed, and raises a credit note in the current period when that period is already reported. The closed month’s reports still reading as filed is how they know it was the right call.
Who should be able to back-date. That is a decision about separating duties. The person who owns the books’ controls makes it and grants the permission on a role, never to everyone, then asks somebody without the role to open a finalised invoice: the date should stay locked for them.

The four ideas in the rest of BigLedger

What must exist first. A company’s default GL codes in Chart of Account, knock-off pairs in the Organization applet if invoices are raised from orders, and roles in Teams and Permissions. The setup order is on Getting Started.

What becomes possible. Every module page reads the same model, so the Sales, Financial Accounting, Inventory and E-Invoice modules explain their own screens without explaining Finalise again.

The sibling, and when to use which. Use the Platform Concepts pages when you want to know why. Use Troubleshooting when you have a symptom and want the fix, and the Core module when you want the reference for one shared applet.

What breaks if it is wrong. One missing default GL code affects every invoice of that company, from every branch. One careless save of the Sales Invoice settings reaches all three companies at once.

What it pairs with in practice. Trace Document, in the Financial Report applet, alongside the Scheduler listing.

More shared explanations, in their modules

Not everything cross-cutting has moved into Platform Concepts yet. These are the ones already written, in the module they grew up in:

When two numbers don’t tally — five figures that will not agree, each with its check, and which of them you should believe for what
Document numbering — the single counter table behind every running number, the pool that keeps two tills from waiting on each other, and what you can and cannot change

One sales invoice, followed through all four ideas

The sale

What these pages will not tell you, and who finds out instead

The four ideas in the rest of BigLedger

More shared explanations, in their modules

Related documentation