Pools and queues

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

Which pool a document lands in

7 slides · about 10 min · Work the pools until nothing is stuck, 1 of 6

Read a pool row before you touch it

7 slides · about 11 min · Work the pools until nothing is stuck, 2 of 6

Clear the Individual Pool

7 slides · about 12 min · Work the pools until nothing is stuck, 3 of 6

Work the Batch Pool without stranding a receipt

8 slides · about 12 min · Work the pools until nothing is stuck, 4 of 6

The pool everyone forgets

7 slides · about 9 min · Work the pools until nothing is stuck, 5 of 6

When a document will not go at all

7 slides · about 11 min · Read a rejection and fix it, 7 of 7

“I finalised the invoice and nothing was submitted to LHDN” — then the document is waiting in one of two places, and which one decides whether you wait or act. A queue holds a document that is complete and on its way: a scheduled job will send it without you. A pool holds a document that is not going to LHDN on its own: something it needs is missing, or it is waiting for the month’s consolidated e-invoice. Outside the Batch Pool, a pooled document waits for a person, however long that takes.

This page explains what moves a document from one to the next, on which clock, where the figures on those screens come from, and what a stuck one looks like. The steps for working each pool are in Pools & Submission Routing; this is the picture behind them.

Why it exists

A GadgetSphere till at GS-KV-02 sells a RM 89 charging cable to a shopper who gives no name and has somewhere to be. LHDN expects that sale to be reported, and an individual e-invoice for it would be rejected for want of a buyer tax number. BigLedger could have refused to finalise the sale, or sent the e-invoice anyway and collected a rejection. It does neither: the sale completes, the books and the stock are right, and the e-invoice is parked with the reason written on it.

Pools are where it is parked. A pool that waits for a person is deliberate — it never submits a document that is not ready, and it never guesses a buyer’s identity on your behalf. The one pool that empties itself, the Batch Pool, does so only into a consolidated e-invoice under the General Public buyer, which is LHDN’s own provision for exactly this shopper. The cost of the design is that the other two pools hold sales you have not reported yet, and they hold them quietly.

How it behaves in BigLedger

What happens behind the scene, from Finalise to LHDN

Pressing Finalise does not talk to LHDN. It starts a background job that looks at the document once and puts it in one of three places — or nowhere:

The document at FINAL	Where it goes
Company’s E-Invoice Status is not ENABLED, the type is not an e-invoice type, Skip E-Invoice is set, or the same document is already waiting	Nowhere. No row, no message
Submission type Consolidated, a sales invoice or cash bill of RM 10,000 or more	Individual Pool, reason “Amount transaction is greater or equal to RM10000”
Submission type Consolidated, anything else	Batch Pool, without any further check
Individual, Single General or blank	Posting Queue

From there, everything is moved by a scheduled job, one per hop. These are the default clocks BigLedger puts on a new tenant:

Hop	What moves it	Default clock	Per run
Posting Queue → e-invoice record, or a pool	The posting run builds the e-invoice record and checks the mandatory fields. Pass: the record is written at `IN_QUEUE` with a row in the submission queue. Fail: the document goes to a pool by its submission type and amount	every 10 minutes	until the queue is empty, up to 5,000 rows
Submission queue → LHDN	The submitter sends one document at a time	every 10 minutes	49
LHDN → Valid or Invalid	The poller asks LHDN for the verdict and writes it onto the record	every 10 minutes	20
Batch Pool → consolidated e-invoice	The by-document consolidation run takes last month’s unprocessed sales rows	every 30 minutes	100 rows
Consolidated queue → LHDN	The consolidated submitter	every 20 minutes	49
A record left at `NOT_SUBMITTED` → submission queue	The feeder, for a record that was written without its queue row (the posting run writes both together)	every 10 minutes	10

Two things follow that the screens do not show.

Throughput is a setting, not a constant. At the default, the consolidation run handles 100 receipts every half hour. GadgetSphere’s 22 branches ring up roughly 38,000 receipts a month; at 100 a run that is 380 runs, nearly eight days — past the 7th. BigLedger can give a tenant’s consolidation clock a bigger batch or a different interval, so what your tenant does is on its own Scheduler row, not in this table.

A clock that exists is not a clock that runs. Each default clock is inserted, switched on, only where your tenant has no row of that code — it can since have been switched off, deleted, or given another interval. And the Scheduler’s Last Run Date means the clock fired, not that the job worked (Scheduler). The schedule belongs to the tenant, so one clock switched off stops that hop for every company in the tenant at once.

The three pools, and what empties each

