Resubmit, and prove it landed — 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 the master data is now correct — and the rejection is still sitting there, unchanged, looking exactly as wrong as it did before you started. That is expected, and this lesson explains why and what actually moves it. In about eleven minutes you will learn the two resubmission buttons, what each refuses, and the thirty-second check that ends the job.

Step 1 — Understand why nothing changed

After this step you will not need to ask support why a corrected customer still fails. The e-invoice record is not your invoice. When a document passes the completeness check, BigLedger builds a separate record and sends that: the buyer, the supplier, the addresses, the totals, all frozen exactly as they were at that moment. Correcting the customer afterwards changes the customer and nothing else. The frozen copy still carries the old tax number, and resubmitting will not fetch the new one: Save and Resubmit sends the buyer that record already holds and never reads the customer again. So correct the buyer on the record’s own Account tab, then resubmit. The customer correction is still worth making, but it helps the next sale, not this one.

Reference: E-Invoice Submission Mechanics — The record that goes to LHDN is not your invoice

Step 2 — Resubmit from a pool row

After this step a held document is either on its way or has told you what is still wrong. Open the row in whichever pool holds it, complete the missing fields on its Account tab, and press Save and Resubmit. Three things happen in order: your corrections are written onto the document’s own e-invoice details, not the customer record, the mandatory-field check is run again, and — only if it passes — the e-invoice record is created and queued for LHDN. If the check fails again the reason is back in Validation Error. On a Batch Pool row there is a sting as well: the row is now marked processed and failed, so the monthly consolidation will not pick it up either, and that is the stranded state from lesson one. An Individual or Single General row simply stays where it was. Either way, look at the row after you press the button rather than assuming.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 3 — Resubmit from the e-invoice record

After this step you can clear a rejection from the screen where you found it. On Internal Submission, then To IRB E-Invoice, open the Invalid row, correct the buyer on its Account tab, and use Save and Resubmit there. It sends that Account-tab buyer, copies your corrections back to the source document, and puts the same record back in the queue for LHDN; it does not make a new one. It refuses in exactly two situations, and both refusals are helpful. On an e-invoice LHDN has already validated it tells you to cancel that one first, because it is already a filed tax record. On one that is merely submitted it tells you to wait for the validation response, because LHDN has not finished deciding. In some companies this button is deliberately hidden so that all corrections are made in the pools instead.

Reference: My E-Invoice Admin Applet — 5. Fixing an Invalid e-invoice from To IRB E-Invoice

Step 4 — Know when the other button is the right one

After this step you can handle a rejected consolidated e-invoice without guessing. Beside Save and Resubmit there may be a second button, Resubmit as New E-invoice, which is switched off by default and has to be enabled in the applet’s settings. It behaves differently by type: for a consolidated e-invoice it builds a whole new consolidated payload, for a single general one it resubmits that single document as a consolidated e-invoice of its own, and for an individual one it creates a fresh record. It refuses on a validated e-invoice, and it refuses when the source document is still sitting in a pool. Where the button is not switched on, Save and Resubmit is your only route.

Reference: My E-Invoice Admin Applet — Applet settings

Step 5 — Fix the right side of a consolidated rejection

After this step you will not waste time correcting a buyer you are not allowed to change. On a consolidated e-invoice, the buyer block is not yours: BigLedger sets it to General Public with the general public tax number, and every line carries the classification code LHDN reserves for consolidation. You cannot type over any of it, so a rejection on a consolidated document is almost never about the buyer. Read the error and look at your own side instead: on a consolidated e-invoice the state on your company address is a documented one, and that address is the supplier block on every one of these. Correct it in the Organisation applet, then resubmit the consolidated e-invoice from To IRB E-Invoice.

Reference: Consolidated e-invoices — How it behaves in BigLedger

Step 6 — Keep the sale in its own month

After this step you can fix a rejection late without moving revenue into the wrong period, and you know which rejections cannot wait. Resubmitting keeps the original document date, so an August invoice of RM 10,000 or more corrected on the third of September is still an August sale in your books and on the report. The issue time stamped on the e-invoice does change, because LHDN requires it to be the actual moment of submission; BigLedger sets it and preserves the transaction date separately. A rejected sale under RM 10,000 is different: it will not be there on the third. The first consolidation run after midnight on the 1st sweeps it into the consolidated e-invoice under the General Public buyer. So fix those in the last days of the month.

Reference: Month-end e-invoicing: check the Batch Pool, and work the Invalid list before the run — Step 4: Work the Invalid list

Step 7 — Watch it to Valid, then prove it in thirty seconds

After this step you know when the job is finished, and finished is a specific word. After a resubmission the row moves to a queued status, then to Submitted, which means LHDN has the payload and is still deciding — usually minutes. Then it becomes Valid, with an LHDN identifier and a QR code, and only then is the sale reported. Submitted is not reported. The proof is two lines: open To IRB E-Invoice, filter to the document you fixed, and check the status reads Valid; then open the customer you corrected and check the identity type and tax number are right there too, so the next sale never reaches this list.

Reference: LHDN rejected it. Where do I find out why? E-invoice validation rules & troubleshooting — What success looks like

How the steps fit together

    flowchart TD
  s1["Step 1 — Understand why nothing changed"]
  s2["Step 2 — Resubmit from a pool row"]
  s3["Step 3 — Resubmit from the e-invoice record"]
  s4["Step 4 — Know when the other button is the right one"]
  s5["Step 5 — Fix the right side of a consolidated rejection"]
  s6["Step 6 — Keep the sale in its own month"]
  s7["Step 7 — Watch it to Valid, then prove it in thirty seconds"]
  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.

Next: What runs without you, and what never will · Back to the series · Play this as a presentation