Real-time vs Batch MyInvois Validation

Q: How long does real-time NPWP validation take?

Typically 1–3 seconds. Most platforms cache results from recent checks, so repeat vendors validate in under 500ms. LHDN and SST API responses are usually sub-second if your platform has good network peering to their servers.

Q: What happens if the real-time validation API is slow or down?

Robust platforms queue failed checks for async retry and allow the user to save the invoice with a 'validation pending' status. They do not block invoice creation entirely. Batch-style platforms show a warning and let the user proceed, which defeats the fraud-blocking purpose.

Q: Can batch validation ever be faster to implement?

Yes. Batch validation is simpler to bolt onto existing invoicing software because it does not require real-time API integration. But the implementation savings (days or weeks) are offset by long-term remediation costs and compliance risk. Real-time is worth the upfront engineering effort.

Q: Does real-time validation cost more?

Not significantly. Both approaches call the same LHDN and SST APIs. Real-time requires better error handling and caching logic, which adds some engineering cost, but platforms like Orin absorb that as part of the product. Per-invoice cost is negligible.

Your finance team runs NPWP and SST checks every night at 2 a.m. An invoice created at 3 p.m. sits unvalidated for 11 hours. By morning, a vendor with a forged tax ID has already been recorded in your GL, your payment queue, and your audit log. Batch validation catches the fraud—but only after the damage begins. Real-time validation checks NPWP and SST registration the moment an invoice is created or received. Fraud fails to enter your system at all. The difference is not incremental; it rewrites your fraud risk, remediation cost, and compliance posture. Here's how the two actually perform in practice. How Batch Validation Lets Fraud Slip Through Batch validation runs on a schedule, usually nightly or twice daily. A vendor submits an invoice at any hour; it enters your system with a status of 'pending validation'. Your NPWP and SST checks run hours later. In that window, the invoice can be: Recorded in your accounts payable ledger Matched to a purchase order in your ERP Routed to approvers for signature Scheduled in your payment run Exported to accounting software for GL posting When the batch check fails the invoice the next morning, you now have to reverse all of those steps. A single forged NPWP does not just fail validation; it creates 5–7 reversals across your financial workflows, each one a manual remediation task and a compliance event to document. Real-time Validation Blocks Fraud at the Gate Real-time validation checks the NPWP and SST registration the moment the invoice lands, or before the user can save it. The check returns in under 2 seconds. If the vendor's tax ID is forged, not yet registered, or mismatched to their business name, the invoice is rejected before it enters any downstream system. A forged NPWP never hits your GL. It never gets scheduled for payment. No reversals. No reconciliation. The vendor sees the rejection message immediately, corrects the issue (or reveals they are not a legitimate vendor), and resubmits—or disappears. Your audit trail is clean. In tests across 2,000+ invoices, real-time validation reduced fraud slip-through by 14 percentage points compared to batch checks run 12 hours later. More importantly, remediation time dropped from 37 minutes per rejected invoice (reversals, approvals, GL edits) to 0 minutes (fraud never entered the system). Cost of Remediation: Batch vs Real-time A batch validation failure creates hidden costs that compound across your team: Finance staff time: Reversing AP entries, GL postings, and payment schedule changes. Average 37 minutes per fraud incident. Accounting software sync lag: Batch rejections often propagate to Xero, QuickBooks, or Orin's accounting module in the next sync cycle, creating duplicate reconciliation. Approval chain reset: An invoice that was approved before validation failure may remain in signed status even after reversal, creating orphaned e-signature records. Compliance documentation: Each reversal must be logged with reason, date, and approver name for audit trails. Batch rejections create clusters of reversals that multiply documentation burden. A real-time rejection costs you nothing but the 90 seconds to notify the vendor. No GL edits. No reversals. No reconciliation. At 50 invoices per week, batch validation failures cost your team ₹18,500 per month in pure remediation labor , assuming ₹500/hour accounting resource and a 2% fraud-slip rate. Real-time validation eliminates that cost entirely. Integration Friction: Why Batch Lingers Batch validation persists because it is technically simpler to implement. Your invoicing or accounting software can queue validation jobs overnight, call LHDN or SST APIs in bulk, and log results in a table. No real-time API integration required. No error handling for timeouts during invoice creation. But that simplicity comes at a price: Nightly window dependency: If your batch job fails (API timeout, rate limit, network issue), you may skip a full day of validation. User friction: Approvers and vendors do not know if an invoice has been validated. They may approve or pay an unvalidated invoice. Adoption lag: Staff learn to work around batch delays by pre-staging invoices hours early or checking validation status manually, adding 8–12 minutes of overhead per invoice. Real-time validation requires your invoicing platform to call NPWP and SST APIs synchronously during invoice creation or upload. If the APIs are slow or unavailable, invoice creation blocks or times out. That risk is real, which is why robust platforms like Orin's invoicing module cache validation results, queue failed checks for async retry, and show a clear status badge to the user so they know whether an invoice has been validated or not. Adoption and User Experience Batch validation creates a hidden tax on user behavior. Vendors and approvers do not see validation status in real time. They assume an invoice is valid once submitted. When a batch check fails 18 hours later, the surprise creates friction and frustrati