Pool	Holds	What takes a row out
Batch Pool	Receipts to be reported inside a consolidated e-invoice	The consolidation run, in the month after the receipt’s date — if that clock is active on your tenant. Otherwise Consolidate, pressed by a person
Individual Pool	Documents meant to go to LHDN on their own, with something mandatory missing, and every sales invoice or cash bill of RM 10,000 or more that was marked Consolidated	A person: Save and Resubmit, or a move to another pool
Single General Pool	Documents given one individual attempt, meant to end up consolidated if it fails	A person, the same way. The fallback is a button, not a rule

Five recovery jobs exist; none of them is on the default schedule. BigLedger contains jobs that move rows out of these pools without a person — Individual Pool to consolidated, Individual Pool to single general, the two equivalents for IRB-Invalid records, and one that re-homes failed Individual Pool rows by the buyer’s identity type. The first four run only if somebody adds a Scheduler row for them. The fifth has no schedule code at all; it runs when it is called for one branch at a time. Read your own Scheduler before assuming any of them works for you.

Where the figures on these screens come from

Almost everything you read on a pool or queue row is a stored value, written at one moment — not a live check.

What you see	Stored or live	Written when, by what
Validation Error on a pool row	Stored	When the row was made, from the mandatory-field check at that moment. Correcting the customer afterwards does not change it; Save and Resubmit and Process run the check again
Queue Status `FAILED` on a new pool row	Stored	Set whenever the row arrived with a reason — the ordinary state of a receipt that went to the Batch Pool because it lacked a buyer tax number. It is a description, not a fault
Process Status on a Batch Pool row	Stored	`UNPROCESSED` at creation; `PROCESSED` once consolidated — or once Process or Save and Resubmit has been pressed, even when the check failed again
`IN_QUEUE` on an e-invoice record	Stored	Written when the record and its queue row are made. The submitter changes it when LHDN accepts the payload; a failed send leaves it `IN_QUEUE`, with the error on the queue row
Retries remaining on a submission-queue row	Stored, frozen	Written as 5 when the row is made or resubmitted, and it never moves: no job reads it or counts it down
`Valid` / `Invalid` on the record	A copy	Written by the poller from LHDN’s answer. Refresh asks LHDN again by the record’s own LHDN document ID
Last Run Date on a Scheduler row	Stored	Stamped when the clock fires, including when an identical job was already waiting. It says nothing about whether the job did its work

What a stuck document looks like, and what to do

A document that has not moved since this morning is almost always waiting for its next run. A document that has not moved since yesterday is waiting for a person or a clock.

What you see	What it means	What to do
The document is in no pool, not in the Posting Queue and not in To IRB E-Invoice	It failed the check at FINAL and nothing was written	Check the company’s E-Invoice Status, the document type and the three Skip E-Invoice sources (Related applets)
A Posting Queue row at `PROCESSED` / `FAILED`, with a message	The posting run hit an error building the record — or the document already had a `Valid` e-invoice, and the row was a duplicate. The scheduled run picks up unprocessed rows only, so it will not try this one again	Look up the document’s e-invoice first. If it is `Valid`, there is nothing to do. Otherwise fix what the message names, select the row and press Submit on the Posting Queue
Posting Queue rows still unprocessed an hour after Finalise, with no message on them	The posting run is not running	Open the Scheduler and look at that clock’s status (the check below)
A record still `IN_QUEUE` the next morning	The send failed and the record is waiting for a person — or the submitter’s clock is off	Read the error on its submission-queue row, fix, resubmit. Under RM 10,000 and left past month-end, a record LHDN refused is swept into the consolidated e-invoice instead, if the consolidation run is active; one never sent waits for the submission run — see below
Individual or Single General Pool rows that keep growing	Sales not yet reported, waiting for you	Save and Resubmit each one with the missing detail (admin applet)
Last month’s Batch Pool rows still unprocessed on the 3rd	The consolidation clock is off, or slower than your volume	Check its Scheduler row; or select the rows and press Consolidate
A Batch Pool row dated two or more months ago, still unprocessed	Outside the automatic run’s window, which is last month only	Select it and press Consolidate — the button has no date window. It will be late
A Batch Pool row at `PROCESSED` / `FAILED`	Stranded: Process or Save and Resubmit failed on it and took it out of the run	The round trip on the admin applet’s Batch Pool section

