Consolidated e-invoices

Watch these as presentations — 2 on this page, slides with narration.

12 slides · about 9 min · Run the month-end e-invoice cycle, 1 of 5

10 slides · about 10 min · Run the month-end e-invoice cycle, 2 of 5

“Do I have to issue an e-invoice for every counter sale?” No. A consolidated e-invoice is one e-invoice that reports many small sales at once: rather than sending LHDN a separate e-invoice for every till receipt, you send a single document covering a whole month of them, with the buyer recorded as General Public instead of a named person. Each receipt inside it stays traceable — BigLedger writes the consolidated e-invoice’s reference onto the receipt and keeps a link row per receipt — but LHDN receives a handful of documents instead of tens of thousands.

This page is the picture behind the Batch Pool: what BigLedger builds, from which clock, where every figure on the finished document comes from, what goes wrong between the 1st and the 7th, and how you know last month is reported. The steps are in The Month-End E-Invoice Cycle.

Why it exists

Malaysian e-invoicing asks you to report every sale. It does not ask you to know who every buyer is. A shopper who buys a phone charger and walks out has not given you a tax number, an identity document or an address, and no amount of chasing afterwards will produce them.

The worry this produces in a finance team is specific, and it arrives in the same words: if we finalise a sale with no buyer tax number, does that invoice just sit there? Are we already non-compliant? The answer is that the sale is not stuck; it is routed. The till takes the money and finalises, the books and the stock are right, and the e-invoice question is parked in the Batch Pool with the reason written on the row. Reporting it is deferred to the month’s consolidated e-invoice, which is LHDN’s own provision for exactly this buyer — and that document must be validated by LHDN by the 7th of the following month.

The scale is the point. GadgetSphere Sdn Bhd’s 22 branches ring up roughly 38,000 receipts a month. Reported individually, that is 38,000 e-invoices, 38,000 buyer identities to collect and 38,000 chances to get one wrong — or a cashier asking every shopper for a tax number while the queue grows. Consolidated, it is a few hundred e-invoices — one per batch the run takes, per company and document type — that a person can actually check before the 7th. Of those 38,000 receipts, the few hundred where a buyer asked for their own e-invoice, or spent RM 10,000 or more, go out individually; everything else travels this road. For a retailer it is the main road, not the exception.

How it behaves in BigLedger

Nothing is consolidated at the moment of sale, and nothing on the screen says what will happen next. This is what does.

What happens between the till and LHDN

When	What BigLedger does	What you can see
Finalise	A background job reads the receipt once. Submission type Consolidated: a sales invoice or cash bill of RM 10,000 or more goes to the Individual Pool with the reason Amount transaction is greater or equal to RM10000; anything else marked Consolidated goes straight to the Batch Pool with no further check. A blank type goes to the Posting Queue, and if the buyer’s mandatory fields fail there, a receipt under RM 10,000 lands in the Batch Pool with the missing fields named — an Individual one that fails waits in the Individual Pool instead	A Batch Pool row, `UNPROCESSED`, usually red with a Validation Error. Red here is normal: it records why the receipt could not be an individual e-invoice
From the 1st of the next month	The consolidation clock fires — by default every 30 minutes — and each firing takes up to 100 of last month’s unprocessed sales rows. First it sweeps in last month’s individual e-invoices under RM 10,000 that LHDN rejected (`Invalid`) or refused when they were sent, then it builds. The rows it took are grouped by company and document type, and then by the receipt’s own calendar month, and each group becomes one consolidated e-invoice — so a month is not one document but one per batch: 38,000 receipts at 100 a firing is a few hundred consolidated e-invoices, and none of them mixes two months	The rows turn `PROCESSED / SUCCESS`; new rows appear under Internal Submission → Consolidated Submission, buyer General Public
Every 20 minutes, by default	The consolidated submitter — up to 49 a firing — sends each queued consolidated e-invoice whose date falls before the first day of the current month	The record on To IRB E-Invoice moves from `IN_CONSOLIDATED_QUEUE` to `Submitted`
After LHDN answers	The status poller copies LHDN’s verdict onto the record	`Valid`, or `Invalid` with LHDN’s reasons

