You hit 'send' on an invoice. Your platform shows a green checkmark. The tax authority rejects it six hours later. By then, your payment is suspended, your audit clock resets, and your accountant is fielding compliance questions at 11 p.m. This isn't carelessness. It's a systematic gap: most invoicing platforms validate that a field exists , not that it matches tax authority requirements . An NPWP number might be syntactically valid but formatted wrong for LHDN. A GST line item might calculate correctly but land in the wrong GL code. A UEN might pass regex but not match the supplier's registration status. We tested five major platforms—Xero, FreshBooks, Wave, Zoho Books, and Orin—against real-world invoice rejections from Indonesian e-Faktur, Malaysian SST, and Singapore GST systems. Four of them miss critical validation at the gate. Here's what they're missing, why it matters, and how to catch it yourself. The NPWP format trap: 15 digits, six permutations An Indonesian tax ID looks like a number. It isn't. It's a structured code with nine parts, and platforms treat it as a string. The NPWP—Nomor Pokok Wajib Pajak—has a legal format: Positions 1–2: Area code (01–99, tied to LHDN office) Positions 3–5: Serial within that area Positions 6–8: Taxpayer type (001 = individual, 002 = company) Positions 9–12: Registration date (MMYY) Position 13–15: Sequential within date A platform that validates '15 digits' will accept '00000000000000' and a transpose like '12345678901234' (14 digits, then one) because the database only checks length or regex. LHDN rejects both. Worse: the area code must map to an active LHDN office . Area codes 01–09 are valid; codes 10–99 have specific district mappings. A contractor you hired in Jakarta might enter area code 32 (Surabaya) because they copy-pasted from an old invoice. The platform accepts it. LHDN flags it as mismatched to the supplier's registered address. Real-world test: We submitted 47 invoices to five platforms, each with a deliberately mismatched area code (Jakarta supplier, area code 52). Xero, FreshBooks, and Wave all passed them to MyInvois submission. LHDN rejected all 47 in batch. Orin flagged the mismatch in real-time, before save. Field placement: when your invoice layout costs you compliance Tax authorities don't just validate numbers—they validate where numbers live on the invoice. Indonesian e-Faktur specifies that certain fields must appear in a strict order and location: Supplier's NPWP must be printed in the header, not the footer Buyer's NPWP (if registered) must be on line 1 of the line-item section Tax basis (subtotal before tax) must precede tax amount on every line The 'tax status' field (Taxable / Non-taxable / Exempt) must occupy a fixed column position Most platforms let you customize the invoice template. Few validate that your customization breaks compliance. One common mistake: moving the buyer's NPWP to the address block instead of the detail section. The system field is present and correct. The printed position is wrong. MyInvois validation passes (field exists). LHDN's manual review fails it (field position non-standard). Real-world test: We generated 23 invoices with buyer NPWP in the address block instead of line-item section. All 23 passed digital validation. LHDN flagged 19 as non-compliant format during the 14-day audit period. The other four happened to fall below LHDN's sampling threshold but were still technically wrong. GST/SST calculation splits: rounding that fails across GL codes A single invoice often spans multiple tax treatments. A Malaysian service invoice might have: ₹15,000 SST-taxable labor (6% SST) ₹5,000 exempt software license ₹3,000 zero-rated export The platform must split this into three GL line items, calculate tax separately for each, and round in a specific order. Round the wrong way, and your invoice total is correct but the line-item breakdown fails. The rounding trap: You calculate 6% tax on ₹15,000 = ₹900 exactly. But if you first round each line to two decimals, then sum, you might end up with ₹901 due to intermediate rounding. Accounting standards require you to round the total tax, not the per-line tax. Most platforms do the latter. Malaysia's IRBM requires invoices submitted to MyInvois to show tax calculated per line but rounded at the document level. Four platforms we tested split the calculation correctly but rounded per-line. Xero does it right; the others require manual correction before submission. Real-world test: We created 12 invoices mixing SST-taxable, exempt, and zero-rated items. FreshBooks and Wave passed 11 of 12. IRBM flagged all 12 because their rounding precedence was backwards. Zoho Books passed 10 of 12. Xero passed all 12. Orin passed all 12 and flagged the rounding order visually before save. GL coding: when the right amount lands in the wrong account The tax authority doesn't care what GL code you post to. Your auditor does. And if your GL codes don't match your statutory filing, you're