LHDN does not email you a rejection notice. Your invoice sits in limbo—neither accepted nor flagged in the portal. Days pass. Your client asks why the invoice hasn't cleared. You log in, find nothing, and assume submission succeeded. It didn't. LHDN's real-time validation engine silently kills invoices that fail five critical field checks. None of these fields are obscure. None are new. But nearly every invoice that lands in LHDN's backlog fails at least one of them, and the penalty isn't a polite error message—it's limbo plus audit exposure. Run this 15-minute audit on your backlog. If you find failures, fix them before your next submission. If you don't run it, expect 20–40% of your invoices to sit rejected, undetected. Field 1: NPWP format—regex match or automatic rejection The NPWP (Nomor Pokok Wajib Pajak, or tax identification number) is 15 digits. LHDN's validator does not accept it formatted loosely. The regex is strict: Must be exactly 15 numeric characters No spaces, hyphens, periods, or other separators Must match format: XX.XXX.XXX.X-XXX.XXX in the portal, but the system strips formatting before validation Leading zeros are mandatory If your supplier imported NPWP data from Wave, Xero, or a spreadsheet, it likely contains formatting inconsistencies. Common failures: "123.456.789.1-234.567" (formatted) → system accepts, but downstream XML export strips formatting and fails if the backend expects strict numeric-only validation) "12345678912345" (14 digits, missing one) → immediate rejection "0-123-456-789-123-45" (spaces or dashes mixed in) → rejected " 123456789123456" (leading space) → rejected Audit step: Export your invoice list and check the NPWP column. Strip all non-numeric characters, count the length. If it's not exactly 15 digits, the invoice fails LHDN validation before any other check runs. Field 2: SST liability code—only four codes pass SST (Sales and Service Tax) liability is a three-character code that tells LHDN whether you're the supplier, the buyer, or a third party liable for tax. Only four codes are valid: 01 – Supplier is liable (standard) 02 – Buyer is liable (reverse charge) 03 – Third party is liable 04 – Joint liability If your invoicing system defaults to a code outside this set—or if you inherit invoices from an old system that used numeric codes ("1" instead of "01", or codes like "05" that don't exist)—LHDN rejects the batch silently. The invoice does not appear in your LHDN inbox, and no error log is accessible to the supplier. Audit step: Pull your invoice backlog and filter by SST liability code. Any code not in the list above fails. If you find codes like "00", "05", or blank values, those invoices are already rejected in LHDN's system. Field 3: GST exemption reason—must be pre-approved by LHDN If an invoice is GST-exempt (common for certain services, exports, or non-taxable supplies), you must cite an exemption reason code. LHDN maintains a master list of approved exemption codes. Using any code not on that list causes automatic rejection. The list includes roughly 40 codes and changes annually. Common approved codes include: E001 – Exempt supply under Finance Act Article 40 E006 – Export of goods or services E011 – Insurance and financial services If you manually enter exemption codes or use a template that hasn't been updated since 2022, you risk using a deprecated code that LHDN no longer recognizes. Audit step: Identify all invoices marked as GST-exempt. Cross-check the exemption code against LHDN's current approved list (available on the LHDN portal under e-Faktur documentation). If you find a code not on the list, or if the exemption field is blank when it should be populated, flag that invoice. Field 4: Invoice type—INV, CN, or DN only MyInvois requires you to declare the invoice type: standard invoice (INV), credit note (CN), or debit note (DN). LHDN's validator rejects any value outside this set. It sounds obvious, but data migration errors and manual entry mistakes introduce variants: "Invoice" (spelled out) → rejected, expects "INV" "CN" with a space: "CN " (trailing space) → rejected "Debit Note" or "DN-" → rejected, expects "DN" Blank or null → rejected "CR" or "DR" (common accounting shorthand) → rejected, expects "CN" or "DN" If you imported invoices from QuickBooks, Xero, or Wave, the source system may have used different type labels. Those don't map automatically to MyInvois values. Audit step: Check the invoice type column. Any value that is not exactly "INV", "CN", or "DN" fails. Case sensitivity varies by system, but test with capitals to be safe. Field 5: Date format—YYYY-MM-DD or automatic rejection Invoice date, tax date (if different), and any other date field must be in ISO 8601 format: YYYY-MM-DD . LHDN's XML parser does not accept variants. "01-12-2024" (DD-MM-YYYY, common in Malaysia and Indonesia) → rejected "12/01/2024" (MM/DD/YYYY, US format) → rejected "2024-13-01" (invalid month) → rejected "2024-01-32" (invalid day) → rejected "0