E-Invoice Statuses: What Recovers on Its Own, and What Nothing Re-drives

Part 3 of I finalised the invoice and nothing was submitted to LHDN: when every company stops at once, what the pipeline recovers by itself, what waits for a person, and what the screen cannot show you. It follows What each status means.

Everyone’s e-invoices stopped at the same time, and nothing here is wrong

This is the case where several companies — or every company in your group, or every company on the platform — stop getting e-invoices through on the same day, all of them sitting at In Queue, and nothing in any of your documents is wrong.

BigLedger submits to LHDN on your behalf in two layers. Each company’s token is asked for under its own tax number, on the authorisation that company gave BigLedger on the MyInvois portal, so a lapsed authorisation stops that one company (MyInvois setup). The tokens are asked for by one token-renewal clock per tenant, with the company’s own credentials where it has them and BigLedger’s shared credentials otherwise, and that layer is shared. When BigLedger’s credentials stop being accepted, every company that uses them fails at the same moment; when LHDN’s identity service is unavailable or the clock is not running, every company fails, its own credentials or not. Nothing about your invoice, your customer or your configuration has changed.

And you will see no error, for a specific reason. The job that renews the authorisation catches every failure and writes it to a log file that customers cannot see. It then carries on running on its schedule, being refused each cycle, with no alert, no e-mail and no marker on any document. The only outward sign is that documents stop leaving In Queue.

Half of it heals by itself. Documents that had not reached the send step yet are still valid, unsent work, and the next cycle after the outage sends them with nobody pressing anything. Documents the send step tried during the outage were refused, and their queue rows are marked failed: nothing re-drives those. Wait until support confirms the outage is over, then select the rows on Individual Submission whose queue row carries a refusal and press Submit. Do not resubmit while it is still going on: every attempt is refused again, and a call that timed out may still have reached LHDN.

How to tell this apart from a problem of your own, in under a minute:

• Is it more than one company, or more than one branch, or documents that have nothing in common? Shared-infrastructure problems are indiscriminate; your own configuration problems are specific.
• Are the affected documents all at In Queue with a clean record and no validation errors? A problem of your own usually shows up as Invalid or as a pool row with a stated missing field.
• Did it start abruptly, with documents from before that moment all Valid? Configuration problems start when somebody changes something; this starts when nobody did.

If all three are true, it is not yours to fix. Raise it with support with the time it started and the number of documents affected, and let the queue do its job.

What recovers on its own, and what nothing re-drives

The honest split, because knowing which side of it you are on is the difference between a wasted afternoon and a five-minute fix.

Recovers on its own. Every stage of the pipeline is a sweeper, not a one-shot job. Unprocessed posting-queue rows, records queued but not sent, and submitted records without a verdict are all re-selected by status on every single run. An e-invoice record left at Not Submitted is the exception: a separate submission-queue job sweeps those, and your tenant may well not run it, because the normal path queues the record in the same pass that creates it — check your Scheduler before counting on it. This is why a backlog drains by itself once whatever was blocking it clears, and why the right response to a platform-wide outage is patience.

Does not recover on its own. Four things, and none of them will tell you:

• A refused submission. When LHDN refuses the document, the record is stamped Failed Submission; when the call itself is refused (a credential, an outage), the record stays at In Queue. Either way the queue row is marked failed and keeps the reason. Nothing on the default schedule re-drives that row. The queue row carries a “remaining retries: 5” value that is written once and then never decremented and never read by any code — a failed row showing five retries remaining is not going to be retried.
  • There are two background jobs in the platform that could rescue such rows, and neither is in the scheduler set a tenant is given to start with — each needs a Scheduler crontab row somebody adds by hand. Assume they are not running for you until you have asked.
  • The one thing that does move such a record is month-end: once its month has ended, the consolidation run sweeps a refused sales e-invoice under RM 10,000 into the consolidated e-invoice under the General Public buyer — the sale is then reported, but not under the buyer you named.
• A verdict that never came. BigLedger polls LHDN for the verdict, but the poll gives up. While LHDN keeps answering “still validating” it is asked until LHDN’s own received-timestamp is three days old; a check that gets no usable answer once ten have been made ends it sooner (Validation and clearance owns the rule). Either way the poll instruction is deleted outright and no final status is written. The record keeps saying Submitted for ever, and nothing is asking any more. Every record that reaches that limit stays there, and only a month-end look for records still at Submitted after a day surfaces it.
• A document that never entered the pipeline at all. The platform contains a detector for exactly this — finalised, e-invoice-eligible documents with no pipeline row anywhere — and nothing schedules it — it needs a Scheduler crontab row that is not part of the set a new tenant is given. If a document falls out before it becomes an e-invoice record, the only thing that will find it is your own month-end reconciliation, through the Discrepancies Report.
• A pool row. The Individual and Single General pools wait indefinitely. That is a deliberate design — a pool never submits a document that is not ready — but it means nobody is coming. Pools & Submission Routing covers this in full.

What you cannot tell from the screen

Six things the listing does not show you, which is most of the reason this page exists:

1. Whether a queued row is waiting or failing. In Queue looks identical either way. The reason for a refused attempt lives on the submission-queue row behind the record, not on the record.
2. Whether anything is still polling for the verdict. A record at Submitted looks the same whether the poll is due in nine minutes or was deleted three days ago. Nothing on screen distinguishes a live wait from an abandoned one.
3. That three status values exist on one record, and they can disagree. A refused submission updates only one of them. Because the on-screen listing and the CSV export do not read the same one, the same document can show one status in the list and another in the export. If they disagree, the export is the stale one.
4. What the retry count means. It means nothing. See above.
5. Whether Submission History is current. Not quite a snapshot, and not quite live. One row is written for each submission LHDN accepted, carrying that attempt’s own LHDN document UUID; the record itself keeps only the latest UUID; and the validation poll writes its verdict onto the rows carrying the record’s current UUID only. So a document submitted twice shows two rows, and only the newest carries the live verdict — the older keeps its Invalid, or stays blank if its poll was abandoned — while the LHDN portal shows both attempts as Valid. The live status lives on To IRB E-Invoice. Never build your Invalid work list from Submission History.
6. Which processors your own tenant is actually running, and how often. The cadence is configured per tenant. The ten-minute figure in How long is normal is an illustration, not a promise about yours — ask your BigLedger contact if you need to plan against an exact number.

Checks and common mistakes for the whole guide

The thirty-second health check and the six common mistakes cover all three parts, so they are kept once, on the first: What success looks like and Common mistakes.