Two things follow that the screens do not show. There is no consolidation day. Last month is worked through in batches from the first firing of the new month; at the default a GadgetSphere-sized month of 38,000 receipts is 380 firings, which is why the interval and the batch size are set per tenant on the Scheduler row, and why the 7th is a deadline the batches must beat rather than a run date. And the schedule belongs to the tenant, not the company. One clock serves every company in the tenant, and a clock switched off stops consolidation for all of them at once (Pools and queues).

What BigLedger puts on one, and where each figure comes from

Every value on a consolidated e-invoice is written once, at the moment the run builds it, from the receipts it took. Nothing on it is read live from a customer, an item or a later edit.

On the finished e-invoice	Where it came from
Buyer — General Public, identity type Passport, identity “NA”, every address and contact field “NA”, tax number `EI00000000010`	Constants in the run, read from no customer record. The by-branch run is the exception: it carries the general tax number its group was keyed on, so it can also build one addressed to the foreign-buyer or government general number — under the same name, General Public
Supplier	Your company record, copied at the build
Lines — by document: one line per receipt, item Consolidated Item, description the receipt’s document number, quantity 1, amount the receipt’s total; by branch: one line per consecutive run of a branch’s document numbers, capped at 200 lines before the next document starts	The receipts’ header totals. The by-document path has no line cap: the 100-row batch is what bounds one e-invoice
Classification `004` Consolidated e-Invoice on every line	Written by the run, never read from the item. The code is LHDN’s marker for a consolidated line
Totals	The sum of the receipts’ own header amounts — total, tax, discounts — at the build
Date and e-invoice date-time	The last day of the receipts’ month, not the day the run fired; billing period the first to the last day of that month. A run on the 3rd of November that builds October’s receipts dates the e-invoice 31 October
Currency MYR, billing frequency Monthly, trade and customs fields “NA”	Constants
The reference on each receipt	Written onto the receipt when the run builds the e-invoice, before anything is sent. A receipt carrying a consolidated reference has been built into a document, which is not the same as reported: `Valid` on the record is the only word that means LHDN accepted it

Because the buyer block is constant, nothing you correct on a customer record changes a consolidated e-invoice, before or after the build. A named customer’s receipt that sits in the Batch Pool is reported as General Public unless somebody pulls it out first.

The two boundaries

RM 10,000 — LHDN’s line and BigLedger’s, one sen apart. LHDN bars consolidation for a single transaction exceeding RM 10,000, in all industries, from 1 January 2026 (e-Invoice Specific Guideline 4.9, §3.7.2, Table 3.6 row 7); such a sale needs an individual e-invoice with the buyer’s real identity. BigLedger applies its own test at RM 10,000 and above, so a sale of exactly RM 10,000.00 is diverted too. The divert covers a sales invoice or cash bill: at Finalise it goes to the Individual Pool with the reason on the row, and a manual move into the Batch Pool is refused with “Cannot move transaction with amount more than or equal to 10000.” Any other consolidatable type of that size is yours to check by hand before the run. The interim relaxation period LHDN granted is not modelled anywhere in BigLedger, so a large sale you are entitled to consolidate still has to be moved out of the Individual Pool by a person (which versions we cite).
Foreign buyers. A customer paying on a passport is keyed with identity type Passport and their sale goes out on its own, with their real tax number. Consolidation is not a fallback for them: with no tax number on the receipt either run reports the sale as General Public — the by-branch run gives the row the General Public number before it groups — which is not an e-invoice the buyer can use. Whether LHDN accepts a foreign buyer inside a consolidated e-invoice at all is a question for your tax adviser — the by-branch run can build one, and that is not the same as it being the right thing to file.

Two runs, and the one your tenant has

BigLedger contains two consolidation runs, and the finished document differs: by document groups by company and document type and prints one receipt per line with no branch on the header; by branch groups each branch’s month into its own block, prints document-number ranges, and keeps the branch on the e-invoice. The by-document run is the default clock on a new tenant; the by-branch run is a clock support schedules in its place. Which one yours is on is a Scheduler row, not a setting on the company record — the company’s Batch Line Logic field records what was agreed and is read by neither run (the two methods side by side).

