Fix a rejection

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 status column on To IRB E-Invoice has just shown you a row that reads Invalid, or a pool that is not empty. In about twelve minutes you will learn to tell which of two checks a document failed, read the reason on it, fix the cause where it actually lives, and get the document back to the Inland Revenue Board, LHDN, as Valid. Most fixes take under two minutes once you know which record to open.

Step 1 — Tell BigLedger’s rejection from LHDN’s

After this step you can say, from the status alone, whose check a document failed and therefore what kind of fix it needs. There are two checks. BigLedger’s comes first: before anything is sent, it looks for the mandatory fields, both parties’ tax number, identity type and value, an address with line one, city and state, the currency and dates, and the line codes. A document missing any of them is held in a pool with the reason attached. Nothing reached LHDN, and nothing will until you complete it. LHDN’s check comes second. A document that passed BigLedger’s check and was sent can come back Invalid: LHDN accepted the submission and rejected the content, and an LHDN error code is on the record. From a distance both look like “my e-invoice is not at LHDN”. They need different fixes, so read the status before you touch anything.

Reference: E-Invoice Validation Rules & Troubleshooting — The two kinds of failure

Step 2 — Recognise a failure to send

After this step you will not mistake a transmission failure for a rejection. There is a third state that belongs to neither check. A document that passed BigLedger’s check but could not be delivered stays In Queue, and its queue row is stamped as a failed submission with the reason in its request error. LHDN never saw it, so there is no LHDN code, and a failed attempt writes nothing to Submission History. Open the row in Internal Submission, then Individual Submission, and read the request error. If it says the access token is not available, that is the authorisation problem from the last lesson, and editing the document will not help. The rule is simple: a pool row is BigLedger’s, an Invalid row is LHDN’s, a failed queue row is the connection between them.

Reference: My E-Invoice Admin Applet — Troubleshooting

Step 3 — Build the Invalid list from the right screen

After this step you have the complete list of last month’s rejections in front of you. Go to Internal Submission, then To IRB E-Invoice, filter to last month, and sort on the status column; the Invalid rows gather at the top. If you prefer a spreadsheet, the Export tab gives you the same rows with a status column you can sort. What you must not do is build the list from Submission History. It is a snapshot from the moment each document was sent, so it says Submitted for a document that LHDN later rejected, and you will get a short, reassuring list while real rejections sit unfixed. For each Invalid row, open it and read the rejection reason. Most of GadgetSphere’s rejections come from one field group, the buyer’s identity, and that is where the next step starts.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 5: Work the Invalid list

Step 4 — Read a buyer identity error

After this step you can read the two commonest LHDN codes and name the fix. Every e-invoice carries the buyer’s tax identification number, their TIN, plus an identity document type and its value. Almost every rejection anyone has recorded comes from that field group alone. The rule is short: Passport for anyone not Malaysian, a business registration number for a company, a national identity number only for a Malaysian individual, as 12 digits with no dashes. Three shapes account for almost every rejection: a tourist at a Penang branch keyed under a national identity number instead of a passport; a national identity number stored with hyphens; a company registration number typed into the identity number box. The codes are CF324, not a valid national identity number, and CF358, invalid buyer TIN. If a tax number looks right and keeps failing, retype it by hand; a pasted number can carry an invisible character.

Reference: E-Invoice Validation Rules & Troubleshooting — Get the buyer’s identity right — this is where most rejections come from

Step 5 — Read the other codes you will meet

After this step you can work one more code properly and you know where the rest are written down. DC511 is currency. On a foreign-currency invoice, say a sale of four thousand eight hundred US dollars to a Singapore distributor, the document currency is US dollars and the base currency must still be ringgit, MYR. If someone keyed both as US dollars, correct the base currency on the source document, not on the e-invoice. The codes you meet less often are about credit-note and debit-note references, state codes, and the classification that marks a line as consolidated. Each has its own fix, and the validation page lists them with the fix beside each one. Read them there when one turns up, rather than memorising them now.

Reference: E-Invoice Validation Rules & Troubleshooting — Common validation errors and fixes

Step 6 — Fix it where it lives

After this step you will fix the record that was actually sent, once, instead of the e-invoice, repeatedly. Buyer identity and address belong on the customer record in the Customer Applet, so the next sale to that customer is right too. But first check which record BigLedger read. If someone typed an e-invoice buyer block onto the sales document itself, that block wins and the customer record is never read; and a half-filled block still wins the whole block, sending the other fields blank. That is the baffling case where a document fails on a field you can see is right on the customer. Fill the block completely or empty every field of it. And if many documents fail together with no customer in common, look at your own company record in the Organisation Applet: it is the supplier side of every sales e-invoice, and one bad state or missing city fails all 22 branches at once.

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

Step 7 — Resubmit and watch it to Valid

After this step the document is back at LHDN and you know what proves it. Fixing the customer record changes nothing on the e-invoice; it is a frozen copy. Go back to the row, in the pool or on To IRB E-Invoice, and use Save and Resubmit. It copies your corrections onto the document, re-runs BigLedger’s check and, if that passes, creates a fresh record and queues it. A correction made on the 3rd keeps the original document date, so an August sale stays in August. Then watch the row to Valid, not Submitted, which only means LHDN is still deciding. On an Invalid consolidated e-invoice the buyer block is fixed by BigLedger, so look at your own side first, typically the state on your company address; fix it, then Save and Resubmit, or Resubmit as New E-invoice where that button is switched on. Dozens of tax numbers to correct? Tools, then Bulk TIN Validation, takes one CSV.

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

How the steps fit together

    flowchart TD
  s1["Step 1 — Tell BigLedger's rejection from LHDN's"]
  s2["Step 2 — Recognise a failure to send"]
  s3["Step 3 — Build the Invalid list from the right screen"]
  s4["Step 4 — Read a buyer identity error"]
  s5["Step 5 — Read the other codes you will meet"]
  s6["Step 6 — Fix it where it lives"]
  s7["Step 7 — Resubmit and watch it to Valid"]
  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: Close the cycle · Back to the course