You hit 'send invoice' in your software. Green checkmark. Two days later, LHDN rejects it. Your accountant digs in and finds the tax ID format was wrong—but your platform never flagged it. This happens because most invoicing platforms validate syntax, not substance. They check that a field exists. LHDN checks that it's correct . We audited five critical validation gaps that live between your software's pass and LHDN's actual rules. These aren't edge cases. They're in your invoice queue right now. 1. Tax ID format validation: The silent format trap Your seller's tax ID must match a specific format. For Malaysia BRN, it's 12 digits. For Indonesia NPWP, it's 15 digits with embedded checksums. For Singapore UEN, it's 9 characters with a strict pattern. Most platforms store the raw number and check length. LHDN checks the structure . The failure: You enter 123456789012 (12 digits, length valid, format invalid). Platform passes. LHDN rejects. Leading zeros stripped during import. 015123456789012 becomes 15123456789012 . Platform accepts. LHDN sees a malformed NPWP. Dashes, spaces, or formatting characters lurk in fields. Platform trims them and passes. LHDN expects them in a specific position and rejects the raw value. Test your platform: Export one invoice with a known-valid tax ID. Check the XML. If it strips formatting but doesn't validate the structure against country-specific rules, you're at risk. 2. GST/SST line-item split: The buried decimal LHDN doesn't care about your total tax. It cares about the tax per line item , calculated at the rate in effect for that item's jurisdiction and tax type. If an invoice has both SST (6%) and zero-rated items, each line must declare its own tax amount. If you're selling to a regional customer (Malaysia + Singapore in one invoice), the tax must split by country. The silent fail: Your platform sums all line taxes and posts one lump amount. LHDN expects individual line-level tax detail. Rejected. You have a 0.5% rounding difference on one line. Platform rounds to nearest cent and posts. LHDN's validator catches the decimal mismatch and rejects the entire invoice. SST on a discounted line item is calculated wrong. Discount applied before SST (correct) or after (wrong). Platform accepts both. LHDN validates the calculation and rejects the second. This is common in multi-line invoices. Check your last 10 invoices: does your platform show tax per line in the XML export, or only the total? 3. Seller UEN format and registration validation The seller (you) must have a valid UEN registered with LHDN. But your software doesn't check if you're actually registered . It just checks if the format looks right. If your UEN is valid as a format but you're not registered in LHDN's records, the invoice fails validation downstream—sometimes days after you sent it. The trap: You entered your UEN years ago. Your business status changed, but your software still uses the old UEN. LHDN rejects invoices from an unregistered entity. You recently renewed your registration. The new UEN wasn't updated in your software's settings. Invoices go out under the old UEN. Rejected. Multiple entities in one account (common for group companies). Software defaults to the first UEN for all invoices, even if the invoice belongs to Entity B. Rejected. Real-time validation would cross-check your UEN against LHDN's live registry. Most platforms don't. They validate syntax only. 4. Buyer NPWP matching and consistency rules If your buyer has an NPWP (tax ID), it must be valid for their stated entity type and consistent across all their invoices in your system. LHDN cross-references buyer NPWP against its database. If the NPWP format is valid but the buyer doesn't exist in LHDN's records, or if you've issued invoices to the same buyer under two different NPWPs, validation fails. Where it breaks: Your buyer's name is PT Acme Jaya with NPWP 123456789012345 . Next month, they rebrand to Acme Group Jaya but the NPWP is the same. Your software doesn't flag the name mismatch. LHDN sees it and questions the invoice's authenticity. A buyer provides a forged or inactive NPWP. Your platform checks the format. LHDN checks the registry and rejects. The same buyer appears in your invoices under three slightly different legal names (spacing, abbreviations, punctuation). LHDN's validation sees inconsistency and flags for audit. This is where real-time NPWP validation stops fraud and rework. Batch checks (end-of-day or weekly) let bad NPWPs through. 5. GL code nesting and ledger hierarchy validation Each line item must map to a valid GL code. But LHDN doesn't just check if the code exists; it validates that the code is at the correct nesting level for that transaction type. A revenue code cannot sit under an expense parent. A 4-digit code cannot be assigned if a 2-digit parent doesn't exist in your chart. The silent rejection: You have GL code 4100 (revenue). Its parent 4000 doesn't exist in your chart. Your invoicing platform doesn't