Your finance team processes 200 invoices this week. Thursday morning, LHDN rejects eight of them. The NPWPs are fake. You cross-check your batch validation log from Monday: nothing flagged. By Friday, you've lost two days of working time, stalled contractor payments, and burned goodwill on a reconciliation that should never have happened. This is not a process failure—it's a timing problem. Batch tax ID validation, run once or twice a week, catches perhaps 86% of bad identifiers. The remaining 14% slip through because they're checked after the invoice is already in your system, already assigned to a GL account, and already waiting for approval. Real-time validation—at the moment of checkout, invoice creation, or form submission—stops that leak before it starts. Why batch validation misses 14% of invalid tax IDs A batch job is synchronous: you run it on Tuesday, it checks 500 NPWPs against the LHDN database, and by Wednesday morning you have results. But the problem is when that batch runs, not how thoroughly it works. Time zone drift. If your batch runs at 2 AM Singapore time but your contractor submits an invoice at 11 PM Jakarta time the night before, the invoice sits unbatched for up to 14 hours. A bad NPWP entered during that window will not be caught until the next cycle. Revalidation lag. If an NPWP is flagged on Wednesday but the contractor corrects it (legitimately) on Wednesday afternoon, your batch system doesn't know. By Thursday, it's run again, but you've now spent a day in limbo. With real-time validation, the correction flows straight to the invoice in flight. No visibility until rejection. Your accounting team sees a batch report listing 8 failures. But those failures happened after the invoice entered AP, after line items were coded, and after routing rules fired. Reversing them is manual work. Real-time validation stops the invoice from entering that state in the first place. Silent failures in legacy systems. Many batch validators return a true/false: NPWP valid or not. But they don't always explain why it failed. Is the NPWP deactivated? Was it entered with a typo? Is it not an NPWP at all (perhaps a KTP)? Without that granularity, your contractor has to guess on the retry. One fintech processing Indonesian contractor invoices tested this hypothesis. Over six weeks, they ran two validation tracks in parallel: their existing batch system (every 24 hours) and a real-time validator at invoice submission. Of 500 invoices, the batch system flagged 42 bad NPWPs. The real-time system caught 50—including 8 that were outright fabricated (fake ID prefixes that would never pass LHDN's checksum). All 8 fake entries had already been assigned to contracts and tagged for payment before the batch cycle caught them. Where real-time validation wins: three stages Real-time tax ID validation is not one thing; it's three things working in sequence. Each catches different failure modes. Stage 1: At checkout or contractor onboarding The earliest point is when a contractor registers with you. If you're using a contractor management workflow , the NPWP (or UEN, or ABN) should be validated the moment it's entered. This catches typos, wrong ID types, and already-expired identifiers before a single invoice is ever created. The contractor sees immediate feedback: "NPWP is invalid" or "NPWP registered to a different legal entity." They correct it on the spot, not three days later when an invoice bounces. Your system locks the contractor record until the tax ID passes, preventing downstream invoices that reference a ghost identity. Stage 2: At invoice creation Even if the contractor's profile was validated on day one, tax IDs can expire, be suspended, or (in rare cases) be revoked mid-contract. A second validation at invoice creation—when the contractor or your team fills in the invoice form—catches these mid-lifecycle changes. This is where unified invoicing platforms with built-in validators shine. The moment a tax ID field is populated, it's checked against the live registry. If the ID is no longer active, the invoice form blocks submission with a specific reason. Your accountant sees it immediately and can escalate to the contractor without waiting for a batch report. Stage 3: Batch reconciliation (as a backstop) Batch validation is not obsolete—it's a safety net. After real-time validation has passed invoices, a nightly or weekly batch job re-validates every tax ID against the current registry. This catches rare scenarios where an ID was valid at submission but was suspended overnight, or where the registry itself had a transient outage and your real-time call got a false positive. In that fintech's testing, the batch backstop caught exactly zero additional failures after real-time validation. This is expected. But it's cheap insurance: a 15-minute batch job once a day costs almost nothing and eliminates the last 0.1% of risk. The fraud detection angle: why real-time stops bad actors Invalid tax IDs are not alway