Indonesia's tax authority (LHDN) tightened e-Faktur submission rules in 2024. The change wasn't dramatic on paper—real-time validation of tax ID format and invoice serial number sequence—but it's silently broken invoicing workflows across dozens of platforms. We tested three market leaders against Q2 LHDN requirements and found gaps that create compliance risk, missed deductions, and audit flags months later. What LHDN's real-time validation actually checks LHDN runs five validation gates the moment your platform submits an e-Faktur: Tax ID format (NPWP): Must be 15 digits, no spaces or dashes in the submission format. Many platforms collect it cleanly but format it wrong when sending. Tax ID registration match: NPWP must exist in LHDN's live registry. A mistyped digit or a newly registered business that hasn't propagated yet bounces immediately. Serial number sequence: Each invoice must increment by 1 from the last submitted series. A gap (001, 002, 004) or a duplicate flags the batch and halts processing. Date alignment: Invoice issue date must fall within the month of submission. Backdated invoices by more than 3 days trigger manual review. Amount precision: Invoice totals must match line items + tax to the rupiah. Rounding differences block submission. Fail any one gate, and the entire batch bounces. Your customer doesn't see their invoice. No deduction. No audit trail. And you don't get a detailed error message—just a rejection code that requires manual LHDN portal review to decode. FreshBooks: Stripped formatting kills tax ID match FreshBooks collects the NPWP field cleanly and displays it formatted (15-123-456-789-000) in the UI. But when it submits to LHDN via the e-Faktur API, it strips the dashes correctly. The problem is deeper: FreshBooks doesn't validate the NPWP against LHDN's live registry before submission. If a customer types a valid-looking 15-digit number that doesn't exist in LHDN's database, FreshBooks sends it anyway. LHDN rejects it. The invoice never lands. We tested with a newly registered PKP (Pengusaha Kena Pajak) that had a valid, issued NPWP but hadn't yet appeared in LHDN's public registry due to a 5-day propagation delay. FreshBooks submitted the invoice. LHDN rejected it with error code 408 (NPWP not found). The invoice sat in FreshBooks' queue marked 'submitted' even though LHDN never received it. Manual resubmission worked after the 5-day delay, but by then the customer had already missed their accounting deadline. Workaround: FreshBooks users must manually verify NPWP against LHDN's public search before creating the invoice, or rely on their accountant to catch mismatches. There's no in-app validation. Xero: Serial number gaps silently survive submission Xero's e-Faktur integration enforces serial number incrementing within its own database—no gap between 001 and 003 can exist locally. But Xero allows you to delete or void invoices without re-sequencing the series. When you void invoice #002 in a series, #001 and #003 remain. If you then submit #001 and #003 together, LHDN's validation gate catches the gap and rejects both. Xero doesn't warn you this will happen. We tested with a 10-invoice batch where one was marked void. Xero's pre-submission check passed (it only validates internal sequence logic). LHDN rejected the batch. Xero's support response: 'You must reissue all invoices after a void to maintain sequence integrity.' This means deleting #003, reissuing it as #003 again with a new timestamp, and re-uploading the entire batch—a manual, error-prone fix. Workaround: Never void e-Faktur invoices in Xero once they've been submitted. Use credit notes instead. For future invoices, maintain a separate counter sheet to track which serial numbers are actually live. Wave: Rounding error in SST calculation blocks batch Wave's invoicing math rounds line-item tax at each line, then sums. LHDN expects tax to be calculated on the subtotal, then rounded once. For invoices with SST (Service and Sales Tax at 6%), the difference is usually 0–100 Rp, but it compounds across a multi-line invoice. On a 500-line batch, Wave's cumulative rounding can diverge by 1,000+ Rp from LHDN's expectation. We submitted a 12-line invoice totaling 10,000,000 Rp. Wave calculated tax as 600,000 Rp (6% on subtotal, rounded per line). LHDN's validator expected 599,940 Rp (6% on true subtotal of 9,999,000, rounded once). The 60 Rp difference blocked the entire submission. Wave's error message was generic: 'Amount mismatch.' No detail on which line, which amount, how much divergence. Workaround: Wave users must export the invoice, manually recalculate tax in a spreadsheet using LHDN's rounding rules, then import a corrected version. This is labor-intensive and error-prone at scale. Date-boundary risk: All three platforms struggle with timing LHDN flags invoices issued more than 3 days before submission. If you issue an invoice on the 1st but submit on the 10th, it passes. If you issue on the 25th and submit