The wrong number was keyed, and nothing stopped it — 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 when a cashier calls you over because a customer’s registration number or tax number went onto a bill wrongly, or a colleague billed the e-invoice to the wrong company altogether, and the bill is already final. In about ten minutes you will know why the till let it through, where the sale has got to, and the single correction that works at each stage. There are four stages and four fixes, and applying the wrong one wastes the only window you may have.

Step 1 — Know what the till checked, and what it did not

After this step you will stop expecting Final to have caught the mistake. When a bill is finalised BigLedger checks the money against the settlement lines, the location against the branch, the customer against the blacklist, serial numbers, batches and stock. It does not check whether the buyer’s tax number is real, whether the registration number belongs to that company, or whether the two match each other. On a bill of ten thousand or more your company may have told the till to insist the buyer block is filled in, but that check is for presence, not correctness: a wrong number in the right box passes it. The till is built to keep the queue moving and to leave the checking to the people and the systems that come afterwards. That is by design, and it is why the correction is now yours.

Reference: POS General — Lifecycle and posting

Step 2 — Know that the bill’s block beats the customer record

After this step you will avoid the correction that changes nothing. Whatever was typed into the buyer block on the bill is what goes to LHDN. The customer record is never read for that bill, not even to fill a blank field, because a block with anything in it wins the whole block. So if the cashier keyed a wrong registration number onto the bill, opening the customer record and correcting it there does nothing for this sale. It is the right thing to do for the next sale, and you should do it, but the fix for this bill has to touch this bill’s own block. From here on, when this lesson says correct the details, it means the copy on the document, which you reach through the pool or the e-invoice record in the admin applet, not the customer’s master record.

Reference: E-Invoice Validation Rules & Troubleshooting — Which record does BigLedger actually send?

Step 3 — Find where the sale landed

After this step you will know which of four places to look. At Final the sale entered the e-invoice posting queue, and a background job then ran the mandatory-field check on the buyer block. That check tests whether a name, a tax number, an identity type and value, an address with a first line, city and state, and a contact number of the right length are present. A block that is complete but wrong passes it, gets an e-invoice record, and is sent to LHDN, which will reject it. A block that is incomplete fails it and the sale is parked in a pool with the reason attached. The bill’s Progress sub-tab from the last lesson tells you which happened. If the Batch Pool stage shows a reason, it is in a pool. If the queue stage shows LHDN’s message, LHDN has already answered. If nothing is lit, it is in the Individual Pool.

Reference: My E-Invoice Admin Applet — 2 posting queue to irb or a pool cron e_invoice_generic_document_to_irb_processor

Step 4 — Fix it in the pool, and press the button that actually resubmits

After this step you will know why editing a number is not the same as resubmitting it. In the admin applet, find the bill in its pool, correct the buyer block, and use Save and Resubmit. That one action writes your corrections onto the document, re-runs the mandatory check, and if it passes creates the e-invoice record and queues it for LHDN. A retailer in the support corpus had edited a wrong registration number and then waited days wondering whether it would go through; nothing had been resubmitted, because the edit alone does not do it. One trap: a row you resubmit that fails the check again is marked processed and failed, and from then on the monthly consolidation no longer sweeps it. It is stranded until you fix it and resubmit again, so read the Validation Error and finish the job in one sitting.

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

Step 5 — Fix it after LHDN has said Invalid

After this step you will handle the case the cashier could not see coming. A complete but wrong block reached LHDN and came back Invalid, with a reason code: CF324 for an identity number that is not valid, CF358 for a tax number that is. The bill’s Progress sub-tab prints the first of those reasons on the queue stage. Two things to do, in this order. Correct the customer record, so every future sale to this buyer is right and so the next resubmission has something right to copy. Then open the e-invoice in To IRB E-Invoice, correct the block there, and Save and Resubmit. Type the number rather than pasting it, because a pasted number can carry an invisible character that fails every time. And note the date: what goes back to LHDN carries today’s issue time, so the resubmitted sale is recorded in this month, whatever the bill’s own date says.

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

Step 6 — Fix it after LHDN has said Valid

After this step you will know what a wrong-but-accepted e-invoice costs. LHDN validates the document it was given: a complete block naming a real, registered buyer comes back Valid even when that buyer is the wrong one for this sale, which is what happened to a branch in the support corpus whose colleague billed one company’s e-invoice to another. Now only two routes remain. Inside seventy-two hours of validation, finance raises a cancellation request and approves it with cancel for edit and resubmit if only the block was wrong, or with void original document if the sale should never have been billed to that party at all. Past seventy-two hours nothing can cancel it, and the correction is a credit note referencing the wrong e-invoice, with one detail that catches people: the buyer on the credit note has to match the buyer on the e-invoice it references, wrong name and all, or LHDN refuses it with DR308.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Know what the till checked, and what it did not"]
  s2["Step 2 — Know that the bill's block beats the customer record"]
  s3["Step 3 — Find where the sale landed"]
  s4["Step 4 — Fix it in the pool, and press the button that actually resubmits"]
  s5["Step 5 — Fix it after LHDN has said Invalid"]
  s6["Step 6 — Fix it after LHDN has said Valid"]
  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 customer wants their company on a bill they have already paid · Back to the series · Play this as a presentation