Malaysia einvoice JSON Check — check your malaysia e-invoice data

Six IRBM rejects sat in a Petaling Jaya ERP integrator's MyInvois e-Invoice payload, and every one of them had already passed the JSON schema check in the build pipeline.

That is the ordinary shape of a MyInvois failure. The document is well formed. The braces close, the arrays nest the way UBL 2.1 in its JSON form wants them to nest, and the submission API still hands the whole thing back. MyInvois validates values, and the values are code lists that nobody memorises.

Here is what the six were, taken line by line from the fixture that ships with the extension.

Line 11 carried "InvoiceTypeCode": "INV". IRBM accepts eight codes there and none of them are words: 01 Invoice, 02 Credit Note, 03 Debit Note, 04 Refund Note, and 11 through 14 for the self-billed versions of the same four.

Line 12 declared "DocumentCurrencyCode": "USD" with no exchange rate anywhere in the document. A non-MYR e-Invoice has to carry a TaxExchangeRate with the rate used to reach ringgit, because the tax authority settles in ringgit.

Line 17 had "IndustryClassificationCode": "0111". MSIC 2008 codes are five digits, not four, and the one that belongs there is the one on your own LHDN profile.

Line 19 put EI00000000010 in the supplier slot. That is the general public TIN. It exists so that you can issue to a buyer who has no Malaysian TIN, and it is a buyer-side value only. A supplier submits under its own.

Line 68 had "ItemClassificationCode": "0022". Classification codes are three padded digits in the 001 to 045 range, so 022 is right and 0022 is a rejection.

Line 78 had "TaxCategory": "SST". This is the one that catches everybody, including every language model asked to draft a payload, because SST is what the tax is called in every conversation in Malaysia. In the field it is 02 for Service Tax, from a list that runs 01 through 06 plus E for an exemption.

Notice what those six have in common. Not one of them is a syntax error. A JSON validator, a TypeScript type, a UBL schema check — all of them pass this document, because the shape is correct and only the contents are wrong. It is also the class of mistake a generative model makes: it writes a document that looks like every MyInvois example it has read, with the tax named the way humans name it.

MyInvois Field Check runs fifteen of these value rules over the open file: supplier TIN presence and shape, the general public TIN in the wrong slot, MSIC code and its description, supplier telephone, buyer registration identifier, e-Invoice type code, listVersionID and the 1.1 signature block, currency code, exchange rate, line classification code, line tax type code, and the original-document reference that credit, debit and refund notes must carry. Each finding names the rule, the value it found, the value IRBM expects, and the line. Files without an Invoice root are skipped.

The clock matters as much as the codes. IRBM's six-month relaxation period that follows the 1 July 2026 phase runs to 31 December 2026, and Section 120(1)(d) of the Income Tax Act 1967 prices a non-compliant e-Invoice at a fine of RM200 to RM20,000, or imprisonment up to six months, or both, per document. Confirm your own phase against the current LHDN e-Invoice Guideline; this is a field checker, not tax advice.

Checking a file in the editor is free and finishes the job: all fifteen rules, every finding, every line. The licence key buys a different job — a dated audit file covering the whole workspace, the kind you hand to a tax agent, and the same check running in CI so a payload that IRBM would reject never leaves the build.