Correct with a credit note — transcript
Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.
This lesson is for you if you run the books at GadgetSphere and a wrong e-invoice can no longer be cancelled: the 72 hours ran out, or the mistake surfaced at month-end, weeks after validation. In about ten minutes you will agree the correction with your accountant, raise a credit note that references the wrong e-invoice, point it at the right original so the Inland Revenue Board, LHDN, accepts it first time, and confirm that LHDN’s records now net out. LHDN gets a new document rather than losing an old one.
Step 1 — Recognise that you are past the window
After this step you will stop trying to cancel and start correcting. There are three ways to arrive here. The cleanest is that you read the validation date-time, added 72 hours, and the moment has passed. The most painful is the message on the Cancellation Queue row: Passed 72 hours from validation date time. It means the request was raised in time and then sat, unapproved, until the window closed, and the portal’s countdown may have suggested more time than the record actually held. The third is the month-end reconciliation, which is where most wrong e-invoices are found, usually weeks after validation. Whichever it was, the position is the same. Past 72 hours there is no cancellation at all, not by support, not by LHDN’s own portal. Nothing you press in the Rejection Requests screen will change that, so leave it and open the sales side instead.
Reference: Cancelling and Correcting a Validated E-Invoice — Step 4: Send the cancellation to LHDN
Step 2 — Agree the correction with your accountant
After this step you know whether the credit note is fixing LHDN, your books, or both. In most of these cases GadgetSphere’s ledger is already right. When the customer called about the laptop order, the branch corrected the sale in the books that morning; what is overstated is only the tax reporting at LHDN, which still holds a Valid e-invoice for RM 12,400. The credit note exists to fix LHDN, not the books, and if you raise it as if it were also a book correction you will have corrected the same thing twice. A credit note changes your reported figures either way, so this is a conversation to have before you raise it, not after. Agree the amount, which is the difference or the whole amount, and agree what the credit note is for, in one sentence you can both repeat when the auditor asks in a year.
Reference: E-Invoice Validation Rules & Troubleshooting — 4. The same sale looks like it is at LHDN twice
Step 3 — Raise the credit note against the wrong e-invoice
After this step a credit note is on its way to LHDN, tied to the e-invoice it corrects. Go to Sales, then the Internal Sales Credit Note Applet, and raise a credit note for the difference, RM 2,480 for GadgetSphere’s laptop order, or for the whole RM 12,400 if the sale is being reversed entirely. The one thing that makes it a correction rather than an unrelated document is its reference: it must carry the LHDN identifier of the e-invoice that was wrong. A credit note is an e-invoice document type in its own right, so the moment you finalise it, BigLedger queues it into the same pipeline as any sale, and it goes through the same completeness check and the same LHDN validation. Once LHDN validates it, LHDN’s records net out to RM 9,920 for that order, even though the original e-invoice is still there and still reads Valid. That is the intended end state.
Step 4 — Point it at an original that is actually valid
After this step the credit note is accepted first time instead of coming back Invalid for its reference. LHDN rejects a credit note whose referenced e-invoice is no longer the live one. The classic case: the original was rejected as Invalid, then fixed and resubmitted under a new LHDN identifier, while your credit note still points at the dead one. You will see one of two codes. DR303 means the referenced document is not in a state that can be referenced. DR308 means 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 must match too. Two ways out. Update the credit note’s reference to the currently valid e-invoice, then Save and Resubmit. Or clear the reference fields entirely and submit it without one. Debit notes, refund notes and sales returns reference an original the same way and meet the same two codes.
Step 5 — Know which of the four notes the rules ask for
This step is the rule book rather than BigLedger, and the two are worth keeping apart. LHDN’s e-Invoice Guideline gives the four types different jobs. A credit note reduces the value of an e-invoice already issued — a late discount, goods returned, an over-charge — where no money goes back to the buyer. A debit note does the opposite: it adds to the value of one already issued, which is what GadgetSphere raises when it under-charged. A refund note confirms money actually returned. So the question is never which is easiest to raise, but which of the three describes what happened. That is LHDN’s rule and not a BigLedger behaviour. It is paragraph one point four of the e-Invoice Guideline, version four point six of seven December twenty twenty-five, and the page that records that version shows you how to see whether LHDN has moved on.
Reference: Which LHDN Guideline Version This Wiki Cites — The rules this wiki states, and where each one sits
Reference: What Malaysia Requires: E-Invoicing Explained — What goes on an e-invoice
Step 6 — Credit a consolidated e-invoice
After this step you can correct a consolidated e-invoice that is past its window. It happens: a receipt was reported twice, once individually and once inside the month’s consolidated e-invoice, and nobody noticed until the reconciliation. The credit note works the same way, with one difference. The buyer on it is General Public, exactly as it was on the consolidated e-invoice itself, because that is the buyer LHDN holds for the document you are referencing; a named customer on the credit note would fail the buyer-match check from the last step. One thing to watch on the way out. BigLedger’s automatic RM 10,000 divert covers sales invoices and cash bills only, so a credit note of RM 10,000 or more marked Consolidated is not diverted for you. Check where it landed. Once the receipts are inside a validated consolidated e-invoice, cancellation inside 72 hours and a credit note after it are the only two routes there are.
Reference: Consolidated e-invoices — How it behaves in BigLedger
Step 7 — Confirm that LHDN’s records net out
After this step you can show that the correction is complete. The credit note is an e-invoice with its own row, so go to Internal Submission, then To IRB E-Invoice, and find it by its Doc No. Watch it to Valid, not Submitted, which only means LHDN is still deciding. Then open the original. It still reads Valid, and that is correct: outside the window the original never changes, and what proves the correction is the validated credit note that references it. Keep the pair together for month-end. The CSV export from To IRB E-Invoice carries, for credit and debit notes, the reference to the original e-invoice, so an auditor can see which document corrected which without asking you. For GadgetSphere’s laptop order the end state is two Valid rows: the RM 12,400 invoice and the RM 2,480 credit note against it, and that pair is what proves the correction.
Reference: Cancelling and Correcting a Validated E-Invoice — What success looks like
How the steps fit together
flowchart TD
s1["Step 1 — Recognise that you are past the window"]
s2["Step 2 — Agree the correction with your accountant"]
s3["Step 3 — Raise the credit note against the wrong e-invoice"]
s4["Step 4 — Point it at an original that is actually valid"]
s5["Step 5 — Know which of the four notes the rules ask for"]
s6["Step 6 — Credit a consolidated e-invoice"]
s7["Step 7 — Confirm that LHDN's records net out"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
s6 --> s7
Check yourself
Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.
Answer key
- A credit note referencing the wrong e-invoice's LHDN identifier — Cancelling and Correcting a Validated E-Invoice — Step 6: Past 72 hours — issue a credit note instead
- The buyer on the credit note is not the buyer on the e-invoice it references — E-Invoice Validation Rules & Troubleshooting — 3. Credit or debit note references an original that is no longer valid
- The currently valid e-invoice, or no reference at all — Cancelling and Correcting a Validated E-Invoice — Step 7: Point the credit note at an original that is actually valid
- General Public, as on the consolidated e-invoice — Cancelling and Correcting a Validated E-Invoice — Step 6: Past 72 hours — issue a credit note instead
- It still reads Valid, and a validated credit note now references it — Cancelling and Correcting a Validated E-Invoice — What success looks like
Next: When a buyer rejects · Back to the series · Play this as a presentation