E-Invoice Statuses: What Each One Means, and How Long Is Normal
Part 2 of I finalised the invoice and nothing was submitted to LHDN: what each e-invoice status means, why a document that has not moved shows no error, and how long each stage normally takes. The decision it supports, Should I wait, or should I act?, is on the first part; What recovers on its own comes next.
Nothing has happened and there is no error message
This is the situation where a document has been finalised, its e-invoice shows In Queue or nothing at all, and no error appears anywhere. Almost always, nothing has failed. Here is why the absence of an error is the normal case rather than a symptom.
Finalising a document does not send anything to LHDN. Finalise is a separate operation from saving, and all it does is put work on a queue. The work is then carried out by a chain of scheduled background jobs, each of which does one step and hands on to the next:
- Finalise queues the document’s primary processor and returns immediately. Your cashier’s screen is already free.
- A secondary processor decides where this document belongs: straight into the pipeline, or held in one of the three pools because something required is missing. If it goes into the pipeline it becomes a posting-queue row, still entirely inside BigLedger.
- A scheduled job turns that posting-queue row into an e-invoice record — the row you can finally see on Internal Submission → To IRB E-Invoice — and, in the same pass, puts it on the submission queue.
- A second scheduled job takes it off the submission queue and calls LHDN.
- A third scheduled job asks LHDN for the verdict and writes it back.
Five steps, three of them on timers. And here is the part that explains the silence: every one of those jobs selects its work by status, every time it runs. No job holds a document in flight. A run that finds nothing it can do simply ends, and the next run picks up the same rows. The one exception is a send LHDN refuses: that row is marked failed and is not tried again (What recovers on its own). There is no failed operation to report, because nothing was ever attempted and lost — it was queued, and queued is where it still is.
So when a document has not moved, there is usually no error to show you. There is only a row that is still waiting for its next cycle.
What each status means, and which ones mean LHDN has never seen your document
Statuses on the e-invoice record fall into three families, and the single most expensive mistake is reading a status from the first family as though it belonged to the second. Every status name below is what BigLedger stores and what the listing shows you.
“In Queue” and “Not Submitted” — LHDN has not accepted this document
Not Submitted means the e-invoice record has just been created and has not yet been put on the submission queue. In Queue means it is on the submission queue, waiting for the job that makes the call.
Both mean the same thing in the only sense that matters to you: LHDN has no record of this document. If your customer scans the QR code on the receipt, or follows a “track your request” link, they will get nothing — not because the link is broken, but because there is nothing at the other end yet.
One wrinkle worth knowing, because it is invisible: In Queue also covers “we tried and were refused”. When a submission is attempted and LHDN rejects the call itself — a bad credential, an unreachable service — the record stays at In Queue and the reason is written onto the submission-queue row, not onto the record you are looking at. So In Queue reads as “waiting” whether it has been waiting quietly or failing loudly. When LHDN takes the call and refuses the document itself, the record is marked Failed Submission instead (below).
Consolidated e-invoices carry their own version of this, In Consolidated Queue, and it means something different: this document is deliberately waiting for the monthly consolidation run, and it is meant to sit there. That is not stuck. See The Month-End E-Invoice Cycle.
“Submitted” — LHDN has the document and has not ruled on it yet
Submitted is written only when LHDN has accepted the payload and handed back a document identifier, which BigLedger stores on the record. That identifier is your proof the submission landed.
Submitted is not the finish line. It means the authority is validating and has not yet said Valid or Invalid. It is normally a state a document passes through in minutes, not one it sits in.
“Valid”, “Invalid” and “Cancelled” — the authority has answered
Valid is the finish line: LHDN validated the document, and BigLedger writes back the validation timestamp, the QR code and the validation URL. This is the state in which the e-invoice is legally your tax document.
Invalid means LHDN rejected it, and the reasons are written back onto the record for you to read and fix. Invalid is a working state, not a disaster — see Validation Rules & Troubleshooting.
Cancelled means a Valid e-invoice was cancelled inside LHDN’s 72-hour window. After that window the correction is a credit, debit or refund note referencing it: Cancelling and Correcting.
“Failed Submission” — a send was attempted and refused
This is the one status that is unambiguously a problem needing a person. It means LHDN took the call and refused the document, and the reason is written onto the record and onto the queue row behind it. (A call refused before LHDN looked at the document, such as a bad credential, leaves the record at In Queue instead.)
The vocabulary, side by side
| What you are looking at | What it actually means | Has LHDN seen it? |
|---|---|---|
| Not Submitted | The e-invoice record exists; it is not yet queued to send | No |
| In Queue | Queued to send — or the call was refused before LHDN looked at the document, with the reason on the queue row | No |
| In Consolidated Queue | Deliberately held for the monthly consolidation run | No, and not yet meant to be |
| Submitted | LHDN accepted the payload and returned a document identifier; awaiting the verdict | Yes, verdict pending |
| Valid | LHDN validated it. QR code and validation URL written back | Yes, accepted |
| Invalid | LHDN rejected it, with reasons written back onto the record | Yes, rejected |
| Cancelled | A Valid e-invoice cancelled inside the 72-hour window | Yes, then withdrawn |
| Failed Submission | LHDN took the call and refused the document; the reason is on the record and the queue row | Yes, and refused it at submission |
How long is normal, and what changes it
Each of the three scheduled stages runs on its own timer, and that timer is a setting on your tenant, not a platform constant. Work your own expectation out from your own settings: a stage set to fire every 10 minutes adds up to ten minutes of waiting, and the three stages add up one after another.
Ten minutes a stage gives you the honest expectation: under an hour, end to end, on a normal day — and usually well inside it, because each stage picks a row up on its next tick rather than at the end of the interval.
What legitimately makes it longer:
- Consolidated submission. A retail receipt marked for consolidation is supposed to wait until the monthly run. It will show In Consolidated Queue for most of a month, and that is correct. It is the commonest reason an e-invoice looks late when nothing is wrong.
- Volume. A Saturday at 22 branches puts a lot of rows through a ten-minute cycle. The queue drains in order; it does not lose anything.
- A slower timer on your tenant. The submission stage can be set to 25, 30 or 35 minutes instead of ten, which stretches the whole chain with it.
- A missing detail. A document with no buyer tax number never enters this pipeline at all — it goes to a pool and waits for a person. That is a different problem with a different page: Pools & Submission Routing.
A worked example. On a Saturday afternoon a walk-in buys a flagship smartphone at branch GS-KV-03 and asks for an e-invoice in his employer’s name, so the cash bill is marked for individual submission with the company’s tax number. He finalises at 14:20. The e-invoice record appears by about 14:30, reaches the submission queue by 14:40, is accepted by LHDN by 14:50, and shows Valid by 15:00 — the QR code on his copy now resolves. If he had scanned it at 14:35 it would have shown nothing, and nothing would have been wrong.
And what should make you suspicious: a document still at In Queue the next morning is not waiting, it is stuck. A stage that is running takes a batch of its status on every tick, so unless a large backlog is queued ahead of it, a row that has survived the night has been passed over by dozens of runs. That is not waiting. If it has been overnight and the queue ahead of it is short, treat it as stuck rather than slow.
Where this sits in the rest of BigLedger
A status is the visible end of a chain that starts three modules away, and most “wrong status” questions are really questions about one of these links.
What must exist before any of this works. A document only enters the pipeline when e-invoicing is switched on for its company — the switch lives on the company’s E-Invoice tab in the Organisation applet, and it depends on the MyInvois authorisation being in place first. Finalise a document while the company switch is off and there is no e-invoice record to have a status at all: nothing fails, nothing warns, and the gap only surfaces in the month-end Discrepancies Report. The document itself must also be finalised rather than saved — saving is not a trigger, and a draft sitting in the Sales Invoice applet will never acquire a status.
What becomes possible once a document is Valid. Only then does the QR code on the printed receipt resolve, only then can the validated PDF be e-mailed to the buyer, and only then does the 72-hour cancellation window open. Everything downstream of e-invoicing hangs off that one state.
Its sibling, and when you are looking at the wrong one. A queue and a pool both look like “waiting”, and they are opposites. A queue is work the system will carry out by itself on a timer; a pool is work it has deliberately set aside for a person, because something required is missing. Use this page when the document has a status; use Pools & Submission Routing when it has none. The quickest test: if you can see a row on To IRB E-Invoice, it is in the pipeline.
What breaks elsewhere when this is wrong. A status that is wrong is rarely only a status. A document stranded at In Queue is a sale reported to nobody, so your month-end tally to LHDN is short; the buyer’s own purchase records have no matching e-invoice, so their reconciliation fails too; and if the shortfall is only noticed after the 7th, the correction is a backdated consolidation rather than a resubmission. Nothing in sales, inventory or the general ledger is affected — the sale itself posted correctly at Finalise, and e-invoicing is a reporting layer over the top of it. That separation is deliberate, and it is why an e-invoice problem never costs you your books.
What it pairs with in practice. In the daily routine this page is used alongside the Discrepancies Report, and the two answer different halves of the same question: this page tells you what happened to a document you can see, and the report tells you which documents you cannot see because they never produced an e-invoice at all. Checking one without the other leaves a blind spot on each side.
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.