The error families and the record behind each

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 you have a list of codes in front of you. Every code belongs to a family, and every family points at exactly one record — usually not the e-invoice you are looking at. In about twelve minutes you will learn the six families you will actually meet and where each one is really fixed, which is the difference between correcting a rejection once and correcting it every month.

Step 1 — The buyer’s identity, and the record that holds it

Every e-invoice carries the buyer’s tax number together with an identity document type and the number that goes with it. That one little group of fields causes more rejections than everything else in e-invoicing put together. The rule is short enough to keep in your head. Passport for anyone who is not Malaysian. Business registration number for a company. National identity number only for a Malaysian individual, and only as twelve digits with no dashes in them. And one habit matters as much as the rule: type the number, never paste it. A number copied out of a browser or a PDF can bring an invisible character with it, and the field will look perfectly right on screen while LHDN rejects it every single time.

Fix it on the customer record, in the Customer applet’s E-Invoice tab — unless somebody typed buyer details onto the sales document itself, which beats it. Lesson four is how to tell.

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

Step 2 — When you do not have the buyer’s tax number

After this step you know which substitutes LHDN allows and which it refuses. There are general tax numbers for the cases where a real one is not available, and the rules around them are narrow enough that most rejections in this family come from stretching one. The general public number works on an individual e-invoice only alongside a Malaysian identity type and a valid twelve-digit number; any other combination is refused. A company that gave you a registration number needs its real tax number, or, below ten thousand ringgit, consolidation instead. The government number is not a general stand-in. And watch the second half of this family: a line carrying the classification code LHDN reserves for consolidation makes an individual e-invoice invalid even when the tax number is perfect.

Reference: E-Invoice Validation Rules & Troubleshooting — General TINs — when you don’t have the buyer’s TIN

Step 3 — Currency, which is fixed on the sales document

After this step you can clear a currency rejection in one edit, in the right place. GadgetSphere’s distribution arm buys and sells in US dollars with regional distributors, so this family belongs to that company rather than to the retail branches. On a foreign-currency invoice the document currency is the foreign currency and the base currency must still be ringgit, with the exchange rate recorded. Key both as US dollars and LHDN refuses it, saying the foreign target currency should always be ringgit. The important part is where you fix it: on the source sales document, not on the e-invoice record, because the e-invoice is a copy of what the document said. Correct the base currency there and resubmit.

Reference: E-Invoice Validation Rules & Troubleshooting — 1. Wrong currency setup on foreign-currency invoices

Step 4 — The state on an address

After this step you can clear a state rejection and stop it recurring at a branch. LHDN wants the state as a number, not as text, and BigLedger does the translation for you — it tries an exact match on the official name, then the same with punctuation stripped, then a partial match either way, then a list of common abbreviations. That covers most of what a counter will actually type. When nothing matches, the code is simply left empty and the document waits for someone to key a real state. There is no safe catch-all: the old not-applicable code is rejected outright, for Malaysian and foreign addresses alike. Key the state in the spelling LHDN uses and the guesswork disappears.

Reference: E-Invoice Validation Rules & Troubleshooting — Malaysian state codes

Step 5 — A credit note pointing at a dead original

After this step you can fix the family that looks impossible because the note itself is perfect. A credit note, debit note, refund note or sales return carries a reference to the original e-invoice. If that original was rejected once and resubmitted successfully, it now has a new LHDN reference, and your note may still be pointing at the one that died. Two codes live here, and they mean different things. One says the e-invoice you referenced is in a state that cannot be referenced. The other says the buyer on your note is not the buyer on the original, so getting the reference right is not enough on its own. Point the note at the currently valid original, or clear both reference fields and submit it without one.

Reference: E-Invoice Validation Rules & Troubleshooting — 3. Credit or debit note references an original that is no longer valid

Step 6 — Your own company record, which fails everything at once

After this step you will recognise the family that has no customer in it. Every sales e-invoice carries a supplier block, and that block is your own company: its name, tax number, registration number, industry classification, business activity, address and contact number, all of them on LHDN’s mandatory list. They come from the company record, so one bad field there does not fail one document — it fails every document, from all twenty-two branches, on the same day. The signature is a wall of rejections with no customer in common, often on a field you have never touched. Before you open a single customer, open the Organisation applet and read your company’s e-invoice identity.

Reference: E-Invoice Validation Rules & Troubleshooting — Which address

How the steps fit together

    flowchart TD
  s1["Step 1 — The buyer's identity, and the record that holds it"]
  s2["Step 2 — When you do not have the buyer's tax number"]
  s3["Step 3 — Currency, which is fixed on the sales document"]
  s4["Step 4 — The state on an address"]
  s5["Step 5 — A credit note pointing at a dead original"]
  s6["Step 6 — Your own company record, which fails everything at once"]
  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 lesson: Fix it at the source, not on the e-invoice · Back to the course