LHDN rejected it. Where do I find out why? E-invoice validation rules & troubleshooting

“LHDN rejected it — where do I find out why?” On the e-invoice record itself: open it in My E-Invoice Admin > Internal Submission > To IRB E-Invoice, and its Validation Error Table lists what LHDN returned — the field, the error code and the message in English and Malay. If the document is waiting in a pool instead, LHDN never saw it, and the pool’s Validation Error panel names the missing fields.

E-invoice validation fails in one of two ways, and telling them apart is most of the battle. By the end of this page you will be able to read any rejection, know which of your records to fix, and get the document through. Most rejections come down to a single field group, and most fixes take under two minutes once you know where to look.

Meet GadgetSphere

GadgetSphere Sdn Bhd sells across 22 branches, so its customer list runs from walk-in shoppers who give nothing but a phone number, through corporate buyers with a registration number, to tourists paying with a passport. Nearly every rejection GadgetSphere sees comes from that mix being keyed inconsistently at the counter — and the examples below are the ones its finance team works every month.

The two kinds of failure

An e-invoice passes two checks, not one — BigLedger’s own completeness check first, LHDN’s content check second. Both produce the same complaint from a distance, “my e-invoice isn’t at LHDN”, and they need completely different fixes. So check the status before you touch anything:

• Held in a pool — a mandatory field was missing, so the document was never sent. Nothing reached LHDN and nothing will until you complete it. Pools & Submission Routing says which pool and why.
• Submitted, then marked Invalid — everything mandatory was there, LHDN accepted the submission and rejected the content. There is an LHDN error code on the record, and that code is what tells you which of your records to correct.

Get the buyer’s identity right — this is where most rejections come from

Every e-invoice carries, for both parties, a tax identification number (TIN) plus an identity document type and its value. Get any part of it wrong — the wrong kind of document, or the right number in the wrong shape — and LHDN refuses the e-invoice.

The rule is short:

• Business registration number (BRN) for a company.
• Passport for an individual who is not Malaysian — never a national identity number.
• National identity number (NRIC) only for a Malaysian individual, and only as 12 digits with no dashes.
• Type it. Don’t paste it.

Read the first two rules together: passport is the rule for a person, not for anyone non-Malaysian. A Singapore or Hong Kong company is not an individual, and it does not take a passport — it takes a business registration number, carrying the number its own home country issued it, alongside the EI00000000030 General TIN for a foreign supplier or EI00000000020 for a foreign buyer.

Three shapes of mistake produce those refusals:

• A foreign customer keyed under NRIC instead of Passport. A passport number is not 12 digits, so LHDN rejects it as an invalid national identity number. Fix the identity type in two places: on the e-invoice record’s Account tab, for the document LHDN has already rejected, and on the customer record, for the next sale.
• A national identity number stored with hyphens. The rule is 12 digits and nothing else, and the hyphens alone are enough to have the document refused — the same number without them passes.
• A business registration number typed into the national-identity field. It is the right number in the wrong box.

The two error codes you will see for this class are CF324 (the identification number is not a valid national identity number) and CF358 (invalid buyer TIN). Both are fixed in two places. On the e-invoice record LHDN marked Invalid, correct the buyer on its Account tab in My E-Invoice Admin and use Save and Resubmit — the record sends its own copy of the buyer, taken when it was built, and correcting the customer changes nothing on it (why). Then correct the Customer Applet as well, so the customer’s next sale is right too.

Mandatory fields

Document header

Every e-invoice needs, at minimum:

• Supplier: name, TIN, identity type + value, industry classification code, business activity description, address, contact number
• Buyer: name, TIN, identity type + value, address, contact number
• Document: e-invoice type and version, issue date/time, currency code
• Amounts: subtotal, total excluding tax, total including tax

Line items

Each line needs an item classification code (LHDN’s list of around 45 codes), an item name, a unit price, a tax type code and a tax amount. Only the item name has to be there: the other four are filled in for you before anything checks. A classification left blank on the line is read from the item record, and if the item has none either it becomes 022 – Others; a missing price or tax amount becomes zero; the tax type is taken from the document line’s own e-invoice tax type — not from the item — and the tax amount then has the last word over it.

If the line’s tax amount is blank or zero, the tax type is set to 06 – Not Applicable whatever was keyed; if there is a tax amount but the tax type is blank, or still reads 06, it becomes 01 – Sales Tax. Any other tax type keyed against a real tax amount is sent as it stands.

Addresses

