I submitted a wrong invoice and LHDN has already validated it. Can I cancel? Cancelling and correcting a validated e-invoice

“I submitted a wrong invoice and LHDN has already validated it. Can I cancel?” Only within 72 hours of LHDN validating it: inside that window you raise a cancellation request, approve it and send it to LHDN, then issue the corrected document; once 72 hours have passed no cancellation is possible at all, and the correction becomes a credit note that references the original.

You have just noticed that an e-invoice LHDN validated yesterday is wrong — wrong customer, wrong amount, or a sale that should never have been invoiced at all. You cannot simply edit it. What you can do depends almost entirely on one thing: whether 72 hours have passed since LHDN validated it. This guide gives you the decision in about five minutes and the fix in about ten.

Meet GadgetSphere

Yesterday afternoon a GadgetSphere branch invoiced a corporate customer RM 12,400 for a laptop refresh. This morning the customer calls: the order was for eight machines, not ten, and the invoice should be RM 9,920. The e-invoice went to LHDN last night and came back Valid. Nothing can be typed over it, so the question is which of two routes GadgetSphere is on.

The one rule that decides everything

Once LHDN marks an e-invoice Valid it is a filed tax record — that is what validation does, and it is why BigLedger refuses Save and Resubmit on it: “already validated with ‘Valid’ status. Please cancel it first before creating a new invoice.” The refusal is deliberate, not a bug. (You get a similar refusal at Submitted, which only means LHDN is still deciding; wait a few minutes and the status settles.)

Everything on this page follows from one date field on that record:

• Inside 72 hours of validation — cancel it at LHDN, then issue the corrected document.
• Past 72 hours — no cancellation is possible at all. The correction becomes a credit note referencing the original.

Before you start

• The e-invoice status is Valid. Nothing on this page applies to a document that is still in a pool or still IN_QUEUE — those you can simply fix and resubmit.
• You can open My E-Invoice Admin Applet → Monthly Report → Submission Detail Report, where the validation date-time is shown to the minute. The e-invoice’s own record on Internal Submission → To IRB E-Invoice does not show it.
• Somebody who can set a request to Approved on the Rejection Requests screen is available today. A cancellation request does not travel on its own; if the person who normally does it is on leave, you will run the clock out.
• For anything past the window, your accountant is in the loop. A credit note changes your reported figures.

Step 1: Work out whether you are still inside the window

Outcome: you know which of the two routes you are on before you touch anything.

My E-Invoice Admin Applet → Monthly Report → Submission Detail Report

Find the e-invoice by its document number and read the column headed Submission Date: that is its validation date-time, to the minute. Add 72 hours. If that moment is still ahead of you, go to Step 2. If it has passed, skip to Step 6.

GadgetSphere’s wrong invoice was validated at 21:40 last night, so the deadline is 21:40 two nights from now — comfortable, but not something to leave until the afternoon of the third day.

How this goes wrong: people count 72 hours from the invoice date rather than the validation date, which on a backdated or queued document can be days apart. Or they read a date off the e-invoice record on To IRB E-Invoice, where every date is shown without a time and none of them is the validation date. Read the Submission Date column.

Step 2: Raise the cancellation request

Outcome: a cancellation request exists against the e-invoice, waiting for approval.

My E-Invoice Admin Applet → Internal Submission → To IRB E-Invoice → Request for Rejection

Select the e-invoice and use Request for Rejection. The button is only enabled on a Valid e-invoice, which is your confirmation that you are on the right route. The request lands in Cancellation → Rejection Requests as requested and in progress.

A buyer can also start this from the My E-Invoice Portal Applet — a customer who spots the error before you do can raise the rejection themselves. It arrives in exactly the same list and needs exactly the same approval from you.

Step 3: Approve the request and choose what happens to the source document

Outcome: the request is approved with a decision recorded about the sales document behind it.

My E-Invoice Admin Applet → Cancellation → Rejection Requests

This is the step everyone misses.

Open the request, set the approval status to Approved, and choose a processing logic — what BigLedger should do when you process the request. Three of the four cancel the e-invoice at LHDN first and then act on the sales document. The fourth never talks to LHDN at all:

