E-Invoice Pools & Submission Routing

Every finalised sales document — invoice, cash bill, credit note — goes through the same decision the moment you finalise it: submit it to LHDN on its own, or report it inside a consolidated e-invoice? And if something required is missing, park it in a pool so you can fix it. Ten minutes with this page and you will be able to look at any document and say exactly where it went and why.

Meet GadgetSphere

GadgetSphere Sdn Bhd runs 22 consumer-electronics branches. The overwhelming majority of its sales are walk-in counter receipts of a few hundred ringgit with no buyer details at all, and a small number are corporate orders worth five figures. Those two shapes take completely different routes through e-invoicing, and every rule below exists to keep them apart.

This page assumes two ideas rather than explaining them: what a consolidated e-invoice is, and how a pool differs from a queue.

Submission types

Each document carries an e-invoice submission type that drives the routing:

You can see and change it on the document itself: open the sales document and go to its E-Invoice tab → Submission Type. There is no per-document-type default, and no setup screen for one. The sales invoice applet starts a new invoice at Individual; the point of sale starts a new cash bill with the type blank, and only a cashier’s choice on the E-Invoice panel fills it. Blank is not a fault — across the customer base it is by a wide margin the commonest state a finalised receipt is in — because the (not set) row above routes it through the mandatory-field check: complete buyer details give the shopper an individual e-invoice without anyone choosing it, and incomplete details send the receipt to the Batch Pool with the missing fields written on the row. Choosing Consolidated explicitly does one thing blank does not: it skips that check, so the receipt is consolidated even when the buyer’s details were complete. Change the type on a single document when that one sale is genuinely an exception; there is no setting that changes it for a whole company or document type.

The RM 10,000 rule

What LHDN requires. A single transaction with a value exceeding RM 10,000 may not be reported inside a consolidated e-invoice. It applies to all industries and takes effect 1 January 2026 — e-Invoice Specific Guideline 4.9, §3.7.2, Table 3.6 row 7. §3.7.1 spells out what follows: a supplier in that position must obtain the buyer’s details and issue an individual e-invoice.

What BigLedger does about it, which is a different sentence with a different source:

• A sales invoice or cash bill marked Consolidated with a total of RM 10,000 or more is diverted to the Individual Pool instead of the batch, with the reason “Amount transaction is greater or equal to RM10000” written on the row.
• For documents of RM 10,000 or more where the buyer’s ID type is a business registration number but the tax number is missing, BigLedger searches LHDN’s registry by registration number and fills the tax number in when it finds a match.

Where does a finalised document go?

When a document is finalised, BigLedger checks its submission type, amount, and whether all mandatory fields are complete:

Example: GadgetSphere Sdn Bhd’s POS cash bills are marked Consolidated — they flow into the Batch Pool and are swept into the monthly consolidated e-invoice. A corporate customer buying RM 18,000 of equipment on the same day is above the threshold, so that invoice must go out individually, with the customer’s real TIN.

What you can do in each pool

The table above says which pool a document lands in; Pools and queues says why the three behave differently. What follows is what you can actually do once a document is in one.

Batch Pool

Fix the buyer’s data and resubmit the receipt as an individual e-invoice; move it to the Individual or Single General pool; consolidate on demand (by date range, by branch, or by selected documents); or skip e-invoicing for the document. Most rows need none of this — they are waiting for the monthly run and that is correct.

Individual Pool

Complete the buyer details and resubmit. If you cannot obtain the buyer’s details at all, move the document to the Batch Pool so it is consolidated instead — but do this before the scheduled monthly consolidation run, or it is stranded in a closed month.

Single General Pool

Fix and resubmit as individual; if that submission fails or comes back Invalid, resubmit the document as a single-document consolidated e-invoice with Resubmit as New E-invoice on the e-invoice record; or move it to another pool. This pool exists for sales where the buyer’s data is unlikely ever to arrive but you still want one individual attempt first. Note that every one of those is something you do: like the Individual Pool, this one waits indefinitely and nothing in it moves on a schedule.

Pool comparison

All pool actions are performed in the My E-Invoice Admin Applet.

The monthly consolidation cycle

Unprocessed Batch Pool documents from a month are grouped into consolidated e-invoices, which LHDN requires to be validated by the 7th of the following month. Every receipt inside one is traceable back to the e-invoice that reported it.

You do not normally press anything. Consolidation and submission run automatically on a schedule set per company, deliberately a few days ahead of the 7th so there is time to correct whatever comes back Invalid. The buttons in the Batch Pool and on Internal Submission → Consolidated Submission are the manual fallback, used when a run has to be repeated. The full week-by-week routine is in The Month-End E-Invoice Cycle.

Which processors are running is a per-tenant answer from support — but three switches are yours, per company. On each company’s E-Invoice tab: Disable Consolidated Submission and Disable Single-General Submission take those two values out of the Submission Type drop-down on every sales and purchase document for that company, so nobody can mark a new document for them; and Send Email To Buyer decides whether the validated PDF is e-mailed to the buyer at all. In a group of three companies they are three separate answers, and the first two explain a submission type that has gone missing from a drop-down rather than a processor that has stopped.

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.
• By branch — one line per consecutive range of that branch’s document numbers, so 1001–1005 is a single line covering five receipts. That keeps a high-volume branch inside the 200-line ceiling on a consolidated e-invoice, and it groups each branch’s month into its own block. A gap in the numbers starts a new line, so every receipt a branch pulls out of the batch splits one range into two.

