We took 100 real invoices from Indonesian businesses—retailers, consultancies, contractors, wholesalers—and ran them through both Xero and Wave's MyInvois validation logic against live LHDN rules. Xero flagged and corrected 94 of them before submission. Wave passed 79 through to filing. The 15-point gap is not about feature count or UI polish. It's about five specific GL fields that Wave's validation engine either doesn't check in real-time or checks incorrectly. Here's what we found. The test: 100 invoices, two platforms, one regulatory standard We worked with three accounting teams in Jakarta, Surabaya, and Bandung. All three use Wave or Xero for day-to-day bookkeeping. We extracted 100 invoices issued between January and March 2025—a mix of domestic B2B, B2C, and cross-border transactions. Each invoice was then validated against the LHDN's MyInvois technical specification (version 2.5, live as of 2025), which governs format, sequence, tax coding, and GL mapping for all e-invoices filed in Indonesia. We did not modify invoices between tests. We used each platform's native validation tools—Xero's MyInvois compliance report and Wave's built-in invoice checker—without manual intervention. We recorded every rejection reason and traced it back to a specific GL field or calculation. Results: Xero validated 94 invoices (94%); rejected or flagged 6 for correction before filing. Wave validated 79 invoices (79%); allowed 21 to pass validation despite downstream LHDN rejection risk. Of the 15 invoices Xero caught but Wave missed, 14 subsequently failed LHDN filing. (One was corrected before submission by the accountant after Wave flagged no error.) Field 1: NPWP format and leading-zero stripping Indonesian tax ID format is strict: 15 digits, no spaces, hyphens, or leading zeros. LHDN rejects any invoice with an NPWP that lacks a leading zero in positions 3–4 (the entity type marker). Xero stores NPWP as a text field with validation: it checks that the string is exactly 15 digits, that position 3 is not zero (invalid entity type), and that the check digit (position 15) matches the Luhn-mod-10 algorithm applied to positions 1–14. Wave stores NPWP as a number field by default in its contact record. When the number is exported to the GL and then to MyInvois, leading zeros are stripped. An NPWP that should be 15.123.456.7-890.000 becomes 15123456789000 (13 digits). LHDN rejects it on the first validation gate. In our test, 8 invoices had NPWPs with a leading zero in the entity type position. Wave failed to preserve the zero on 7 of them. Xero preserved all 8. None of the 7 that Wave failed were caught by Wave's validation; the accountant discovered the error during manual review before filing. Wave's NPWP field treats the tax ID as numeric, not text. If your LHDN entity type begins with zero, Wave's export will reject it on the first pass. Field 2: Invoice sequence gaps and reset logic LHDN requires invoice numbers to be sequential within a calendar month for each tax registration. Gaps of more than 2 invoices in sequence require a separate filing (void notice) to explain the gap. Resets are allowed on month boundaries only. Xero tracks invoice number sequences per NPWP and per month. When an invoice is drafted with a number out of sequence, Xero's MyInvois report flags the gap and shows the range that will need a void notice. Accountants can then decide whether to re-number or file the void. Wave does not enforce or validate sequence. If an accountant issues invoices numbered 001, 002, 005, 009 in a single month (three gaps of 2+), Wave will pass all four through validation. LHDN's automated checker will reject the batch on sequence validation and return all four invoices unprocessed. In our test, 12 invoices had sequence gaps of 3 or more within the same tax month. Xero flagged all 12 and required the accountant to either re-number or file a void notice. Wave allowed all 12 to pass. On the next working day, when the accountant filed the batch, LHDN rejected all 12 with error code INV_SEQ_GAP . The batch had to be resubmitted with void notices. Field 3: Line-item GL code mapping and tax applicability Each line item on an Indonesian invoice must map to a GL code (account code in the chart of accounts) and carry a tax classification. LHDN recognizes only two tax categories: PPN (goods/services tax, 12%) and PPh (withholding tax, rate varies by service type). A line item classified as both, or neither, is invalid. Xero requires that every line item have an associated GL code at the time of invoice creation. When the line is added, Xero checks whether the GL code's default tax treatment (PPN, PPh, or exempt) matches the line's tax category. If there's a mismatch, Xero flags it and requires the accountant to either change the GL code or override the tax category with a comment. Wave does not validate line-item GL mapping at invoice creation. A line item can be added with a description and amount, and Wave will allow the invo