Once the month is over, rejected individual e-invoices are swept into the consolidation. Since the backend of 2 October 2026, every automatic consolidation run first takes last month’s sales e-invoice records under RM 10,000 that LHDN did not take, moves each into the Batch Pool under the General Public buyer, and retires the individual record. Since 13 October 2026 that means a record that reads Invalid, or one still IN_QUEUE because LHDN refused it when it was sent (LHDN’s answer is on the record, and it has no LHDN document ID). A record still IN_QUEUE because it was never sent, or because the send failed before LHDN answered, is left for the submission run. That is the right outcome for a walk-in receipt and the wrong one for a named business customer who wanted their own e-invoice, which is why rejections are a job for inside the month, not for the 7th.

An Invalid record is swept too, since 13 October 2026. Before that date the run left it alone; now an Invalid sale you have not fixed by the time the run fires for its month is reported inside the consolidated e-invoice under the General Public buyer, not the buyer on the record. The run stamps the document Consolidated whatever submission type it carried, and it does not read the company’s Disable Consolidated Submission switch, so that switch does not keep a company’s rejected sales out of the sweep. Whether that is intended has not been confirmed by BigLedger. Rows waiting in a pool are not touched by the sweep, and the manual Consolidate buttons do not run it.

What it will not do

It will not tell you a document has been waiting a long time. E-invoicing has no ageing alert. The nearest thing is an e-mailed CSV of the Individual Pool’s failed rows, per company, which BigLedger can schedule for a tenant; it lists the pool’s failed rows each time it runs, whatever their age, and it does not cover the Single General Pool.
It will not retry a failed send by itself. The “retries remaining” figure is decoration; a row that has not moved since yesterday is not being retried.
It will not empty the Individual or Single General Pool unless one of the recovery jobs above has been scheduled for your tenant.
The automatic consolidation run will not look further back than last month. Older Batch Pool rows wait for Consolidate.
A queue row is not a promise. It means BigLedger has the document and LHDN has not seen it yet — nothing more.

What it is not

A pool is not a queue. A queued document is on its way; a pooled document is going nowhere until a run or a person moves it.
IN_QUEUE is not “in a pool”, and it is not an error. It means the record exists and is waiting to be sent.
“Processed” on a Batch Pool row does not mean “submitted”. It means the row is out of the consolidation run — and if it is also FAILED, it is stranded rather than finished. This is the most expensive misreading in e-invoicing.
A pool is not a list of mistakes. A Batch Pool full of walk-in receipts is a retailer working normally. An Individual Pool full of receipts is unreported revenue.

Where this sits in the rest of BigLedger

Before you can rely on any of it: the company’s E-Invoice Status must be ENABLED on the Organisation applet, and the pipeline’s clocks must be active on the Scheduler. The intermediary token refresh is a clock too; without it every run that talks to LHDN fails while the pools and the consolidation keep filling.
What decides the pool is set upstream, on the document: the point of sale leaves a new cash bill’s submission type blank, and the sales invoice starts at Individual. Change the habit at the till and you change which pool fills.
What it enables downstream: the consolidated e-invoice is built from the Batch Pool, and validation and clearance is what happens once the submitter has sent a record.
Pool or queue, and which pool instead of which: the sibling choice is the submission type. Consolidated goes straight to the Batch Pool and skips the individual check; blank gives the shopper an individual e-invoice when their details are complete and consolidates them when they are not.
What breaks elsewhere: one clock switched off stops that hop for every company in the tenant, and a failed send left past month-end turns a named customer’s sale into an anonymous one.
What it is paired with in practice: the My E-Invoice Admin applet, where the pools and queues are worked, alongside the Scheduler, where you confirm the clocks that move them.

How you know nothing is stuck — a five-minute check

The clocks. In the Scheduler, find E_INVOICE_GENERIC_DOCUMENT_TO_IRB_PROCESSOR, E_INVOICE_TO_IRB_SUBMISSION_PROCESSOR, E_INVOICE_TO_IRB_VALIDATION_STATUS_UPDATE_PROCESSOR, E_INVOICE_BATCH_PROCESSING_CYCLE_RUN_PROCESSOR and CONSOLIDATED_E_INVOICE_PROCESSOR. Each should be ACTIVE, and each due clock’s Last Run Date should be recent. A missing or inactive one is a question for BigLedger support.
The Posting Queue holds nothing unprocessed older than an hour, and no PROCESSED / FAILED row whose document lacks a Valid e-invoice.
To IRB E-Invoice, filtered to IN_QUEUE, holds nothing older than yesterday.
The Individual and Single General Pools hold only rows somebody is already working on.
The Batch Pool holds no unprocessed row older than last month, and no PROCESSED / FAILED row.

If all five hold, every finalised sale is either on its way to LHDN or waiting for this month’s consolidation.