I finalised the invoice and nothing was submitted to LHDN: understanding e-invoice statuses
“I finalised the invoice and nothing was submitted to LHDN” — in most cases nothing has failed and nothing is stuck: finalising only queues the work, scheduled background jobs send the e-invoice to LHDN afterwards, and a document still waiting for its next run shows no error because there is none.
You finalised a sales invoice this morning. It is mid-afternoon, the e-invoice still says In Queue, and there is no error anywhere — no red text, no warning, no message in any log you can reach. Nothing has happened, and nothing has complained. The e-invoice looks stuck.
It is queued, not stuck — and the absence of an error is the normal case, not a symptom. Ten minutes with this guide and you will be able to look at any e-invoice status and say three things about it — whether LHDN has ever seen the document, whether anything is actually wrong, and whether the right move is to wait or to act.
The guide is in three parts: this page, for the decision; What each status means, and how long is normal; and What recovers on its own, and what waits for a person.
Meet GadgetSphere
GadgetSphere Sdn Bhd runs 22 consumer-electronics branches across three companies. On a normal Saturday its tills finalise several thousand documents, every one of which becomes an e-invoice obligation. Nobody at GadgetSphere watches individual e-invoices go out — they look at statuses, and only when something looks wrong. Knowing which statuses mean “wrong” is the whole job.
The e-invoice is stuck — five things people mean by that, and where each one goes
Five sentences come up over and over, and they are five different situations with five different answers. Find yours here first; it will save you reading the rest.
| What you would say | What is actually happening | Where to go |
|---|---|---|
| “It is stuck in the queue and there is no error” | Almost always queued rather than stuck, and the absence of an error is normal | Nothing has happened and there is no error message, then Should I wait, or should I act? |
| “It has been sitting there for two days” | That is past normal. Something is waiting for a person | Should I wait, or should I act?, directly below — the overnight rule is the whole test |
| “It says Submitted and it never becomes Valid” | The verdict never arrived, and after a limit nothing is asking for it any more | What recovers on its own, and what nothing re-drives |
| “Every company stopped at once and nothing changed” | Usually not yours: BigLedger’s shared connection to LHDN. What was never sent goes by itself once it clears; what was refused while it lasted waits for Submit | Everyone’s e-invoices stopped at the same time |
| “There is no e-invoice row against the document at all” | It never entered the pipeline. A pool, or the company switch | Pools & Submission Routing |
The one rule that decides most of them: a document that has not moved since yesterday is stuck; a document that has not moved since this morning is almost certainly queued. Every stage of the pipeline re-selects its work on every run, so a row that survived the night has been passed over by dozens of runs, and that is not waiting.
Should I wait, or should I act?
Read the status first, then the clock. The decision is almost entirely determined by the two together. Each status is explained in full on What each status means.
| What you see | Wait or act | What to do |
|---|---|---|
| In Queue, less than an hour old | Wait | It is inside the normal cycle. Check again after lunch |
| In Queue, since yesterday | Act | Open Internal Submission → Individual Submission (the queue, not To IRB E-Invoice, which has no Submit button), select the rows and press Submit. If they stall again, raise it with support — nothing will retry them for you |
| In Queue across several companies at once | Wait, report, then Submit | Shared-infrastructure outage, if the three checks under Everyone’s e-invoices stopped at the same time all hold. Tell support when it started. Once support says it has cleared, Submit the rows whose queue row carries a refusal; nothing retries those |
| In Consolidated Queue, any age inside the month | Wait | This is the monthly consolidation working as intended |
| Submitted, less than a day old | Wait | LHDN is validating. BigLedger refuses a resubmission in this state on purpose — “already submitted and pending LHDN validation” |
| Submitted, more than a day old | Act | The scheduled check may have stopped asking (What recovers on its own, and what nothing re-drives). Open the record and press Refresh; if it still reads Submitted, take it to support with the document number |
| Invalid | Act | Read the reasons on the record, fix the underlying customer or item data, and resubmit |
| Failed Submission | Act | Read the reason on the record or its queue row, fix it and press Submit. Nothing will re-drive it |
| Valid | Nothing to do | Done. If you need to change it, you have 72 hours to cancel, then it is a credit note |
| No e-invoice row at all against a finalised document | Act | The document never entered the pipeline. Check the pools first, then raise it — nothing sweeps for this |
What each status means, and which ones mean LHDN has never seen your document
Every status, the three families they fall into and the one gap that costs the most to misread are on What each status means, with why a waiting document shows no error and how long each stage normally takes.
“Valid”, “Invalid” and “Cancelled” — the authority has answered
These three mean LHDN has answered — a verdict, or a cancellation it accepted — and BigLedger has written the answer back onto the record: Valid, Invalid and Cancelled.
What you cannot tell from the screen
Six things the listing does not show you — whether a queued row is waiting or failing, whether anything still polls for a verdict, why the list and the export can disagree — are on What you cannot tell from the screen, with what recovers by itself and what nothing re-drives.
What this page will not tell you
Stated plainly, because guessing here is worse than not knowing:
- It will not tell you why a specific document is stuck. The reason lives on the submission-queue row or the validation response, and reading it needs the document number in front of you.
- It cannot give you a guaranteed time to LHDN. The timings in this guide are measured across tenants, not a service level. Your own cadence may differ and LHDN’s response time is not ours to promise.
- It does not cover incoming supplier e-invoices. Documents arriving from your suppliers run through a different pipeline with a different vocabulary: Incoming Supplier E-Invoices.
- It does not cover PEPPOL delivery statuses. PEPPOL is a separate channel with its own queue and its own states: PEPPOL Configuration.
- It is not an incident status page. It can tell you what a platform-wide outage looks like from your screen; it cannot tell you whether one is happening right now.
- It will not tell you it is safe to resubmit a Submitted document. BigLedger refuses that on purpose, and so should you — the guard exists because the direct-submit path does not check for an already-accepted document, and a document filed twice at LHDN is a 72-hour cancellation problem or a credit note.
What success looks like
Thirty seconds on Internal Submission → To IRB E-Invoice in the My E-Invoice Admin Applet, filtered to yesterday and earlier:
- No rows at In Queue. Anything from today is fine; anything from yesterday is stuck.
- No rows at Submitted older than a day. Submitted is a state documents pass through, not one they live in.
- No rows at Failed Submission. Every one is a person’s job.
- Everything else is Valid, Invalid or Cancelled — an answered state, whether or not you like the answer.
If all four hold, your pipeline is healthy, whatever today’s rows are doing.
Common mistakes
- Reading In Queue as “submitted”. LHDN has no record of the document yet, so a month-end tally that counts In Queue rows as filed comes out wrong.
- Resubmitting during an outage. Every attempt is refused again, and a call that timed out may still have reached LHDN, the commonest way to put the same sale there twice (a cancellation inside 72 hours, or a credit note after); wait for the all-clear, then Submit only the rows that carry a refusal (Everyone’s e-invoices stopped at the same time).
- Waiting on a stalled row because it shows retries remaining. Nothing reads that number, so nothing re-drives the row: select it and press Submit (What recovers on its own).
- Trusting a record at Submitted to resolve itself eventually. It usually does, in minutes; past a day the check may have stopped asking, and then nothing writes the verdict: press Refresh on the record (Should I wait, or should I act?).
- Building the Invalid work list from Submission History. Once a document is resubmitted, its older rows are never updated again and keep a stale verdict (What you cannot tell from the screen, item 5). Use To IRB E-Invoice.
- Assuming a finalised document produced an e-invoice at all. One finalised while its company was not enabled, or that fell out before a record was made, has no status to find; only the monthly Discrepancies Report catches it.