E-Invoice Pools: Consolidating by Document or by Branch
Part 5 of Pools and E-Invoice Submission Routing: the two ways a consolidated e-invoice is built, what each does to the tax number on a Batch Pool row, and the check a company that consolidates by branch runs before and after each run. It follows The monthly consolidation cycle. For a group like GadgetSphere, with 22 branches, by-branch is the shape that keeps each branch’s month readable as its own block.
By document or by branch — two ways to build one
Which method your company is on is set for you, and the difference is visible on the e-invoice itself, so it is worth knowing which you will be looking at:
- By document — one line per receipt. Each line’s description is that receipt’s document number. Simple to read and simple to trace. This run groups only by company and document type: every branch’s receipts go into the same consolidated e-invoice, and the header carries no branch at all. To answer “which e-invoice reported this branch’s sale”, you follow the individual receipt’s link, not a branch column. There is no line cap on this path — what bounds one run is how many batch-pool rows it takes per pass.
- By branch — one line per consecutive range of that branch’s document numbers, so
1001–1005is a single line covering five receipts. It groups each branch’s month into its own block, and a gap in the numbers starts a new line, so every receipt a branch pulls out of the batch splits one range into two. This is the path with the 200-line ceiling, and it is a ceiling per e-invoice rather than a cut-off: the run works through the month in blocks of 200, so a branch with more than 200 ranges in a month gets more than one consolidated e-invoice, not a truncated one. Ranges are what keep the count down. It is also the only automatic path that touches purchase documents — the by-document run takes sales document types and nothing else.
On the by-branch path, a Batch Pool row is grouped under one of LHDN’s general tax numbers, and which ones count depends on whether the document is a sale or a purchase:
- a sales row qualifies on its buyer’s tax number, and only on General Public, foreign buyer or government;
- a purchase row qualifies on its supplier’s tax number, and only on General Public, foreign supplier or government.
Since 14 October 2026 the run first rewrites every other unprocessed row it is about to consolidate. A row carrying a real customer tax number, none at all, or the general number belonging to the other side — sales or purchases — is given the General Public number EI00000000010, overwriting what was on the row, and is then consolidated as General Public. Nothing warns you that a row’s tax number was replaced.
The by-document run has no tax-number test at all. It takes every unprocessed row for the month whatever tax number is on it, and files the lot as General Public. So on the by-document run every Batch Pool row is reported as General Public, and on the by-branch run every row is unless it already carries the foreign or government number — and if you do not know which run your company is on, that is the question to ask support first.
What to do about it, if your company consolidates by branch. Two things.
Look at the Batch Pool before your run, and again the day after it. Before: a row whose buyer needs an e-invoice of their own — a real tax number, a named business customer — has to be resubmitted individually or moved out of the Batch Pool first, because the run will report it as General Public. After: filter on unprocessed rows for the month that was just consolidated. A leftover row was not left for its tax number; check that the run actually finished and that the row has a branch on it, then select those rows and press Consolidate yourself.
And for anonymous counter sales, either submission type reaches the consolidated e-invoice. Marking a till receipt Consolidated stamps the General Public number on the row when it enters the Batch Pool; a blank one that lands there is given it by the run. Use Consolidated only where it is genuinely the right answer — a local walk-in, under RM 10,000, who has not asked for an e-invoice of their own. An explicit Consolidated skips the mandatory-field check, so a shopper who does hand over complete details is consolidated instead of being given an individual e-invoice; and it stamps General Public over a named, foreign or government buyer’s own identity. For anything but the anonymous case, leave the type blank and rely on the before-the-run check above.
By-branch is the shape that keeps a multi-branch month readable as its own block. It can run either way — on the company’s consolidation schedule, or on demand from the Consolidate By Branch button — and which of the two your company is on is a scheduler question for support. It is not the Batch Line Logic field on the company record: that field records what the company was promised and is read by nothing that consolidates — its only reader anywhere is a listing filter on the company query (Organisation applet). Ask your BigLedger contact if you are not sure.
NRIC), so a passport holder with a blank tax number is not submitted at all: the document parks in the Individual Pool. Moving it to the Batch Pool is not the answer either: whichever consolidation run your company is on picks the row up and reports that foreign customer’s sale as General Public — a by-branch run gives a row with no tax number the General Public number first, and a by-document run files every row that way. Neither gives the buyer the e-invoice they came for. Ask for the tax number at the counter.What success looks like for this part
If your company consolidates by document: each consolidated e-invoice has one line per receipt, described by that receipt’s document number, and no row for the month just consolidated is still unprocessed. If your company consolidates by branch: before the run, every Batch Pool row whose buyer needs an e-invoice of their own has been resubmitted individually or moved out; and the day after it, nothing for the month just consolidated is still unprocessed — or what is left has been checked for a branch and consolidated by hand. When you are done, run the whole page’s success check.
Common mistakes in this part
- Expecting consolidation to absorb a foreign buyer you have no details for. Key the identity type as Passport and submit individually, with the buyer’s real tax number — no General TIN is substituted for a passport, and a pool row with no tax number is consolidated under General Public by either run. (A customer record deliberately carrying the foreign-buyer General TIN
EI00000000020is a different case: a by-branch run does group those into a consolidated e-invoice of their own. Whether LHDN accepts a foreign buyer inside a consolidated e-invoice is a question for your tax adviser — BigLedger builds it, and that is not the same as it being the right thing to file.)