Resubmit, and prove it landed

Play this lesson as slides — one slide per step, with the same narration. The full text 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 the most common support question in e-invoicing will never be yours. 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 it will carry it forever unless something rebuilds it. That something is a resubmission button, which copies your corrections back onto the document and builds a fresh record. Until you press one, nothing you fixed has reached anywhere that matters.

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 back to the customer and the document, 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 and use Save and Resubmit there. It does the same work: copies your corrections back to the source document and re-queues the document for LHDN. 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 a filed tax record cannot be edited. 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. This worries people, and it should not. Resubmitting keeps the original document date, so an August sale corrected on the third of September is still an August sale in your books and on the report. What does change is the issue time stamped on the e-invoice itself, because LHDN requires that to be the actual moment of submission and refuses a backdated one. BigLedger sets it for you and preserves the transaction date separately, so you lose nothing. Fix it when you find it; do not sit on a rejection to protect a period.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 5: 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: 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 lesson: What runs without you, and what never will · Back to the course