By-branch is the shape that keeps a multi-branch month readable as its own block, but it is uncommon as a scheduled run — most companies that have an automatic consolidation at all are consolidated by document, and Consolidate By Branch is used as a button. Which run your tenant has 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.

Backdated documents

Two rules matter when handling documents dated in the past:

1. Issue time is always “now”. LHDN requires the e-invoice issue date-time to be the actual submission time. The document’s original transaction date is preserved separately — you don’t lose it.
2. The automatic run looks at one month, and older rows are left where they are. Since 2026-09-18 it selects only unprocessed Batch Pool rows whose transaction date falls in the previous calendar month. A receipt dated this month waits for next month’s runs, which is right; a receipt dated two months ago is outside the window and will never be picked up, however long you wait. Sort the Batch Pool by date every cycle. When you find old rows, select them and press Consolidate yourself — the button has no date window, and the e-invoice it builds is dated the last day of that receipt’s own month. It will be submitted, and it will be late, because that month’s deadline was the 7th of the month after it.

Frequently asked questions

A customer wants an individual e-invoice for a receipt that’s already in the Batch Pool — what do I do? Find the document in the Batch Pool, complete the customer’s TIN/ID and address, and use Save and Resubmit. It leaves the batch and is submitted individually. This works any time before the receipt has been consolidated.

What happens if I can’t get a buyer’s TIN at all? For a local buyer, an individual e-invoice can still be issued with the General Public TIN plus a valid NRIC (see General TINs); failing that, move the document to the Batch Pool and let it be consolidated. For a foreign buyer neither route is open — no General TIN is substituted for a passport, and a consolidated e-invoice cannot carry a foreign buyer — so the buyer’s real tax number is the only way that sale reaches LHDN.

A customer is asking us for an e-invoice for a receipt from last week — do we have to key it ourselves? Not necessarily. Your buyers can do it themselves through the My E-Invoice Portal: the customer finds their own receipt, fills in their tax number, identity and address, and submits. Their details land on your customer record and the pooled receipt is ready for you to complete with Save and Resubmit. For a 22-branch retailer this is the difference between chasing details and having them arrive. It does not work for a receipt that is already inside a validated consolidated e-invoice — that needs a cancellation inside 72 hours, or a credit note.

A document shows “skipped” — is that a problem? Skipping is a deliberate action for documents that must not be e-invoiced (for example, when the counterparty issues the e-invoice instead). A skipped sales document is still recorded in a matching queue, so it can be paired later with the e-invoice the counterparty issued — see Incoming Supplier E-Invoices for what that pairing can and cannot reach. Skipping removes the document from the report’s ERP Transaction Summary, but not from the Document vs E-Invoice Discrepancy tab, where it is still listed as missing — so a document skipped by mistake still turns into a question at month-end. And a voided sale that was not marked skipped shows up as a gap on both.

I fixed a Batch Pool row and resubmitted it, and it failed. Will the consolidation still pick it up? No — and this is the one that catches people out, though not for the reason most people think. It is not the “failed” that strands it, it is the “processed”. Most rows in a healthy Batch Pool are unprocessed and failed: they are there because they could not have been individual e-invoices, the Validation Error lists the buyer details you do not have, and the consolidation run never reads that column. What takes a row out of the run is Process or Save and Resubmit, which mark it processed whether they succeed or fail. So filter on process status, not on red. Then either fix the customer record and Save and Resubmit again — which can now succeed and produce an individual e-invoice — or, if you simply want the receipt back in the monthly batch, use Move to Individual and then Move To Batch Pool from the Individual Pool. Nothing resets a row; that pair replaces it with a fresh unprocessed one.

What success looks like

Thirty seconds in My E-Invoice Admin Applet, at any point in the month:

1. Individual Pool — empty, or every row has someone chasing the buyer’s details. Nothing here moves on its own.
2. Single General Pool — same test, and remember to look; it is the pool people forget.
3. Batch Pool — filter on process status = unprocessed and sort by date. Rows dated this month and last month are fine; they are waiting for the run, and it does not matter how many of them are red. What you are looking for is anything dated before last month, which the automatic run can no longer see, and any row whose process status reads processed, which it has finished with. Both need you.

Common mistakes

• Assuming a pooled document will sort itself out. Only the Batch Pool empties itself, and only for last month. The Individual and Single General pools wait for you indefinitely, and nothing ages a row or warns you it is old. BigLedger does contain five processors that could move these rows for you: four can be put on a schedule and, measured across 90 of 90 tenant databases, together they are on fewer than three tenants; the fifth cannot be scheduled at all and only runs when somebody calls its endpoint for one branch. So the capability exists, it is switched on essentially nowhere, and asking support is the only way to find out about your own tenant. Plan for manual.
• Moving a document to the Batch Pool months after the fact. The row keeps the document’s own date, and the automatic run only selects last month’s. Move it late enough and nothing will ever pick it up — you will have to select it and press Consolidate yourself.
• Pressing Process on a screen full of red rows to tidy them up. They were going to be consolidated. Process runs the individual check, the check fails for the same reason it failed the first time, and the row is marked processed — you have just taken it out of the run, and there is no button that puts it back.
• Trying to move a RM 10,000-or-more sale into the Batch Pool. BigLedger refuses it — “Cannot move transaction with amount more than or equal to 10000.” Get the buyer’s tax number instead.
• Putting a foreign buyer into consolidation. Key the identity type as Passport and submit individually — with the buyer’s real tax number, because no General TIN is substituted for a passport.
• Splitting a large sale to duck under RM 10,000. The threshold is a reporting rule, not a target.

Related documentation