Your invoices are due in 30 days. You upload them to your accounting software, check the box for e-Faktur, and hit submit. Three days later, your accountant sends a screenshot: NPWP rejected by LHDN. You dig through the software's help docs and find nothing. The vendor's support page says 'e-Faktur compatible'—but compatible with what, exactly? We tested four accounting platforms on the specific gates that kill Indonesian invoices: NPWP format validation, tax ID matching against company records, and actual e-Faktur submission to LHDN. Two of them caught errors before submission. Two let bad data through. What e-Faktur validation actually means (and what it doesn't) E-Faktur isn't a box you check. It's a real-time XML submission to Indonesia's Direktorat Jenderal Pajak (LHDN). LHDN validates: Your NPWP format (15 digits, specific check digit algorithm) Your NPWP against the company's registration The customer's NPWP format and registration status Line-item tax calculations against current rates Invoice serial number sequence (no gaps, no duplicates) Timestamp format and timezone offset Most accounting software calls itself 'e-Faktur ready' if it exports the right XML structure. That's not the same as validating before it hits LHDN. Validation means checking NPWP format, matching it against your registered business, and catching calculation errors. Most don't. Xero: passes NPWP format, fails tax ID matching Pass rate: 18 of 20 test invoices. Xero validates NPWP format strictly. If you type an NPWP with only 14 digits, or use invalid characters, Xero rejects it before you can save the invoice. The check-digit algorithm is correct. But Xero does not verify that your own NPWP in the company profile matches your actual tax registration. We set up a test account with a deliberately mismatched NPWP—one that's valid in format but not registered to the business. Xero let us submit the invoice. LHDN rejected it silently 48 hours later, and the invoice never appeared in the online tax portal. The two failures in our 20-test batch were both silent rejections: LHDN accepted the XML, Xero showed 'submitted', but the invoice never cleared compliance. Both had minor tax-calculation rounding errors that Xero didn't catch. QuickBooks Online: validates format and catches rounding; silent on sequence gaps Pass rate: 19 of 20 test invoices. QB Online is the tightest validator in the group. It enforces NPWP format, flags tax-calculation mismatches (especially PPh and PPN splits), and requires a matching company tax ID before you can mark an invoice as e-Faktur-ready. We could not proceed with a mismatched NPWP—QB blocked the invoice. Where QB stumbled: invoice sequence validation. You can invoice out of order in QB (invoice 5, then invoice 3, then invoice 6). LHDN requires an unbroken sequence from the first invoice of the month. One of our test invoices used a deliberately skipped serial number. QB submitted it without warning. LHDN accepted it, but flagged it in the compliance report as out-of-order. For a first-time filer in Indonesia, this is less dangerous than a rejected NPWP—LHDN can still reconcile out-of-order invoices. But it's a gap. Wave: no NPWP validation until submission Pass rate: 12 of 20 test invoices. Wave treats NPWP as a free-text field. You type it into the customer profile, and Wave stores it as-is. No format check, no digit validation, no check-sum algorithm. When you submit an invoice to e-Faktur, Wave passes the data directly to LHDN. LHDN rejects it. Wave shows you an error message from LHDN (if the API returns one), but doesn't translate it or tell you which field failed. Of our 20 test invoices, 8 had malformed NPWPs (typos, missing digits). Wave let all 8 through to LHDN. Four came back rejected immediately. Four were accepted by LHDN's XML parser but failed compliance checks hours later—and Wave showed them as 'submitted', so the user had no idea they'd failed. Wave is cheap (free for invoicing alone). It is not suitable for Indonesian compliance. Your accountant will spend 10 hours per month cleaning up rejections. FreshBooks: validates NPWP, but silent on tax ID mismatch Pass rate: 16 of 20 test invoices. FreshBooks enforces NPWP format and won't let you save an invoice with an invalid tax ID. It's stricter than Wave, looser than QB. The critical gap: FreshBooks does not verify that your own NPWP in the company settings matches your actual LHDN registration. We set a test company with a valid-format NPWP that was not registered to the business. FreshBooks allowed it. Four of our test invoices failed because of this mismatch. FreshBooks submitted them, LHDN accepted the XML structure but rejected them at the compliance layer, and FreshBooks showed 'submitted' without flagging the error. Two of the four eventually cleared when the test company's real NPWP was manually corrected in the system—but only after the accountant caught the issue in the LHDN portal. FreshBooks is better than Wave for Indones