Tax ID Validation in Invoicing

Q: What happens if LHDN's API is down when I try to create an invoice?

The invoice should be held in 'draft' status with a 'validation pending' flag. The system retries the lookup periodically. Do not auto-post it to GL. Your accountant should manually approve it once the API is back up, or override it with an audit log entry.

Q: Can I use a simple format check instead of real-time lookup?

No. Format checks catch typos, but they don't confirm the tax ID actually exists or matches the entity name. LHDN will reject syntactically valid NPWPs that don't exist in their registry. Real-time lookup is the only reliable method.

Q: How long does tax ID validation typically take?

LHDN, AKRA, and ACRA lookups usually complete in 1–3 seconds. If a lookup takes longer than 10 seconds, the API may be slow or unavailable. Set a timeout and queue the invoice for later validation rather than making the user wait.

Q: What should I do if a new company's tax ID doesn't appear in the registry yet?

Allow an accountant to manually override the validation with an approval comment. Log the override in your audit trail. Once the registry updates (typically within 24–48 hours), re-validate the invoice to confirm it now passes.

Your accountant just rejected 12 invoices. The reason: NPWP format was correct, but it didn't match the legal entity name in the invoice header. By the time you caught it, those invoices had already posted to your general ledger. Now you're spending four hours tracing and reversing entries, and your tax audit trail is a mess. This is not a hypothetical. Businesses across Indonesia, Malaysia, and Singapore lose days to this every month. The fix is simple: validate tax IDs before the invoice is created, not after it fails at the tax authority's gate. Why tax ID validation belongs in invoicing, not accounting Most teams treat tax ID entry as a data-entry task, same as contact name or address. It isn't. A tax ID is a legal reference that ties the invoice to a specific entity in your country's tax registry. If the ID doesn't exist, or if it's mismatched to the entity name, the invoice will either bounce at submission or fail audit years later. The cost of fixing this downstream is steep: Rejected invoices: LHDN (Indonesia's tax authority) rejects MyInvois submissions if NPWP format is invalid or doesn't match registered entity name. You can't file until you correct it. Accounting rework: Once an invoice posts to GL, reversing it creates a new journal entry. Auditors flag unusual reversal patterns. Withholding errors: If the tax ID is wrong, you may over-withhold or under-withhold on contractor payments. This creates discrepancies at tax filing. Audit exposure: Tax authorities now cross-check invoices against registry data. Mismatches trigger questions. The solution: validate at invoice creation time, before the user even sees a 'create' button. This is a pre-invoice gate, not a post-hoc fix. The three tax ID formats and real-time validation methods Indonesia (NPWP) NPWP (Nomor Pokok Wajib Pajak) is a 15-digit ID issued by Dirjen Pajak. Format: XX.XXX.XXX.X-XXX.XXX. The ninth digit encodes the entity type (person, CV, PT, etc.); the last five digits are sequential. Real-time validation via LHDN's API is now available through approved integrators, but many platforms fall back to format-only checks. Format validation is not enough. An invoice with a syntactically correct NPWP that doesn't exist in the LHDN registry will fail at MyInvois submission. Build in a real-time lookup step: Check format (15 digits, correct separators). Call LHDN's tax ID lookup API (if your integrator supports it) to confirm the ID exists and matches the entity name. If the API is unavailable, flag the invoice as 'pending validation' and hold it until the lookup succeeds or you manually verify it. Malaysia (BRN) BRN (Business Registration Number) is a 12-digit ID issued by the Companies Commission of Malaysia (SSM). Format: XXXXXXXXXX-XX. The SSM publishes a public registry, and most accounting platforms now integrate AKRA lookups (an SSM-approved validation service) to cross-check entity name, address, and director information. Real-time validation is more mature here than Indonesia. Most invoicing platforms can call AKRA to confirm BRN existence and match it to the company name. If AKRA rejects the lookup, the invoice should not be created until the discrepancy is resolved. Singapore (UEN) UEN (Unique Entity Number) is an 8- or 9-character ID issued by ACRA (Accounting and Corporate Regulatory Authority). Format: XXXXXXXXXX or XXXXXXXXXX-A. The ACRA public register allows real-time lookup. Validation is straightforward: format check + ACRA API confirmation. Building the pre-invoice gate: three layers Layer 1: Format and basic sanity checks Before any API call, validate locally: NPWP: 15 digits, correct separator positions, valid entity type digit (digit 9 must be 1–5). BRN: 12 digits, hyphen at position 11. UEN: 8–9 characters, correct format per entity type. This catches typos and copy-paste errors in seconds. If format fails, reject immediately with a specific error message: 'NPWP must be 15 digits. You entered 14.' Layer 2: Real-time registry lookup Call the tax authority's API (or an approved integrator like AKRA for Malaysia) to confirm: The tax ID exists in the registry. The entity name in your invoice matches the registered name (or is a close enough match, since minor abbreviations are common). The entity has not been deregistered or suspended. If the lookup fails, do not create the invoice. Show the user the error and ask them to verify the tax ID or entity name. If the lookup API is temporarily unavailable, queue the invoice as 'pending validation' and retry in 5 minutes. Do not silently create it without confirmation. Layer 3: Fallback and manual override Lookups fail. LHDN's API goes down. A new entity hasn't been indexed yet. Your system needs a fallback that doesn't compromise audit integrity: Soft fail: If real-time lookup fails after 3 retries, allow an accountant (not the person creating the invoice) to manually review and confirm the tax ID. Log this override in audit trail. Hold in draft: Mark invoices with unconfirmed