Pools and E-Invoice 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. The e-invoice pools are three: the Batch Pool, the Individual Pool and the Single General Pool. 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 the normal state of a till receipt, because nothing at the point of sale fills the field unless a cashier chooses. It is not a fault either, because the (not set) row above routes the receipt 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 two things blank does not. It skips that check, so the receipt is consolidated even when the buyer’s details were complete — and it stamps the General Public tax number on the Batch Pool row. A blank receipt is different: BigLedger tries to build it into an individual e-invoice first, and the row then carries whatever tax number that attempt worked out — the customer’s own if the record holds one, the General Public number if they gave a Malaysian identity card, and nothing at all for an ordinary walk-in, which is the common case. On most companies that difference is invisible. On a company that consolidates by branch it decides whether the row is ever consolidated — see By document or by branch below, and read it before you decide to leave the submission type blank at the till. 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.

Where the value comes from, and when it is read. The submission type is a stored field on the document itself. The screen that created the document writes it first; after that BigLedger itself rewrites it when a document is re-routed — a pool action, or the monthly sweep described under Individual Pool. It is read at two moments, and which one depends on the value. An explicit Consolidated is acted on by a job that runs as part of finalising, so its Batch Pool row appears without waiting for any clock. Every other value — Individual, Single General or blank — goes into the posting queue, and the routing decision is made by the clock that empties that queue, every ten minutes by default. So for up to ten minutes after you finalise, a non-consolidated document is in neither a pool nor the submission list; that is the queue, not a fault.

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 a sales invoice or cash bill 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. On a purchase document of that size it does the same for the supplier.

Where the RM 10,000 lives — and who can change it. It is not a setting. The figure, and the list of two document types it applies to, are written into BigLedger’s program, separately in each place that tests it: the finalise step above, the routing after the mandatory-field check, the registry search, the Move To Batch Pool button, and — since 13 October 2026 — the monthly sweep of rejected records, which takes only those under RM 10,000. No company field, scheduler clock or screen holds it, so nobody on your tenant can raise, lower or switch it off; only a BigLedger release can. The amount it compares is the document’s own total as stored on the document, in the document’s currency — BigLedger does not convert a foreign-currency sale to ringgit before comparing.

Where does a finalised document go?

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

The ✅ and ❌ column is BigLedger’s own check, not LHDN’s: for the supplier and the buyer, a name, tax number, identity type and value, an address with line 1, city and state, and a contact number of 8 to 20 characters; the supplier’s industry code and business activity; the document’s currency and totals; and on every line a classification, description, unit price, tax type and tax amount. The RM 10,000 rows act only when that check has failed. A Single General sales document that fails nothing but its buyer details is therefore sent individually at any amount — an RM 18,000 sale included — with whatever buyer details it carries, and it is LHDN, not BigLedger, that then decides whether that is acceptable. If a large sale has a real buyer, choose Individual for it.

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 — and do it in the first days of the following month. The automatic run keeps taking last month’s Batch Pool rows on every firing until that month is over, so a row you move on the 3rd is still picked up, but it has to be consolidated and submitted by the 7th to be on time; and once the following month has ended the row is outside the run’s window, and only the manual Consolidate button will take it. (Since 13 October 2026 a document that did get an individual e-invoice record which LHDN then rejected — Invalid, or still IN_QUEUE because LHDN refused it when it was sent — is swept into the Batch Pool by the next consolidation run for its month when it is under RM 10,000 and a sales document, and reported under the General Public buyer. A record that has not been sent yet is left for the submission run, and a pooled document that never got a record is not touched.)

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 submitted within seven calendar days after the month end — by the 7th (e-Invoice Specific Guideline 4.9, §3.6.2). Every receipt inside one is traceable back to the e-invoice that reported it.

You do not normally press anything — and there is no single “consolidation day”. Consolidation and submission are two clocks on your tenant’s scheduler, and by default both tick all day, every day: the consolidation run every half hour, the consolidated submission every 20 minutes. From the first firing on the 1st, each consolidation run takes a batch of last month’s unprocessed Batch Pool rows (100 by default) and builds them into consolidated e-invoices, and the submission clock sends whatever has been built for last month on to LHDN. So last month is consolidated in batches from the morning of the 1st onward, and the 7th is the deadline those batches have to beat, not the day they run. A small month is done within the first hours; a high-volume tenant on the default batch can need days of runs — the interval and the batch size are set per tenant on the clock’s row in the Scheduler applet, which is where to look (or ask support) if your month is large (Pools and queues works the arithmetic). The clocks belong to the tenant, not the company — one consolidation clock serves every company in your BigLedger tenant, so in a group of three companies all three are consolidated by the same runs, and switching that clock off stops it for all three at once. The buttons in the Batch Pool and on Internal Submission → Consolidated Submission are the manual fallback, used when a run has to be repeated or a row has fallen outside its window. The full week-by-week routine is in The Month-End E-Invoice Cycle.

Where each number in this section comes from. Some are clocks on your tenant, some are written into the program, and one is LHDN’s:

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. 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–1005 is 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.

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.

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. BigLedger does not copy it from the document: it writes the clock time, in UTC, at the time of submission — the moment the run builds what it sends — so a document finalised on the 30th and sent on the 1st carries the 1st. The document’s original transaction date is preserved separately — you don’t lose it. A consolidated e-invoice is the exception you will notice: its own date is set to the last day of the month it reports.
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 pushing the receipt into the batch either strands it (a by-branch run skips a row with no tax number) or misreports it (a by-document run files it under General Public). The buyer’s real tax number is the only way that sale reaches LHDN as theirs.

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 sale that already carries the skip flag at FINAL is also recorded in a matching queue, so it can be paired later with the e-invoice the counterparty issued, provided your company runs that job; a sale you skip later from a pool row is not recorded there. 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. Skipping is not a way to get rid of a sale that did not happen. It stops the e-invoice and nothing else: the revenue, the stock movement and the amount owed all stay in your books. Correct the sale itself, as the month-end guide sets out. A voided sale is on neither side of the report, because both sides read FINAL sales only. That is why a sale voided after its e-invoice went out leaves a Valid e-invoice with nothing behind it.

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.
4. If your company consolidates by branch — do step 3 again the day after your run. Anything still unprocessed for the month that was just consolidated was not skipped, it was not eligible; check the buyer’s tax number on those rows and consolidate them by hand.

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. (One clock can e-mail each company a list of its Individual Pool rows whose submission failed, but it is not among the clocks BigLedger installs, so on a default tenant no such e-mail arrives.) BigLedger does contain five processors that could move these rows for you: four of them can be put on a schedule, and nothing puts them on one for you; the fifth cannot be scheduled at all and runs only when somebody calls its endpoint, one branch at a time. So the capability exists, but it does nothing until a clock is added for it. The listing in the Scheduler applet shows whether a schedule with one of these codes exists on your tenant and whether it is ACTIVE; if you do not have that applet, ask support. 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.
• 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 not picked up by a by-branch run. (A customer record deliberately carrying the foreign-buyer General TIN EI00000000020 is 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.)
• Splitting a large sale to duck under RM 10,000. The threshold is a reporting rule, not a target.

Related documentation