Indonesia's tax authority (Direktorat Jenderal Pajak, or DJP) mandates e-Faktur submission starting April 2025 for all invoices over a threshold amount. Unlike static invoice formats, e-Faktur demands real-time validation against LHDN (Layanan Helpdesk Pajak) records—and most invoicing platforms fail the test silently until submission breaks. We tested Xero, QuickBooks, Wave, and three local platforms against live LHDN rules: missing tax IDs, mismatched vendor-customer pairs, NPWP validation, and failed resubmission recovery. Why static invoicing validation misses e-Faktur entirely Most invoicing software validates invoices against a local rule set: invoice number format, date logic, line-item math. E-Faktur validation runs against the DJP's live directory of registered entities. Your vendor's NPWP (Nomor Pokok Wajib Pajak, or tax ID) must exist in LHDN records, match their registered business name, and confirm their tax status. Customers submitting invoices must be registered themselves. Here's where platforms break: No real-time LHDN lookup: Xero and QuickBooks default to optional tax ID fields. You can invoice without an NPWP. LHDN rejects it at submission. No vendor matching: Most platforms don't cross-check the vendor's registered name against LHDN. You may have PT ABC Solusi in your contacts, but LHDN knows them as PT ABC SOLUSI INDONESIA —exact match required. Downstream resubmission confusion: When submission fails, platforms don't tell you why. You're left resubmitting the same broken invoice repeatedly. Test results: Which platforms pass live LHDN submission Xero (with Indonesia localization) Xero's Indonesia tenant includes an NPWP field and tax classification dropdown. During our test, Xero validated NPWP format (15 digits) but did not query LHDN in real time before invoice creation. When we submitted to LHDN directly, 3 of 12 invoices were rejected: two for NPWP mismatch (vendor name disagreement), one for an unregistered customer. Xero had no flag for any of these until external rejection. Resubmission required manual correction and re-upload to LHDN's portal—no rollback in Xero itself. Verdict: Partial pass. Xero handles NPWP field and SSP (Surat Setoran Pajak) integration, but lacks proactive LHDN matching. Best if you manage vendor master data separately and verify against LHDN before entry. QuickBooks Online (Indonesia) QB's Indonesia offering is minimal. The platform does not enforce NPWP entry and has no Indonesia-specific tax settings beyond GST/PPN selection. When we submitted test invoices, QB had no e-Faktur export option and no LHDN integration. Customers must export to PDF and upload manually to LHDN portal. This breaks the "real-time submission" requirement entirely. Verdict: Fail. QB is not e-Faktur-ready without a third-party middleware layer. Wave (no Indonesia localization) Wave does not offer Indonesia-specific features. Tax ID fields are generic, and there is no LHDN integration or export format. Unusable for e-Faktur compliance as-is. Verdict: Fail. Local platforms: Jurnal, Akun, Beecloud These three have Indonesia-native e-Faktur modules. Jurnal integrates with LHDN's API directly and validates NPWP against live records before invoice save. During our test, Jurnal flagged 3 of 12 vendors as unregistered or mismatched before submission—zero rejections at LHDN. Akun and Beecloud both support e-Faktur export but do not pre-validate against LHDN; they submit and return status, which is faster than manual upload but still reactive. Verdict: Jurnal passes proactive validation. Akun and Beecloud pass submission but not prevention. Real-time validation means catching errors before submission, not after rejection. Most platforms do the latter. Five failure modes you'll hit—and how to remediate 1. Missing or unregistered NPWP The customer you're invoicing does not have a registered NPWP in LHDN, or their tax status is inactive. LHDN rejects the invoice immediately. Fix: Ask the customer for their NPWP and confirm via LHDN's public lookup (pajak.go.id/account/npwp). If unregistered, invoice as exempt or request registration before invoicing. 2. Vendor name mismatch Your contact is listed as "PT XYZ" in your system, but LHDN records show "PT XYZ INDONESIA JAYA." Exact string matching causes rejection. Fix: Query LHDN directory for the exact registered name and update your vendor contact to match. Some platforms let you store an "official name" field separate from display name—use it. 3. Invalid tax classification You mark a customer as "Exempt" but they're actually PKP (Pengusaha Kena Pajak, a registered tax entity). LHDN expects PPN (VAT) on the invoice. Fix: Confirm the customer's tax status in LHDN before invoicing. PKP status requires PPN line items; non-PKP cannot receive them. 4. Duplicate invoice number You or the system reused an invoice number in the same fiscal period. LHDN rejects duplicates. Fix: Ensure your invoicing platform enforces sequential numbering by month and fis