E-Invoice Pools: Submission Types, the RM 10,000 Rule and Where a Finalised Document Goes
Part 2 of Pools and E-Invoice Submission Routing: the decision BigLedger makes for every finalised sales document — submit it to LHDN on its own, report it inside a consolidated e-invoice, or park it in a pool. It follows the month at a glance on the first page. GadgetSphere’s walk-in counter receipts of a few hundred ringgit and its five-figure corporate orders take completely different routes, and the rules below keep them apart.
Nothing is submitted at the moment you press Save: finalising a document puts it in a queue, and a background processor picks it up and sends it.
Submission types
Each document carries an e-invoice submission type that drives the routing:
| Submission type | Meaning |
|---|---|
| Individual | Submit this document to LHDN as its own e-invoice |
| Consolidated | Include this document in the monthly consolidated e-invoice (typical for B2C retail) |
| Single General | Try as an individual e-invoice using general buyer details. If that attempt fails the document is meant to end up consolidated — but somebody has to press Resubmit as New E-invoice; nothing falls back on its own. Since 8 October 2026 the check before that attempt skips the buyer’s fields on a sales document (see the table under Where does a finalised document go?) |
| (not set) | The system decides based on the amount and available data |
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, 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:
| Submission type | Amount | Mandatory fields complete? | Outcome |
|---|---|---|---|
| Individual | any | ✅ | Submitted to LHDN as an individual e-invoice |
| Individual | any | ❌ | Individual Pool |
| Consolidated | < RM 10,000 | — | Batch Pool (awaits monthly consolidation) |
| Consolidated — sales invoice or cash bill | ≥ RM 10,000 | — | Individual Pool (the RM 10,000 rule, applied before the field check) |
| Consolidated — any other document type | ≥ RM 10,000 | — | Batch Pool (the divert does not cover these) |
| Single General | any | ✅ — on a sales document the buyer’s fields are not checked (since 8 October 2026) | Submitted as an individual e-invoice |
| Single General | < RM 10,000, or any amount on a type other than a sales invoice or cash bill | ❌ | Single General Pool |
| Single General — sales invoice or cash bill | ≥ RM 10,000 | ❌ | Individual Pool |
| (not set) | any | ✅ | Submitted as an individual e-invoice |
| (not set) | < RM 10,000, or any amount on a type other than a sales invoice or cash bill | ❌ | Batch Pool |
| (not set) — sales invoice or cash bill | ≥ RM 10,000 | ❌ | Individual Pool |
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 success looks like for this part
For any document you finalised today you can say where it went and why: its submission type on the E-Invoice tab, its total against RM 10,000, and — once the clock that empties the posting queue has run (every ten minutes by default) — whether it is in the submission list or a pool. Any credit note, debit note, refund note or sales return of RM 10,000 or more marked Consolidated has been checked by hand before the monthly run. When you are done, run the whole page’s success check.
Common mistakes in this part
- 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.
- Splitting a large sale to duck under RM 10,000. The threshold is a reporting rule, not a target.
Next: Working each pool.