Both the supplier and the buyer address must carry an address line 1 (up to 150 characters), a city (up to 50) and a state. Address lines 2 and 3 (150 characters each) and a 5-character postal code are optional. Anything longer than the limit is shortened silently rather than rejected. The postcode is never checked against any list on the way to LHDN — it is cleaned, cut to five characters and sent as typed. A postcode not found message comes from the address screen’s own lookup, the platform-wide postcode list behind its typeahead, and has no bearing on whether the e-invoice goes through.

If address line 1, city or state is missing, the document is not submitted at all — it goes to a pool for you to complete.

Which record does BigLedger actually send?

Before you go correcting a customer record, make sure it is the record the e-invoice was built from. There are two places the other party’s details can live — the customer or supplier record, and an e-invoice block typed directly onto the sales or purchase document — and the document wins.

Whichever record is used, the other party’s name is cleaned before it goes: anything outside letters, digits, spaces and - / ( ) . , & ' is deleted, a full-width ＆ becomes &, and the result is cut at 300 characters. Your own company name is sent exactly as stored. LHDN treats a Valid e-invoice as final, so a name that went out with a character removed stays as sent — check names carrying unusual punctuation before the first submission. The apostrophe was itself stripped until July 2026, so an older Valid e-invoice for O’Brien Trading may carry OBrien Trading and is correct as far as LHDN is concerned.

Which address

If your customer has several addresses on file: BigLedger sends the first address flagged as the e-invoice address, looking in this order: shipping, then billing, then main. Flag exactly one and the guesswork disappears. If the buyer’s details were typed straight onto the sales document rather than pulled from the customer record, that typed address is used exactly as entered.

Another buyer, or another address, on one sales invoice

The buyer on an e-invoice does not have to be the customer you billed. An employee pays for a laptop his employer will claim; one company in your group buys on behalf of another; a corporate client of GadgetSphere Distribution has one account and one monthly statement, but each of its branches wants the e-invoice to carry the address of the branch that took the goods. The E-Invoice tab of a sales invoice has a button for this — and which button you get depends on one switch. You never see both.

The switch is on the E-Invoice tab of the sales invoice applet’s Settings → Application Settings; on an English screen its label reads HIDE_SELECT_FROM_ANOTHER_CUSTOMER_BUTTON. Turning it on removes the one-click copy of another customer’s identity — the shortcut with the compliance risk — and the address picker that replaces it changes only where the same buyer is. It does not stop staff naming another buyer. With the switch on, the buyer name, identity type and number, tax number, SST number, e-mail and contact number are still ordinary inputs on the same tab, and typing into any of them writes the buyer block. Each of those fields has its own hide switch on the same settings tab (its label is the raw key too, such as HIDE_E_INVOICE_BUYER_NAME), and hiding a field is the only setting that takes it off the screen. None of these switches is a permission, so checking that each invoice names the right buyer stays with whoever reviews the e-invoices.

Before you rely on either button:

• Both go grey once the invoice is FINAL. The tab is not blocked and it is not a permission — the document is final. To change the buyer or the address after that, work on the e-invoice record in My E-Invoice Admin: edit the Account tab on the record (or its pool row) and use Save and Resubmit. That is refused once LHDN has validated the e-invoice; from then on it is a cancellation inside 72 hours or a credit note — Cancelling and correcting a validated e-invoice.
• The button you expect is missing? Check the switch before anything else. A business that hides Select From Another Customer gains the address picker and loses the one-click copy of another customer; the buyer fields themselves stay editable.
• The picker offers billing addresses only. A shipping address, however many you hold, is not in the list. Add the branch as a billing address on the customer record and it appears.
• A blank part of the picked address keeps what was there before. If the branch’s address has no second line, the second line already on the tab stays. Read the address back after you pick.
• The other customer needs an e-invoice billing address of its own. Select From Another Customer copies only the billing address flagged for e-invoices. If that customer has none, the address arrives empty, and with no address line 1, city or state the invoice waits in a pool instead of going to LHDN.
• A picked address travels only with a buyer block that is in use. Picking an address fills the address alone. The name and numbers you see on the tab are shown from the billed customer until you edit one of them, and until then the block holds no identity field, so the callout above applies the other way round: BigLedger sends the customer record and its flagged address instead of the one you picked. So after picking, change one buyer field and leave it — clear the e-mail, tab out, type it back, tab out — and the whole block, as shown, is saved onto the invoice. You will know it worked when the e-invoice record in My E-Invoice Admin shows the branch’s address.

