What a consolidated e-invoice is made of, and what cancelling it does not touch — 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 at GadgetSphere has just cancelled a consolidated e-invoice, or is about to, and wants to know what that does to the four hundred cash bills inside it. In about eleven minutes you will see what a consolidated e-invoice is physically made of, which three records mark a receipt as reported, and why cancelling the e-invoice leaves all three exactly as they were.
Step 1 — Picture the thing you are about to cancel
After this step you will stop thinking of a consolidated e-invoice as a document. It is a summary with no document behind it. When the consolidation run gathers March’s walk-in cash bills, it builds one e-invoice header, gives it the General Public as buyer, and fills it with one line per receipt. What it never does is record a source document on that header, because there is no single source: four hundred cash bills cannot fit in a column that holds one. Every other e-invoice you deal with has that column filled, and almost everything on the cancellation screen is written expecting it. Hold on to that one absence. It is the whole reason three of the four cancellation choices fail on a consolidated e-invoice, and the reason Save and Resubmit tells you Generic Document Not Found.
Step 2 — Know what actually joins the receipts to it
After this step you will know where to look to find out which e-invoice reported a given receipt. One table does that job. As the run consolidates, it writes a link row for every document it swept in, joining that cash bill to that e-invoice header. Those link rows are the only structural connection between the two, and they are what the drill-down on the Discrepancies Report reads when it shows you the list of source documents inside a consolidated e-invoice. So if you want to know what was inside March’s e-invoice, you are asking that table, not the e-invoice’s lines. Remember this table too: it stays exactly as it is when the e-invoice is cancelled, and in the third presentation you will see the expensive consequence of that.
Reference: My E-Invoice Admin Applet — 8. Monthly Report → Discrepancies Report
Step 3 — Know that each receipt was stamped, one by one
After this step you will recognise the number on a cash bill for what it is. The moment LHDN accepted March’s consolidated e-invoice, BigLedger ran a single update across every member document and wrote three things onto each: the e-invoice’s running number, LHDN’s own document identifier for it, and the e-invoice date-time. That is why opening any walk-in cash bill from March shows an e-invoice number even though the customer never gave a name. It is not the receipt’s own e-invoice; it is the month’s, copied down. Nothing on the cancellation path ever clears those three columns. So after you cancel, every one of the four hundred receipts still displays an e-invoice number, and that number now belongs to an e-invoice LHDN has thrown away.
Step 4 — Know that the ticket that got each receipt there has been used up
After this step you will understand why nothing collects those receipts again. Every receipt reached the consolidated e-invoice through a Batch Pool row, which is best thought of as a ticket saying this document still needs reporting. Consolidation marks the ticket processed. Successful submission then deletes it, softly, so the row is still in the database but flagged as gone. The run that builds consolidated e-invoices only ever looks at tickets that are unprocessed and not deleted, and there is no code anywhere in BigLedger that turns a used ticket back into a fresh one. Not on cancellation, not on a schedule, not by any button. A receipt whose ticket has been spent is, as far as the run is concerned, finished with.
Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do
Step 5 — Watch what a cancellation actually changes
After this step you will be able to list the changes on one hand. When LHDN accepts your cancellation, BigLedger asks LHDN for the document again and writes back what it now says: Cancelled, with the cancellation time, onto the e-invoice record and onto its submission history. It deletes the cancellation queue row and closes the request. That is the complete list. It does not clear the number stamped on any receipt. It does not remove a single link row. It does not restore one Batch Pool ticket. The e-invoice record changes; the four hundred receipts behind it change in no way at all, and every screen that reads them still describes a month that was reported.
Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)
Step 6 — Take the thirty-second check away with you
After this step you will have one habit that protects a month. Whenever a consolidated e-invoice reads Cancelled, open it, use the drill-down to list the documents inside it, and treat every one of those as unreported until somebody confirms otherwise. Do not check the receipts themselves — they will show a number and look fine. Do not check the Discrepancies Report yet, for reasons the third presentation gives in full. The cancelled e-invoice record is, for now, the only honest thing on the screen. Across BigLedger’s customers, cancelled consolidated e-invoices turn up on about a fifth of tenants, and about a third of the receipts behind them have never appeared on any other e-invoice since. Those are months nobody noticed.
How the steps fit together
flowchart TD
s1["Step 1 — Picture the thing you are about to cancel"]
s2["Step 2 — Know what actually joins the receipts to it"]
s3["Step 3 — Know that each receipt was stamped, one by one"]
s4["Step 4 — Know that the ticket that got each receipt there has been used up"]
s5["Step 5 — Watch what a cancellation actually changes"]
s6["Step 6 — Take the thirty-second check away with you"]
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.
Answer key
- Nothing — it has no single source document, and that absence is what breaks three of the four cancellation choices — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back
- The cancelled e-invoice's number and LHDN identifier, unchanged — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back
- Each receipt's Batch Pool row was marked processed and then deleted, and nothing turns a used row back into an unprocessed one — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back
- The e-invoice record's status and cancellation time, its submission history, and the queue row, which is deleted — My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)
Next: Four buttons, one missing column: why three cancellation choices do nothing here · Back to the series · Play this as a presentation