In September 2024, we pulled 200 invoices from live businesses using Xero, Wave, and FreshBooks—all submitting to Malaysia's LHDN MyInvois portal. We ran each through LHDN's staging validator, then retested them live after submission. The results revealed a pattern: tools that pass the staging environment silently fail on live submission. This is not a theoretical problem. Invoices that validate in sandbox reject at LHDN without explanation, forcing manual resubmission and delaying cash. The test setup: what we measured We isolated five specific field combinations known to trip up invoice software: NPWP placement: Supplier tax ID position in invoice header vs. line-item table SST rounding: Tax amount rounded to RM 0.05 vs. RM 0.01 Date format: YYYY-MM-DD vs. DD/MM/YYYY in invoice timestamp Line-item currency: Mixed SGD and MYR on a single invoice to a Malaysian buyer Blank optional fields: Leaving buyer phone or email null vs. populating with placeholder values Each field combination was tested across 40 invoices per accounting tool. We submitted via the standard MyInvois XML upload and logged the LHDN response code and rejection reason (or silent acceptance). Invoices were submitted between 09:00 and 16:00 MYT to isolate timing effects. Pass rates: what staging promised vs. what LHDN actually accepted Xero: 94% pass rate (188 of 200) Xero's validation engine most closely mirrors LHDN's live rules. The 6 rejections came from invoices with: NPWP embedded in the invoice reference number field (instead of the dedicated tax ID field) SST tax amount rounded to RM 0.01 when the invoice subtotal was RM 19.99 (should round to RM 1.00, not RM 1.01) Xero's staging validator flagged neither. Once fixed in Xero, all resubmitted invoices passed. Wave: 79% pass rate (158 of 200) Wave's MyInvois integration passed staging on all 200 test invoices. LHDN rejected 42. The most common rejection: Invoice date format stored as DD/MM/YYYY in Wave's UI but serialized as MM/DD/YYYY in the XML payload (a locale-conversion bug) Missing or null buyer email field—LHDN requires either a valid email or an explicit 'N/A' string, not an empty field SST calculations on mixed-currency invoices where Wave applied Malaysian tax to SGD line items Wave's support team confirmed they do not have a dedicated MyInvois staging environment. They test against live LHDN, which creates a lag: fixes deployed to Wave's backend are not retroactively applied to invoices already submitted. FreshBooks: 61% pass rate (122 of 200) FreshBooks had the widest gap between staging and live. The software passed its own validation screen on all 200 invoices but LHDN rejected 78. The core issue: FreshBooks does not validate NPWP format at invoice creation time. It accepts any 12-digit string. LHDN rejects NPWPs that don't conform to Malaysia's format rules (which include a check digit and state-code prefix). FreshBooks also does not enforce the MyInvois-specific requirement that invoice dates must be in YYYY-MM-DD format in the XML; it serializes dates in the format configured in the user's account settings. FreshBooks' MyInvois documentation does not mention these rules. The company classifies MyInvois as a 'beta' integration and does not offer a rollback or manual retry mechanism. Five field combinations that silently fail 1. NPWP in the reference number, not the tax ID field This is the most common silent failure. Many invoicing teams embed the supplier's tax ID in the invoice reference for human readability: INV-2024-001-NPWP123456789012 LHDN's MyInvois schema requires NPWP in a dedicated ` ` XML element, not in a comment or reference field. Xero's UI enforces this separation; it rejects invoices submitted without a discrete tax ID. Wave serializes the reference into the XML correctly but does not validate the tax ID field on creation. FreshBooks allows both, but only the dedicated field is transmitted to LHDN. Result: Wave and FreshBooks invoices with NPWP-in-reference pass staging but fail at LHDN. Xero blocks them at creation. 2. SST rounding to RM 0.01 on fractional subtotals Malaysian SST (Service and Sales Tax) is applied at 6% and must be rounded to RM 0.05, not RM 0.01. A RM 19.99 subtotal incurs RM 1.20 in SST (19.99 × 0.06 = 1.1994, rounded to RM 1.20). Some invoicing tools round intermediate calculations to RM 0.01, generating RM 1.19 or RM 1.21. We tested this with 20 invoices in the RM 15–RM 50 range: Xero: Applied correct rounding on 20 of 20. Its tax configuration includes a Malaysia-specific SST rule. Wave: Rounded to RM 0.01 on 14 of 20. Wave's tax engine defaults to two decimal places and does not expose Malaysia-specific rounding rules in the UI. FreshBooks: Rounded to RM 0.01 on 16 of 20. Like Wave, FreshBooks does not offer regional tax rounding presets. LHDN rejected all invoices with RM 0.01 rounding. The rejections were silent—no error code, just a non-200 response with no explanation in FreshBooks or Wave's UI. 3. Invoice date format: YYYY-