Malaysian state codes

LHDN wants the state as a numeric code, not free text. BigLedger resolves what your staff typed automatically: first an exact match on the official state name, then a match after stripping punctuation, then a partial match in either direction (so “Kuala Lumpur” finds “Wilayah Persekutuan Kuala Lumpur”), and finally a list of common abbreviations.

The abbreviations that resolve on their own, so you do not need to re-key them: KL, WP Kuala Lumpur, WPKL → 14 · Labuan, WP Labuan → 15 · Putrajaya, WP Putrajaya → 16 · Penang, Pinang, P. Pinang → 07 · NS, N9, N. Sembilan, Seremban → 05 · Malacca, Melacca → 04 · Trengganu, Terenganu → 11 · Johore → 01 · Selangor Darul Ehsan, Sel, S.Gor, Sgor → 10.

If none of those match, the state code goes out empty. The check that holds a document back for an incomplete address looks only at whether a state is typed, not whether it is recognised, so a misspelt state passes it and LHDN rejects the submission with the state-code error CV317. That — not the postcode — is the address error that actually fails a submission. The one case an empty state is accepted is the buyer of a consolidated e-invoice, where BigLedger sends code 17 (not applicable); for everything else there is no fallback, and LHDN rejects 17 outright, for Malaysian and foreign addresses alike.

For foreign addresses the state passes through as text (or as the country code when the state is blank), and the country defaults to Malaysia if your address data does not say otherwise.

General TINs — when you don’t have the buyer’s TIN

LHDN publishes four General TINs for cases where a real one is not available:

Rules that trip people up:

1. For individual e-invoices, always prefer the buyer’s real TIN.
2. EI00000000010 can be used on an individual e-invoice for a local buyer without a TIN — but only together with identity type NRIC and a valid 12-digit national identity number. Any other combination is rejected.
3. If the buyer’s identity type is a registration number, the General Public TIN is not acceptable — obtain the company’s real TIN, or, for a local buyer under RM 10,000, let the sale be consolidated instead.
4. If the buyer’s identity type is a passport, neither escape is open. The General Public TIN is rejected with a passport, BigLedger only ever substitutes EI00000000010 and only when the identity type is NRIC, and consolidation does not rescue the document either — depending on which consolidation run your company is on, the pooled receipt is either skipped for having no tax number or swept in and reported as General Public, and neither is the e-invoice the buyer wanted. Where the document ends up depends on its submission type: keyed Individual, or at RM 10,000 or more, it waits in the Individual Pool; left blank or marked Consolidated below that, it goes to the Batch Pool. Ask for the tax number while the customer is still with you. EI00000000020 is LHDN’s General TIN for foreign buyers, and if it is used it has to be keyed onto the document by hand; BigLedger never fills it in for you.
5. The government TIN is not a general-purpose stand-in either. Using it on an ordinary individual e-invoice gets the document returned Invalid.
6. If a buyer has a TIN but no identity value, BigLedger fills the value with 000000000000 automatically, which LHDN accepts.

Common validation errors and fixes

1. Wrong currency setup on foreign-currency invoices

Symptom: A US dollar (or other foreign-currency) invoice is rejected with a currency error.

Cause: On a foreign-currency document the document currency should be the foreign currency and the base currency must be MYR. The error appears when both are set to the foreign currency.

Fix: Correct the base currency to MYR on the source document, then reprocess the e-invoice.

The part that is not on the screen. A foreign-currency sale leaves two documents behind in BigLedger — the ringgit one and the foreign-currency one — and only one of them is reported to LHDN. Which one is a setting held per company, and the default is the foreign-currency document, so your e-invoice shows USD with the exchange rate against it rather than the ringgit equivalent. There is no control for this on any screen; if your accountant needs e-invoices filed in ringgit instead, that is a request to BigLedger support, and it is worth settling before your first foreign-currency month rather than after. Either way, check one submitted foreign-currency e-invoice early and confirm the currency on it is the one you expected — nothing warns you that you are on the other setting.

Example: GadgetSphere invoices a Singapore distributor USD 4,800. Keyed with document currency USD, base currency MYR and the exchange rate recorded, it submits cleanly. Keyed with base currency USD by mistake, LHDN rejects it with error DC511.

2. General TIN misuse

Symptom: LHDN marks the document Invalid with a TIN-related message such as “Only General TIN (010)…”, shown against the buyer TIN field in the validation error panel.

