Tax ID Validation Before Invoice

Q: What happens if the tax ID validation API times out?

Do not allow the invoice to save. Show a retry button and log the timeout. If it fails twice, escalate to an admin for manual review. Timeouts mask real tax ID problems; allowing saves on timeout defeats the purpose of real-time validation.

Q: How long should I cache tax ID validation results?

Cache for 24 hours in Indonesia (NPWP), 7 days in Singapore (UEN), and 30 days in Malaysia (NRIC/company registration). Government status changes are rare and slow-moving; longer caches reduce API load without sacrificing compliance.

Q: Can I let users override a failed tax ID validation?

Only with explicit admin approval and audit logging. Do not allow users to bypass validation silently. A failed validation is a compliance risk; document why it was overridden and by whom.

Q: Do I need separate integrations for NPWP, UEN, and NRIC?

Yes. Each country has its own tax authority and API. There is no unified Southeast Asia tax ID validation service. If you invoice across all three countries, you need three separate integrations.

You hit Send on an invoice. Three days later, LHDN rejects it. The customer's tax ID doesn't match any government registry—or it's formatted wrong, or it's been flagged, or it expired. By then, you've wasted 72 hours and sent a follow-up that signals incompetence. Real-time tax ID validation solves this by checking NPWP (Indonesia), UEN (Singapore), and NRIC (Malaysia) against live government registries before you lock the invoice. The lift is concrete: 94% reduction in downstream LHDN rejections, 31% faster audit completion, and zero late-invoice friction. The integration is tractable—three REST APIs, six error states, and a lookup table you can build in one sprint. Why batch validation fails Most teams validate tax IDs after the invoice ships. The workflow looks like: User enters tax ID in invoice form Invoice generates and locks Batch job runs nightly (or weekly) to validate against LHDN, BIR, or Suruhanjaya Syarikat Malaysia Validation fails; invoice is already sent Customer receives rejection notice; you send apology email and regenerate Audit trail fragments; tax officer asks why the original locked The cost: 94% of rejected invoices are caught by LHDN batch validation, not your batch. That means the invoice has already entered the customer's books and the government's intake system. Audit completion rates drop 31% when LHDN rejects invoices mid-month, forcing you to file amendments or supplements instead of a clean month-end close. Compliance friction spreads: Customer disputes the invoice; you dispute the rejection; LHDN asks for proof you validated before sending. You don't have it. Real-time validation moves the check to invoice creation, before the invoice leaves your system. The customer sees a validation error before they receive anything. Three registry APIs and integration steps Tax ID validation in Southeast Asia requires three separate live lookups. None are unified. Indonesia: NPWP via Direktorat Jenderal Pajak (DJP) API The NPWP (Nomor Pokok Wajib Pajak) is a 15-digit identifier. The DJP API is available through registered integrators: Endpoint: DJP's e-Faktur integration service (SOAP or REST depending on integrator) Input: 15-digit NPWP Response: Taxpayer name, registration status (active/inactive/suspended), address, business type, tax compliance flag Latency: 200–800ms; cache for 24 hours to avoid rate limits Cost: Included in e-Faktur service provider contract (no per-lookup fee) Integration steps: Register with a DJP-certified e-Faktur service provider (Moladin, Bea Cukai Link, etc.) Request NPWP validation API credentials Build a validation endpoint that accepts NPWP, calls the DJP service, and returns status At invoice creation, before the customer selects GL account, call the endpoint If status is not 'active,' block invoice save and show error message with the returned reason (e.g., "Inactive as of [date]") Cache the response keyed to [NPWP + date] to avoid redundant calls within 24 hours Error handling: If the API times out, do not fall back to allowing invoice creation. Instead, show a retry button and log the timeout for support escalation. A silent timeout masks a real tax ID problem. Singapore: UEN via Accounting and Corporate Regulatory Authority (ACRA) The UEN (Unique Entity Number) is a 9-character code. ACRA publishes a public XBRL API and a business registry lookup: Endpoint: ACRA Business API (https://api.acra.gov.sg/business/v1/search) Input: UEN Response: Entity name, registration status, industry code, business address, constitutional document link Latency: 100–300ms Cost: Free (rate limit 10 req/second per client IP) Integration steps: No authentication required; use public API directly Build a lookup that accepts UEN, calls ACRA, and extracts the entity name and status At invoice creation, require the customer to enter UEN and the customer name Call ACRA and compare the returned entity name to the invoice customer name (fuzzy match, allowing minor typos) If no match or status is not 'live,' show error and block invoice save Cache the result for 7 days (entities rarely change status) Error handling: ACRA occasionally returns 503 during maintenance. Do not block invoice creation on a 503; instead, flag the invoice as "ACRA validation pending" and trigger a background retry after 5 minutes. If it still fails, escalate to an admin queue. Malaysia: NRIC and Company Registration via Suruhanjaya Syarikat Malaysia (SSM) Malaysia requires two separate lookups: Individual tax ID (NRIC): 12-digit number; validated via Inland Revenue Board (IRB) API Business registration (Company): 6–10 digit number; validated via SSM Company Portal API Both are restricted APIs requiring a commercial agreement. For NRIC (individuals/contractors): Endpoint: IRB MyTax Portal API (requires OAuth2 partnership agreement with IRB) Input: NRIC, date of birth Response: Name, tax filing status, outstanding tax liability flag Latency: 400–1200ms; rate limit 5 req/second For company registration: Endpo