Two of these look alike on the screen and are not. Void original document first checks — before anything is sent to LHDN — that the sales document can actually be voided: it must still be Final, and nothing may have been raised from it (a payment matched to it, a return against it). If that check fails you see Can not void the generic document in the Cancellation Queue, and LHDN was never called. Cancel for edit and resubmit skips that check entirely, cancels at LHDN, and leaves the sales document exactly as it was, Final. It never voids anything.

For GadgetSphere’s over-invoiced laptop order the amount is wrong, so cancel for edit and resubmit is the wrong tool: the resubmit step can correct who the e-invoice is addressed to and what it references, never a quantity or an amount. The clean route is void original document — LHDN cancels, the invoice is voided with your reason recorded, and the branch raises a fresh invoice for eight machines, which gets its own e-invoice at Final. (Two machines short and the customer keeping the invoice? Then the correction is a credit note for the difference, Step 6, with the original left standing.)

After cancel for edit and resubmit. Open the now-Cancelled e-invoice in Internal Submission → To IRB E-Invoice, correct the buyer’s details or the reference there, and use Save and Resubmit. The button refuses a Valid or Submitted e-invoice and accepts a Cancelled one: it copies the corrected buyer and supplier identity, the original-invoice reference, the submission type and the billing period back onto the sales document, and puts the same e-invoice record back into the submission queue; LHDN issues a new identifier when it validates. Nothing on that screen edits a line — every line field is read-only — and editing the sales document in its own applet does not resubmit anything, because the e-invoice gate fires once, at Final. For a consolidated e-invoice, Save and Resubmit fails with Generic Document Not Found (there is no single document behind it); see Step 5 for what happens instead.

Step 4: Send the cancellation to LHDN

Outcome: LHDN has cancelled the e-invoice and the status on your record says so.

My E-Invoice Admin Applet → Cancellation → Rejection Requests → Process Request

With the request approved and a processing logic set, use Process Request. BigLedger builds a cancellation queue row and calls LHDN there and then. Watch the result in Cancellation → Cancellation Queue — the Request Error field on the row carries the reason if it did not go through.

Before it calls LHDN, BigLedger checks three things, and refuses on any of them: the e-invoice must be Valid, it must actually have an LHDN document reference, and fewer than 72 hours must have passed since validation — counted in whole hours, so 71 hours 59 minutes passes and 72 hours 0 minutes does not. If you see “Passed 72 hours from validation date time”, the window closed while the request was waiting for approval — go to Step 6.

What the answer looks like. When LHDN accepts the cancellation, BigLedger immediately asks LHDN for the document again and writes Cancelled and the cancellation time onto the e-invoice record, the Cancellation Queue row disappears, and the request reads completed with cancellation status Cancelled. A queue row you can still see is a row that failed: its Request Error carries either BigLedger’s own refusal or LHDN’s response text verbatim, and the request reads completed with cancellation status FAILED.

Two things follow from “completed”. Process Request will not pick that request up again — it only takes requests that are still in progress. If the failure is one you can fix (the wrong logic on a consolidated e-invoice, say), correct the logic on the request and use Process on the Cancellation Queue row itself; that re-runs the row with whatever the request now says. And do not wait for an e-mail: BigLedger does send one for every outcome, but it goes to the buyer’s e-mail address on the e-invoice, not to you. On a consolidated e-invoice it goes nowhere at all — consolidation fills the buyer’s e-mail with the placeholder NA, the address will not parse, and the send fails quietly after the statuses have already been saved. The Cancellation Queue row is your notification, and on a consolidated e-invoice it is your only one.

Step 5: If it is a consolidated e-invoice, act immediately

Outcome: the cancellation is under way despite the extra constraint consolidated e-invoices carry.

A consolidated e-invoice has no single sales document behind it — it reports hundreds of receipts at once. Only cancel for edit and resubmit works — and the other three fail in three different ways. Void original document is refused with “Can not void the generic document” before LHDN is called: nothing happens, and you have lost only time. Regenerate new e-invoice is the dangerous one. It cancels the e-invoice at LHDN first, then tries to rebuild it from a source document a consolidated e-invoice does not have — so the month’s consolidated e-invoice is Cancelled at LHDN and nothing replaces it. New reversal document fails on the same missing document, and that failure is only written to the log: no Request Error on the queue row, no e-mail, nothing on the screen.

