What Malaysia Requires: BigLedger's Part

What Malaysia Requires: What BigLedger Does About It

Part 2 of What Malaysia Requires: what BigLedger does about each of LHDN’s rules, and what it leaves to you. The rules themselves — who must comply and from when, what an e-invoice holds, the 72 hours, consolidation by the 7th — are on the first part. Who does what, the common mistakes and the five checks that close the loop are kept there too, because each spans both parts.

Your date is a decision BigLedger does not hold

Everything under Who has to comply, and from when is LHDN’s rule, and BigLedger knows none of it about you. A company record holds its e-invoice credentials and switches, and no implementation date, no turnover and no exemption. The one thing that decides whether a document goes to LHDN is the company’s E-Invoice Status (Organisation Applet, E-Invoice tab), and BigLedger reads it at the moment each document is finalised. A document finalised while the status is anything but ENABLED is passed over: no pool row, no error, and on the default schedule nothing later goes back to look for it.

So the decision is yours, and it has three parts:

Who decides. Whoever owns the figures, with your tax agent, per legal entity. In a group the answer can differ by company — GadgetSphere Sdn Bhd, GadgetSphere Online and GadgetSphere Distribution are each switched on their own record.
When. Set the status to ENABLED before the first document dated on your implementation date is finalised, not on the morning you notice. Write the date and the reasoning down — §1.5 says it never moves again, and in two years nobody will remember why.
How you know it is right. On the first trading day, finalise one ordinary sale in each enabled company and find it in the My E-Invoice Admin applet — in a pool or on To IRB E-Invoice — within the hour. If a company was switched on late, list the documents it finalised in between and send the numbers to BigLedger support, who can push named documents into the pipeline.

Where BigLedger takes the seller and the buyer from

The seller block is read from your company record at the moment BigLedger checks the document — not copied when the document was keyed. One missing field there — the tax number, the industry classification code, the contact number — parks every document the company sends, all at once, each pool row naming the same Supplier field. Correct the company record first, then resubmit the parked rows; they are checked again against the corrected record.

The buyer block comes from the first of three places that is filled in: the document’s own e-invoice buyer block, then its e-invoice entity block, and only then the customer record, read at the moment of the check. That order is deliberate. The buyer LHDN sees does not have to be the account you billed. A shopper buys a laptop at GS-KV-01 as a walk-in cash customer, and two days later their employer asks for the e-invoice in the company’s name. While the receipt is still waiting to be reported, you complete the buyer block in the My E-Invoice Admin applet and send it: the sale, the cash and the stock stay exactly as they were, because nothing about who paid has changed — only who LHDN records as the buyer. Once the month’s consolidated e-invoice has taken that receipt, this cheap route is gone; Cancelling and Correcting a Validated E-Invoice has the others.

What happens between Finalise and Submitted

Finalise does not talk to LHDN. It hands the document to a chain of scheduled jobs, and on the default schedule each hop runs every 10 to 30 minutes:

The entry test, at Finalise. The document must be final, an e-invoice document type, not marked Skip E-Invoice, and its company ENABLED. A sale marked Consolidated goes straight to the Batch Pool to wait for month-end — or to the Individual Pool if it is RM 10,000 or more (see The large sale, one sen lower). Everything else goes into the posting queue.
The field check, within about ten minutes. BigLedger checks the mandatory fields. A document that passes is queued for submission. One that fails is parked in a pool, with the missing field written on the row.
Submission, within about ten more. The submitter sends queued documents to LHDN and the record reads Submitted.

Outside the Batch Pool, which the month-end run empties, a pool waits for a person, indefinitely — and that is the point. BigLedger never guesses a buyer’s tax number to get an individual e-invoice out of the door, so a document that is not ready is never sent as one. The cost is that nothing ages it out: an Individual Pool row from March is still there in June unless someone works the pool. Pools and Queues explains every hop and what empties each pool.

An idea worth having: the documents do not have to be keyed in BigLedger. A business whose till or webstore runs on another system can send its sales into BigLedger and let BigLedger be the part that talks to LHDN. An imported document goes through exactly the same entry test — which means it must arrive final, because a draft never reaches the e-invoice pipeline, and nothing reports that a batch landed as drafts.

Where Valid, and the 72 hours, come from

Valid and Invalid in BigLedger are a copy of LHDN’s answer, written back by a status check that runs every ten minutes on the default schedule, twenty documents a run. So a document can read Submitted for a while after LHDN has already decided, and MyInvois and BigLedger can briefly disagree. The Refresh button on To IRB E-Invoice asks LHDN again for that one document.

The 72 hours are counted from LHDN’s own validation time-stamp, which BigLedger stores as LHDN sent it — not from your invoice date, and not from when you pressed Finalise. When you ask to cancel, BigLedger counts the hours on its own server, in whole hours, and refuses at 72 with “Passed 72 hours from validation date time”. The cancellation button on the screen, though, decides whether to light up using your computer’s clock, at the moment you open the record — so a lit button late in the window is not a promise. Read the validation time from the Submission Detail Report, add 72 hours, and decide with an hour in hand.

Which month a receipt belongs to, and when it leaves

A receipt belongs to the calendar month of its own date, in Malaysian time. The automatic run starts on the 1st, takes only last month’s receipts from the Batch Pool, groups them by company and document type, and dates each consolidated e-invoice on the last day of that month. A sale rung up at 11:58 pm on 31 March is a March sale; one at 12:03 am on 1 April waits a whole month.

Nothing consolidated leaves before midnight on the 1st. The consolidated submitter sends only e-invoices dated before 00:00 Malaysian time on the first day of the current month — so there is no early submission for a month still in progress.

Do the arithmetic on your own volume, because the default schedule is not sized for it. By default the run takes 100 receipts every 30 minutes. If 38,000 GadgetSphere receipts are in the Batch Pool on the 1st, that is 380 runs — the last batch is built on the evening of the 8th, a day after LHDN’s window has closed. Divide your own month’s Batch Pool count by 200 to get the hours it needs. If the answer is more than about 140 (six days), have the batch size raised on your tenant’s consolidation clock — it is a setting on that clock’s row in the Scheduler applet, set per tenant, and BigLedger support can set it with you.

The consolidated-submission switch, and what it does not govern

Each company has a Disable Consolidated Submission switch. Both of these are true, and you need both:

It does what it says at the point of choice. With it on, Consolidated disappears from the submission-type drop-down on the company’s back-office sales and purchase documents (not at the till: Consolidated e-invoices), so nobody keying one there can choose it. That is the right control when the wrong choice would be a person’s.
It does not stop the month-end run. The automatic run builds the consolidated e-invoice and marks it consolidated itself, and it never reads the switch. A cash bill from the till that reached the Batch Pool — the till leaves the type blank, and a sale under RM 10,000 with no buyer details lands there — is consolidated on the 1st whatever the switch says. If your policy is “no consolidated e-invoices at all”, the switch alone does not deliver it: whoever closes the month has to clear every last-month receipt out of the Batch Pool before the run reaches it on the 1st.

The large sale, one sen lower

From 1 January 2026 LHDN bars consolidation of any single transaction exceeding RM 10,000, except for a taxpayer still inside its interim relaxation period (The large sale). BigLedger applies its own line one sen lower. A sales invoice or cash bill marked Consolidated is diverted to the Individual Pool at RM 10,000 and above, not above RM 10,000 — so a sale of exactly RM 10,000.00 is diverted here although the guideline would still allow it in a consolidation. That is deliberate: erring on the safe side of a tax rule costs you one extra individual e-invoice and never a compliance failure. Pools & Submission Routing explains how the sorting works and which document types it covers.