The switch that governs the choice, not the run

On the company’s E-Invoice tab, Disable Consolidated Submission removes Consolidated from the Submission Type drop-down on every sales and purchase document of that company. That is enforcement at the point of choice, and it is the right shape for a distribution company whose every sale is business-to-business: nobody can pick the option by accident. It is not a control on the run. The automatic consolidation stamps Consolidated onto the documents it builds and reads the switch at no point, and a receipt that reached the Batch Pool another way — a blank submission type whose buyer fields failed — is consolidated regardless. Both halves are true, and BigLedger has confirmed the switch is meant to govern the choice only. A per-item-category default e-invoice submission type also exists in the data model; at the current backend the only things that read it are a listing filter and a keyword search, so it decides nothing about which pool a receipt enters.

What goes wrong between the 1st and the 7th, and what to do

What you see	What it means	What to do
Last month’s Batch Pool rows still `UNPROCESSED` on the 3rd	The consolidation clock is off or slower than your volume	Open the Scheduler: `E_INVOICE_BATCH_PROCESSING_CYCLE_RUN_PROCESSOR` (or the by-branch processor) should be `ACTIVE` with a recent Last Run Date. Then select the rows and press Consolidate yourself; the button has no tax-number test and no date window
A Batch Pool row dated two or more months ago, still `UNPROCESSED`	Outside the automatic run’s window, which is last month only	Consolidate it by hand. It will be late, and it is dated the last day of its own month, which is the month LHDN counts it in
A Batch Pool row at `PROCESSED / FAILED`	Stranded: somebody pressed Process or Save and Resubmit, the buyer check failed again, and the row left the run	Move to Individual, then Move To Batch Pool, which replaces it with a fresh unprocessed row (the round trip)
A sale of RM 10,000 or more is “missing” from the month’s consolidated e-invoice	It was diverted to the Individual Pool at Finalise, with the reason on the row	Complete the buyer’s identity and Save and Resubmit; it goes out as its own e-invoice. Decide this before the 7th — the row ages silently
A business customer who wanted their own e-invoice finds their sale inside the consolidated one	Their individual e-invoice was `Invalid`, or still `IN_QUEUE` after LHDN refused it, when the month closed, and the run swept it in under General Public. Before 13 October 2026 the run took a never-sent `IN_QUEUE` record instead and left `Invalid` ones	Inside the month, read LHDN’s reasons on the record or the error on the submission-queue row, fix and resend. After the run, the receipt is inside a validated tax document; correcting it is now a document decision for your accountant, by the routes in Cancelling and Correcting
An `Invalid` individual e-invoice from last month disappeared from To IRB E-Invoice	Since 13 October 2026 the run sweeps `Invalid` records under RM 10,000 of a month that has ended, the same as those LHDN refused at the door, and retires them	Nothing is lost: the sale is inside the consolidated e-invoice under General Public. Fix and resubmit a rejected e-invoice whose buyer needs their own before the run fires for its month
A consolidated e-invoice reads `Invalid`	LHDN rejected the whole document; the reasons are on the record	Fix from To IRB E-Invoice (§5). Every receipt inside it is unreported until it is `Valid`
A consolidated e-invoice was cancelled and the month’s receipts have “disappeared”	Cancellation cancels the document; the receipts keep their reference and their links and do not return to the Batch Pool	Ask support to push the named documents back to the Batch Pool — a re-run for the period would sweep in everything else as well (what a cancellation leaves behind)
A walk-in comes back on the 3rd wanting their own e-invoice	Their receipt is still in the Batch Pool only if the run has not reached it yet	While the row is `UNPROCESSED`: complete the buyer on the row and Save and Resubmit, or let them key it in the customer portal. Once consolidated, the cheap routes are gone (the walk-in who comes back). A shop that tells shoppers ask before the end of the month and it costs nothing has understood the system

What it will not do