Afterwards, the receipts that were inside the cancelled consolidated e-invoice still need reporting, and they will not come back on their own. Cancelling changed the e-invoice record and nothing else: every receipt still carries the cancelled e-invoice’s number, still shows as matched to it, and its Batch Pool row was used up when the month was first submitted. No scheduled run will pick those receipts up again, because the run only looks at Batch Pool rows that have not been used.

What has to happen is that a fresh Batch Pool row is created for each of those receipts, named one by one, after which the ordinary consolidation run gathers exactly those and nothing else. There is an endpoint that does precisely this, push-gendoc-to-batch-pool, and it refuses to give a receipt a second row if one is already open, so asking twice cannot double-report anything. It is not on any screen. This is support’s job, not a self-service action — ask for it in the same request, and ask for it in those words: “please push these documents back to the batch pool”, not “please re-run consolidation for March”, which would sweep in everything else in the month as well.

Step 6: Past 72 hours — issue a credit note instead

Outcome: LHDN’s records are corrected by a new document rather than by removing the old one.

My E-Invoice Admin Applet → Cancellation → Rejection Requests, or Sales → Internal Sales Credit Note Applet

There is no cancellation past the window. What you do instead is a new document that reverses the wrong one, referencing the LHDN identifier of the e-invoice that was wrong. Once it is validated, LHDN’s records net out correctly even though the original e-invoice is still there.

You have two ways to raise it. If a rejection request exists — yours or the buyer’s — open it: once 72 hours have passed, the processing-logic list on that request collapses to a single choice, new reversal document, and processing it builds the reversing document for you (a sales return for an invoice or cash bill, a credit note for a debit note), finalises it, and creates its e-invoice, all without touching the original. Otherwise raise the credit note by hand for the difference (or the whole amount) in the credit note applet. Either way, check the new document’s e-invoice reference before it is submitted — Step 7 is where a reversing document goes wrong.

For a consolidated e-invoice, the buyer on that credit note is General Public, exactly as it was on the consolidated e-invoice itself.

Step 7: Point the credit note at an original that is actually valid

Outcome: the credit note is accepted first time instead of being rejected for its reference.

A credit note is rejected if the e-invoice it references is no longer the live one. The classic case: the original was rejected as Invalid, somebody fixed and resubmitted it, and it came back with a new LHDN identifier — but the credit note is still pointing at the dead one. You will see one of two errors:

• Referenced document status (DR303) — the referenced e-invoice is not in a state that can be referenced.
• Buyer mismatch (DR308) — the buyer on the credit note is not the same buyer as on the referenced e-invoice. Matching the reference number is not enough; the identity has to match too.

Two ways out, both fine:

1. Update the credit note’s original-invoice reference to the currently valid e-invoice, then Save and Resubmit.
2. Clear the reference fields entirely and submit the credit note without a reference.

What we cannot see for you

If your buyer rejects an e-invoice on the MyInvois portal rather than through BigLedger, only the date comes back. The next time BigLedger fetches that e-invoice’s details from LHDN, it writes the rejection date into the e-invoice’s IRB Reject Request Date field on Internal Submission → To IRB E-Invoice. That is all: no request appears under Cancellation → Rejection Requests, nothing in your queues changes, and nobody is told. The field shows the date without the time. If a customer tells you they have rejected one of your e-invoices, check the portal yourself and act on it here — do not wait for BigLedger to notice.

What success looks like

Thirty seconds:

1. Open the e-invoice in Internal Submission → To IRB E-Invoice. Its status reads Cancelled (inside the window) — or it is still Valid and a validated credit note now references it (outside the window).
2. Cancellation → Rejection Requests shows your request as completed and approved, not still in progress.
3. The sales document behind it is in the state you chose in Step 3 — Void (void original document); still Final with a fresh e-invoice record beside the cancelled one (regenerate); still Final and waiting for your Save and Resubmit (cancel for edit); or still Final with a finalised reversing document next to it and the original e-invoice still Valid (new reversal document).

Common mistakes

Related documentation