Four choices, and what each one tells LHDN — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for whoever has to choose a processing logic on a rejection request at GadgetSphere and has noticed that the four names do not say what they do. In about twelve minutes you will learn which of them talk to LHDN, what one of them checks before it does, what each leaves the sales document as, and which one to pick for a wrong amount, a wrong buyer, and a consolidated e-invoice.

Step 1 — See that three cancel first, and one never calls LHDN at all

After this step you will not read the list as four flavours of cancel. Void original document, regenerate new e-invoice and cancel for edit and resubmit all do the same first thing: they send LHDN the cancellation and only then act on your side. New reversal document does not. It never contacts LHDN, never changes the e-invoice, and instead raises a second document that reverses the first. So the real choice is two questions asked in order. Is the e-invoice to be cancelled at LHDN, or left standing and offset? And if cancelled, what should become of the sales document behind it: voided, rebuilt as a new e-invoice, or left exactly as it is for you to correct? The next five steps take the four in that order, and the last one turns out to be the route the screen leaves you once the window has closed.

Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

Step 2 — Void original document: the dry run that happens before LHDN hears anything

After this step you will know why one refusal arrives with LHDN never having been called. Before this logic sends the cancellation it rehearses the void. It looks at the sales document and asks two things only: is it still Final, and has anything been raised from it, a payment matched against it, a return taken on it. If either fails, the row is marked failed with can not void the generic document, and LHDN was never contacted; the e-invoice is still Valid and you have lost nothing but time. Notice what the rehearsal does not ask. It does not apply the e-invoice refusals the ordinary Void button meets, the ones that make a sales invoice on an e-invoice-enabled company unvoidable. That is deliberate. This is the one path on the platform that voids such an invoice, and it may do so precisely because LHDN is being told first.

Reference: What a Void Undoes — When BigLedger refuses to void at all

Step 3 — Void original document: what happens after LHDN says yes

After this step you will check the document and not assume. Once LHDN accepts, BigLedger writes Cancelled onto the e-invoice record and then voids the sales document with the reason from your request, through the same fan-out the Void button starts: the reversing journal, the negated stock movements, the cash book line removed, the points taken back, each on the tenants that subscribe to it. Two cautions. First, the result of that void is discarded; if it fails after the cancel has succeeded, the e-invoice reads Cancelled, the document still reads Final, and nothing on any screen says so, so read the document’s posting status afterwards. Second, posting and unposting are separate subscriptions, and a minority of tenants hold one without the other; the void page shows how to find out which of the ten run on yours, and the answer is a test document.

Reference: What a Void Undoes — Which of the ten run on your tenant, and where the two lists differ

Step 4 — Cancel for edit and resubmit: no check, no void, and a resubmit that fixes who, not how much

After this step you will know what the word edit covers. This logic skips the rehearsal entirely, cancels at LHDN, and leaves the sales document as it was, Final, untouched. The resubmit half is yours. Open the now Cancelled record on To IRB E-Invoice, correct the buyer’s details or the reference there, and use Save and Resubmit; it refuses a Valid or Submitted record and accepts a Cancelled one, copies the corrected identity, references and submission type back onto the sales document, and puts the same record back in the submission queue, so LHDN validates it afresh and issues a new identifier. Every line on that screen is read-only. So GadgetSphere’s invoice for ten machines that should be eight is not a job for this logic: it corrects who and what is referenced, never a quantity. A consolidated e-invoice is different again, and the resubmit fails on it, because there is no single document behind it.

Reference: Cancelling and Correcting a Validated E-Invoice — Step 3: Approve the request and choose what happens to the source document

Step 5 — Regenerate new e-invoice: cancel first, rebuild second, and the two ways that goes wrong

After this step you will use regenerate only when the sale is right and the e-invoice was built wrong. It cancels at LHDN and then creates a fresh e-invoice record from the same sales document, with the buyer taken from the old record. Two things to know. The new record starts as unsent and the request does not queue it; on tenants that schedule the sweeper which queues unsent records it goes on the next tick, and elsewhere it waits for Save and Resubmit. And the rebuild only works for a buyer who qualifies for an individual e-invoice; otherwise you get the cancel and not the rebuild. That second point is what makes it dangerous on a consolidated e-invoice: the cancellation goes through, the rebuild has no document to work from, and a month of receipts is left unreported. That is not a hypothetical; the estate shows it has been done on a few tenants, many times over.

Reference: Cancelling and Correcting a Validated E-Invoice — Step 5: If it is a consolidated e-invoice, act immediately

Step 6 — New reversal document: LHDN is told nothing, and a second document appears

After this step you will not pick this logic expecting the e-invoice to change. It never calls LHDN. Instead it starts a job that clones the sales document into its reversal type, a sales return for an invoice or a cash bill, a credit note for a debit note, a debit note for a credit note, a receipt voucher for a refund note, creates that clone, finalises it through the normal Finalise chain so everything a finalise posts is posted, and gives it an e-invoice of its own. The original e-invoice keeps reading Valid, which is exactly what LHDN requires once a document can no longer be cancelled. That is the point of it. Once seventy-two hours have passed since validation, the Rejection Request screen removes the other three choices and offers this one alone; it is the past-the-window route, built for you, with the original left standing.

Reference: Cancelling and Correcting a Validated E-Invoice — Step 6: Past 72 hours — issue a credit note instead

How the steps fit together

    flowchart TD
  s1["Step 1 — See that three cancel first, and one never calls LHDN at all"]
  s2["Step 2 — Void original document: the dry run that happens before LHDN hears anything"]
  s3["Step 3 — Void original document: what happens after LHDN says yes"]
  s4["Step 4 — Cancel for edit and resubmit: no check, no void, and a resubmit that fixes who, not how much"]
  s5["Step 5 — Regenerate new e-invoice: cancel first, rebuild second, and the two ways that goes wrong"]
  s6["Step 6 — New reversal document: LHDN is told nothing, and a second document appears"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

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.

Next: The clock, on both sides of 72 hours · Back to the series · Play this as a presentation