Validation and clearance
Watch these as presentations — 5 on this page, slides with narration.
“MyInvois shows Valid but BigLedger shows Invalid” — then you are looking at two copies of one verdict, and only one of them is LHDN’s. Malaysia runs a clearance model: an invoice becomes a tax record when LHDN examines it and answers Valid, and from that moment nothing on it can be typed over. The status in BigLedger is a copy of that answer, written when BigLedger last asked. This page is what the gates before Valid do to a document, what LHDN sends back and where BigLedger writes each piece, why Valid is a one-way door, and where the 72-hour clock really starts. The steps — reading a rejection, cancelling, crediting — are in the guides at the end.
Why it exists
The old arrangement was that you invoiced whoever you liked and the tax authority found out later, if it audited you. Clearance reverses that: the authority sees the document first, so the record it holds and the record you hold are the same one by construction. That is why the correction path after Valid is narrow by design — a filed record is withdrawn or answered by a second document, never edited.
One design choice inside BigLedger follows from it and surprises people. The buyer block on the e-invoice is deliberately separate from the customer account on the sale. A walk-in who paid cash and later asks for an e-invoice in their employer’s name, or a person who buys a laptop for the company that will claim it back, gets an e-invoice whose buyer is not the account you billed — and that block is completed or corrected in the My E-Invoice Admin applet, not at the till and not on the customer record. The consequence for this page: LHDN validates the e-invoice. A Valid e-invoice whose buyer differs from the account is the feature working, and a Valid e-invoice can still be for the wrong amount, which is what cancellation and credit notes are for.
How it behaves in BigLedger
Three gates, not one
They fail in ways that look alike from a distance — “my e-invoice isn’t at LHDN” — and have different fixes.
1. BigLedger’s own check. Before anything is sent, the posting run looks for the mandatory fields: both parties’ name, tax number, identity type and value, and a contact number of 8 to 20 characters; your industry code and business-activity description; an address on each side with line 1, city and state; the e-invoice’s currency, date-time and totals; and on every line the item name, classification, tax type, unit of measure, price and tax amount. On a sales document whose submission type is Single General the buyer’s fields are not checked. Any gap is written onto a pool row as “Buyer TIN is missing”, one line per field, and the document waits in a pool. LHDN was never called, and it will not be until the field is filled and the row resubmitted.
2. LHDN at the door. The submitter sends the payload and LHDN answers at once with two lists, accepted and rejected. BigLedger counts the call a success only when a document was accepted. Accepted: the record reads Submitted, holding LHDN’s document identifier and submission identifier, and a poll row is written to fetch the verdict. Rejected at the door, or the call itself failed: the submission-queue row behind the record goes SUBMISSION_FAILED with LHDN’s response text, and the record’s process status reads FAILED_SUBMISSION — but the E-Invoice Doc Status column you filter on keeps reading IN_QUEUE, because the refusal writes one column and not the others. Nothing exists at LHDN for that document.
3. LHDN’s validation. A scheduled check asks LHDN about each Submitted document, twenty a run, every ten minutes on the default clock, and copies the answer onto the record. LHDN’s vocabulary is exactly four words:
- Submitted — LHDN has it and is still deciding. Usually minutes.
- Valid — accepted. The record now carries the validation time, a validation link and a QR code, and it is a filed tax record.
- Invalid — accepted for processing, then rejected on content, with the reasons written onto the record. Fix the source data and resubmit. Since 13 October 2026 the month-end consolidation sweep also takes an Invalid record under RM 10,000 once its month has ended, and reports the sale inside the consolidated e-invoice under the General Public buyer, so a business buyer who needs their own e-invoice has to be fixed before the run fires.
- Cancelled — a validated e-invoice that was subsequently cancelled at LHDN, with the cancellation time.
What comes back, and where BigLedger writes it
Everything you read about a verdict is a stored copy, written at one moment — and three of the copies are built by BigLedger, not received.
| What you see | Stored or built | Written when, from what |
|---|---|---|
| E-Invoice Doc Status on To IRB E-Invoice | A copy of LHDN’s word | By the scheduled check, or by Refresh, from LHDN’s answer for this record’s own document identifier. Between asks it is whatever it was last time |
| LHDN Document and LHDN Submission | Stored | At the door, from LHDN’s acceptance. A record without the first has never been at LHDN; Refresh is greyed out on it for that reason |
| Validation date-time | Stored, LHDN’s own clock | Parsed from LHDN’s validated-at timestamp the moment the verdict is Valid, held in universal time (UTC). Shown to the minute only in Monthly Report → Submission Detail Report, as the Submission Date column; every date on the To IRB screens is a date without a time, and none of them is this one |
| Validation URL and the QR | Built by BigLedger | On Valid: LHDN’s own page for the document, from the environment’s host, the document identifier and LHDN’s long identifier. The QR encodes that link and nothing else. Empty before Valid, and the same image on the printout, the e-mail and the export |
| Validation errors on an Invalid record | A copy | LHDN’s failed validation steps, each as code: message, one per line, written when the verdict arrived; the details screen parses them into a table. Correcting the data does not change this text — the next verdict replaces it |
| E-Invoice Status on a Submission History row | A copy | Written onto the rows carrying the record’s current LHDN document identifier. The row’s Submission Status is a snapshot from the moment of sending and stays “Submitted” whatever LHDN decided; a row from an earlier attempt keeps its old verdict |
| Submitted that has not moved for days | Stale | The scheduled check deletes its own poll row after ten unanswered asks, or once LHDN has held the document as Submitted for three days — and writes nothing. The record keeps reading Submitted until someone presses Refresh |
| The buyer’s e-mailed PDF | Sent by a run | On Valid, a non-consolidated record is queued for the validated-PDF e-mail run, which sends it to the buyer e-mail on the e-invoice only where the company’s Send Email To Buyer switch is on. Refresh never sends it; Resend Email does |
Valid is a one-way door
BigLedger refuses Save and Resubmit on a Valid record — “already validated with ‘Valid’ status. Please cancel it first before creating a new invoice.” — and on a Submitted one, because LHDN has not finished. Resubmit as New E-invoice is refused on a Valid record for the same reason. From Valid, the only movements are a cancellation inside the window, or a second document that references the first.
The door swings one way for the buyer too. A customer can reject your e-invoice on the MyInvois portal within the same 72 hours; when they do, the next time BigLedger fetches that document’s details only the date lands on the record, as IRB Reject Request Date. No request appears in your Rejection Requests list and nobody is told. Watching for a buyer’s rejection is a person’s job: when a customer says they have rejected one, check the portal and act on it yourself.
The 72 hours, and the two routes
Inside the window the route is a cancellation request: raise it from the record, have somebody approve it and choose what happens to the sales document behind it — void it, regenerate the e-invoice from it, cancel at LHDN only and fix it yourself, or raise a reversing document instead — then process it. Nothing advances a request on its own; one raised and left sits until the window closes. Under an e-invoice-enabled company the Void button refuses a sales invoice, return, credit, debit or refund note, so the cancellation’s Void original document choice is the one route to voiding one. A consolidated e-invoice has no single sales document behind it and takes one choice only — cancel-for-edit-and-resubmit; the others fail, one of them after LHDN has already cancelled the month. Cancelling and Correcting a Validated E-Invoice walks every step.
Past the window there is no cancellation. The correction is a new document that reverses the wrong one — a credit note or sales return — referencing the original’s LHDN document identifier; once that is Valid, LHDN’s records net out and the original stands. On a rejection request that has run past 72 hours the screen collapses to a single choice, New reversal document, which builds and finalises that document for you and never calls LHDN. Point the note at the e-invoice that is currently Valid: a reference to an earlier, superseded identifier comes back DR303, and a note whose buyer differs from the original’s comes back DR308.
Which route, and whether the original should go at all, is a decision for the person who owns the figures, with the accountant: in most cases the ledger is already right and only the tax reporting is overstated, so the credit note exists to fix LHDN, not the books.
The duplicate that was, and the one that was not
Two situations from the support record, with the names removed.
A retailer found one cash bill reported inside two consolidated e-invoices, both Valid. The newer one was still inside its 72 hours and was cancelled; the receipts inside it that still needed reporting were pushed back to the Batch Pool and consolidated again by explicit list, not by date range. Three older documents, each validated twice, were past the window — and the only correction left for those was a credit note against each surplus e-invoice. One mistake, two prices, decided by nothing but the clock.
Another believed 185 of its e-invoices were duplicates; 129 were still inside the window, so cancellation was open. None was a duplicate. A sales invoice and a self-billed purchase invoice can legitimately carry the same document number — at GadgetSphere Distribution, an outgoing invoice to a corporate client and a self-billed invoice from a small supplier can share one — and matched by number alone they look like one document filed twice. The advice was to cancel nothing. Had the 129 gone through, that many valid tax records would have been withdrawn at LHDN and would have needed re-issuing.
Deciding what is a duplicate is a person’s job, and the moment is before Request for Rejection: check the document type and the buyer on both rows, not the number. Cancelling is the destructive operation in this module, and the window that makes it possible is also the window in which a misreading does the most damage.
When LHDN and BigLedger disagree — what you see, why, what to do
| What you see | What it means | What to do |
|---|---|---|
| MyInvois says Valid; the record has read Submitted since yesterday | The scheduled check has stopped asking about this record (ten unanswered asks, or three days at Submitted) and nothing wrote the verdict | Open the record and press Refresh. If it turns Valid, use Resend Email — Refresh sends nothing |
| MyInvois says Valid; BigLedger says Invalid | You are reading an older attempt — a Submission History row from an earlier identifier, or the CSV export, which reads a different status column — or the record was resubmitted and its newest attempt has not been polled yet | Read E-Invoice Doc Status on Internal Submission → To IRB E-Invoice, filtered to the record; wait one poll; Refresh if it still disagrees |
| MyInvois has nothing; the record reads IN_QUEUE | Never sent, or rejected at the door — the refusal is on the submission-queue row, not on the record | Read the queue row’s Request Error, fix what it names, resubmit (pools and queues) |
| Invalid, with reasons on the record | LHDN rejected the content. Under RM 10,000 and left past month-end, it is swept into the consolidated e-invoice under General Public (since 13 October 2026) | Fix the source data and Save and Resubmit: Validation Rules & Troubleshooting |
| Request for Rejection was enabled, and the cancellation failed Passed 72 hours | The screen counted by your browser’s clock; the backend counts whole hours from the stored UTC time | The window is closed. Issue a credit note or sales return against the original |
| The e-invoice is Valid and the cash bill behind it was voided at the till | A cash bill can be voided after its e-invoice is Valid, and the e-invoice stays Valid at LHDN with no sale behind it (the guard meant to refuse the void while a submission is in flight is a known issue, reported to engineering) | Whoever voids a bill tells the person who runs My E-Invoice Admin, who cancels inside 72 hours or raises a credit note |
A credit note comes back Invalid with DR303 or DR308 | It references an e-invoice that is no longer the live one, or names a different buyer from the original | Point it at the currently Valid identifier, or clear the reference and submit without one |
| The original still reads Valid after a request was processed | The request was processed with New reversal document, which raises a reversing document and never cancels | That is what the choice does. Inside the window pick another; past it, this is the only one offered |
What it is not
- Submitted is not Valid. A month whose documents all read “Submitted” is not a month that has been reported, and a record that has read Submitted for days has usually been dropped by the check, not delayed by LHDN.
- 72 hours is not a submission deadline. There is no rule that an invoice must reach LHDN within 72 hours of being raised. It is the cancellation and buyer-rejection window, and nothing else.
- Validation is not a check of your accounting. LHDN validates structure, identities and codes. An e-invoice can be perfectly Valid and still be for the wrong customer or the wrong amount.
- The QR is not a signature of yours. It is LHDN’s validation link, built by BigLedger from the identifiers LHDN returned. Scanning it opens LHDN’s page for that document, not anything of yours.
- Valid is not proof the buyer has it. The PDF goes out by a scheduled run, to the buyer e-mail on the e-invoice, and only where the company’s switch is on. A consolidated e-invoice carries no buyer address to send one to.
- Cancelled in BigLedger is not reversed in your books. The cancellation changed the e-invoice record; what happened to the sales document is whichever choice was made on the request.
Where this sits in the rest of BigLedger
- Before any of it works: the company’s E-Invoice Status is ENABLED on the Organisation applet; the intermediary token refresh, the submitter and the status check are active on the Scheduler — without the token every call to LHDN fails while the queues keep filling; and the record has a complete buyer block, or it never leaves a pool.
- What Valid makes possible: the validation link and QR your customer can check; the validated-PDF e-mail; credit, debit and refund notes that reference it; and an e-invoice lifecycle feed an integration can collect, with one event for each verdict. Invalid is what the fix loop works; Cancelled is what a request produces.
- Sibling choices: on an Invalid record, Save and Resubmit re-queues the same record after copying your corrections back to the sales document, while Resubmit as New E-invoice builds a fresh record, with a consolidated variant that re-links every member receipt to the new one (admin applet §5). On a Valid one, a cancellation removes the record at LHDN and a credit note answers it; inside the window the choice is yours and turns on whether the original should go; past it there is one.
- What breaks elsewhere when this is wrong: a resubmitted original gets a new identifier and every credit note still pointing at the old one is rejected (sales credit note); a cash bill voided after Valid leaves LHDN holding a sale your books no longer have (POS); a consolidated e-invoice cancelled with the wrong choice leaves every receipt inside it unreported, and the Discrepancies Report reads clean because the receipts are still attached to it (month-end); a company whose Send Email To Buyer switch is off accumulates unsent rows in the e-mail queue (admin applet §4b).
- What it is paired with in practice: the My E-Invoice Admin applet — To IRB E-Invoice for the verdicts, Rejection Requests and the Cancellation Queue for the window, the Submission Detail Report for the time — alongside the MyInvois portal, which is the only place a buyer’s rejection shows in full.
How you know a month is cleared — a five-minute check
- To IRB E-Invoice, E-Invoice Doc Status = Submitted: nothing older than today. Press Refresh on anything older — it is almost certainly dropped, not pending.
- Filtered to Invalid: every row has a name against it, and none is dated last month. Once the consolidation run fires for that month it takes those under RM 10,000 into the General Public e-invoice, and the 7th will not wait for the rest.
- Open one Valid record you rely on: the Validation URL opens LHDN’s page for that document and the QR renders. On a Valid record with neither, press Refresh: it rebuilds both from LHDN’s answer.
- Cancellation → Rejection Requests: nothing sits at requested / in progress without an approval and a processing choice. Each one is a clock running.
- For every e-invoice you intend to cancel: its Submission Date in the Submission Detail Report plus 72 hours is still ahead of you, by a margin you would bet on.
If all five hold, every verdict BigLedger shows you is LHDN’s current one, and nothing you still mean to withdraw has slipped past the window.
Read next
- Understanding E-Invoice Statuses — every status word, which ones mean LHDN has never seen the document, and when to stop waiting
- Validation Rules & Troubleshooting — why LHDN rejects a document and which of your records to fix
- Cancelling and Correcting a Validated E-Invoice — both routes, step by step, including the consolidated case
- My E-Invoice Admin Applet — the To IRB E-Invoice, Submission History, Rejection Requests and Cancellation Queue screens, field by field