It will not lift one receipt out of a built consolidated e-invoice. Cancellation is of the whole document, and the other receipts are not returned to the pool by it.
It will not read a customer’s details into one. The buyer block is fixed; a receipt with a complete buyer that is sitting in the Batch Pool is reported as General Public unless a person moves it first.
It will not look further back than last month. Older Batch Pool rows wait for the Consolidate button.
It will not warn you that a row is ageing — in the Batch Pool, the Individual Pool or on an Invalid record. The nearest thing is an e-mailed list of the Individual Pool’s failed rows that BigLedger can schedule for a tenant, and it reports age to nobody. Reading the pools before the 7th is a person’s job.
It will not apply LHDN’s relaxation period. The divert reads the submission type, the document type and the amount, and nothing about your taxpayer status.

What it is not

Not a summary or a report. It is a tax document in its own right, validated by LHDN like any other, and subject to the same rules once it is Valid.
Not a way to avoid reporting a big sale. The RM 10,000 line is a reporting rule, not a target. Splitting a sale to duck under it is not a workaround.
Not the same thing as “submitted in a batch”. The Batch Pool is where receipts wait; the consolidated e-invoice is what is eventually built from them. A receipt sitting in the pool has not reached LHDN, and neither has a receipt whose consolidated e-invoice is still IN_CONSOLIDATED_QUEUE.
Not switched off by Disable Consolidated Submission. That removes a choice from a drop-down; the run does not consult it.
Not final until the run. Up to the moment the run takes the row, a receipt can be pulled out and reported individually with the buyer’s real details. Afterwards it is inside a tax document.

Where this sits in the rest of BigLedger

Before it can work: the company’s E-Invoice Status must be ENABLED on the Organisation applet, the consolidation clock and the consolidated submitter must be ACTIVE on the Scheduler, and the intermediary token refresh with them — without a token the run still builds and the submitter fails on every row. Missing any of these, the Batch Pool fills and nothing leaves it.
What decides who goes in is set upstream, at the till: the point of sale leaves a new cash bill’s submission type blank, so a shopper who gives complete details gets an individual e-invoice and one who does not is consolidated; the sales invoice starts at Individual. Marking a receipt Consolidated explicitly skips the buyer check altogether.
What it enables: a month’s counter sales reported with a document count a person can review, and the Discrepancies Report, whose consolidated-only count and drill-down to a consolidated e-invoice’s source documents is how you prove a given receipt was reported.
Its sibling is the individual e-invoice, and the boundary is three questions: did the buyer ask for one, is the sale under RM 10,000, and is the buyer local. Yes, yes and yes is a consolidation; a no on any of them is an individual e-invoice — with the buyer’s real tax number, which for a passport holder BigLedger will not substitute.
What breaks elsewhere if it is wrong: a failed send left past month-end turns a named business customer’s sale into an anonymous one; a clock switched off on the tenant stops every company’s consolidation at once; a consolidated e-invoice cancelled past the window leaves a month of receipts reported by nothing.
What it is paired with in practice: the My E-Invoice Admin applet — Batch Pool, Consolidated Submission, To IRB E-Invoice — and the Scheduler, where the clocks that drive it are read.

How you know last month is reported — a five-minute check

The Batch Pool, filtered to last month: no UNPROCESSED row and no PROCESSED / FAILED row. On a by-branch tenant, do this the day after your run, because a row the run passed over looks exactly like one it has not reached.
Internal Submission → Consolidated Submission: empty. A row still here is built and not sent; check the consolidated submitter’s clock and the intermediary token.
To IRB E-Invoice, filtered to consolidated: last month’s records — several per company and document type, one for each batch the run took — each dated the last day of that month, each Valid. Submitted means LHDN has not answered yet; Invalid means every receipt inside it is unreported.
The Individual Pool: nothing from last month that was diverted for size and never completed. Each row there is a sale of RM 10,000 or more that LHDN has not seen.
One receipt, picked at random from a busy branch’s last month: it carries a consolidated e-invoice reference, and the e-invoice it names is the Valid one from step 3.

If all five hold, last month’s counter sales are at LHDN. What the check does not do is confirm the amounts: comparing the consolidated e-invoices’ totals with the month’s sales by document type is a person’s job, and the Discrepancies Report is where it is done.