Cause and fix: one of the six rules in General TINs above was broken — most often EI00000000010 used with an identity type other than NRIC, or with an invalid national identity number. Correct the buyer’s TIN and identity combination and use Save and Resubmit.

Watch for the second half of this one: even with a correct buyer TIN, a line carrying classification 004 makes an individual e-invoice Invalid, because 004 means “consolidated”. Fix the classification on the line as well.

3. Credit or debit note references an original that is no longer valid

Symptom: A credit note, debit note, refund note or sales return is rejected even though its own data looks correct.

Cause: These documents reference the original e-invoice. If the original was first rejected as Invalid and then resubmitted successfully, it received a new LHDN reference — and your note may still be pointing at the dead one.

There are two error codes here, and they mean different things:

• DR303 — the referenced e-invoice’s status is not one that can be referenced.
• DR308 — the buyer on your note is not the same buyer as on the referenced e-invoice. Getting the reference number right is not enough; the identity has to match too.

Fix: either update the note’s reference to the currently valid e-invoice and Save and Resubmit, or clear both reference fields and submit the note without a reference. Full walkthrough in Cancelling and Correcting a Validated E-Invoice.

4. The same sale looks like it is at LHDN twice

Before you act on this, work out whether the duplicate is real or apparent. Acting on an apparent one destroys valid e-invoices.

Apparent duplicate — the same number, two different documents. Sales invoices and self-billed purchase invoices draw their document numbers from two independent sequences that both start at the same value, so the same number legitimately exists twice: once on a sale, once on a purchase. The submission listing does not show which direction a document went, so the two rows look like one document submitted twice.

Real duplicate — one sale inside two Valid e-invoices. This does happen: for example, a receipt submitted individually while a copy of it was still waiting in the Batch Pool, so the monthly consolidation reported it a second time; or a manual push to the Batch Pool performed twice. LHDN’s records then overstate your sales.

How you find it: by reconciling, not by reading Submission History. See The Month-End E-Invoice Cycle.

The test that separates a real duplicate from the ordinary case. When you do find one sale attached to two e-invoices, look at the status of both before you do anything. If one of them reads Invalid, this is not a duplicate at all — it is the ordinary shape of a rejection that was fixed and resubmitted, and LHDN counts only the valid one. Only a pair where both read Valid is a real duplicate, and only that pair needs cancelling or crediting. Cancelling on the strength of “there are two rows” is how a correct month gets broken.

How you fix it: inside 72 hours of validation, cancel the e-invoice that carries the duplicate and re-report the legitimate documents. Past 72 hours, issue a credit note for the duplicated amount and involve your accountant — usually your ledger is right and only the LHDN reporting is overstated. Both routes are in Cancelling and Correcting a Validated E-Invoice.

5. Backdated documents rejected for their issue date

Symptom: A document dated in the past is rejected because of its date and time.

Cause: LHDN requires the e-invoice issue date-time to be the actual submission time, not the original transaction date. The transaction date is preserved separately on the document, so you lose nothing.

Fix: nothing to do by hand — BigLedger writes the issue date and time itself when it builds the submission, as the clock time at that moment (in UTC), and never copies the transaction date into it. If you see this on documents from an external integration, check that the integration is not overriding the issue date-time with the historical transaction date. To consolidate backdated B2C receipts from earlier months, see Pools & Submission Routing.

The fix loop

Whatever the error, the recovery is the same four moves:

1. Find the document. In a pool (never submitted) or in Internal Submission → To IRB E-Invoice (submitted and Invalid). The LHDN error code and message are shown on the record.
2. Fix the record, then the source. On a record LHDN marked Invalid, correct the buyer on the record’s own Account tab: Save and Resubmit sends the buyer that record already holds and never reads the customer again. Then correct the customer record as well, or the same error is waiting for the next sale. For a document still in a pool, the pool row’s Account tab is read when it holds any buyer field, and the customer record otherwise. Currency and lines belong on the sales document.
3. Save and Resubmit.
4. Watch it to Valid. Not to “Submitted” — that only means LHDN is still deciding.

What success looks like

Thirty seconds, one screen. Open My E-Invoice Admin Applet → Internal Submission → To IRB E-Invoice, filter to the document you just fixed, and check that:

1. Its status reads Valid — not Submitted, not IN_QUEUE, not Invalid.
2. The customer record you corrected now shows the right identity type and a clean tax number, so the next sale to that customer submits first time.

Common mistakes

Related documentation