An invoice bounces back from your accountant. The customer's tax ID is missing, malformed, or doesn't exist in the national registry. You scramble to find the right person, resend it, and now cash is 5–10 days late. Neither your CRM nor your invoicing tool caught it. Tax ID validation is not a fancy feature. It's a blocking point. In Indonesia, Malaysia, and Singapore, mismatched or invalid tax identifiers will either reject your invoice at submission or—worse—get flagged in an audit. Yet most CRM platforms don't validate them at all, and most businesses don't know which formats are even required. This playbook walks you through the validation rules, the lookup APIs that actually work, and exactly where to enforce them in your CRM and billing workflow so invoices move forward instead of backward. The three tax ID formats you need to validate Each country uses a different identifier, format, and audit depth. You cannot treat them the same. Indonesia: NPWP (Nomor Pokok Wajib Pajak) Format: 15 digits, grouped as XX.XXX.XXX.X-XXX.XXX Rules: Must be registered with LHDN (Direktorat Jenderal Pajak). First two digits encode the tax office region (01–34). Digits 3–5 encode the registration sequence within that office. Digit 6 is a check digit (calculated from the previous five). Digits 7–9 encode the taxpayer type (001 = individual, 002–999 = business variants). Last three digits are sequential within the type. The check digit is critical. Many systems validate the format without checking the digit itself, which means they accept invalid NPWPs. The algorithm is modulo-11, and it's public, but not every lookup service uses it. Validation challenge: An NPWP can be syntactically correct but not exist in the LHDN registry. A real-time lookup requires access to LHDN's API, which is restricted to certified tax consultants and accounting software vendors. Most SMBs don't have direct access. Malaysia: NRIC/BRN and ACRA Registration Format varies by entity type: Individual: NRIC (Nombor Kad Pengenalan) = 12 digits (YYMMDD-PB-GGGG-C), where PB is place of birth code. Business: BRN (Business Registration Number) = 12 digits (YYMMDD-PB-GGGG-C) OR new SSM registration number. Company: ROC (Registration of Company) = 6–8 alphanumeric digits, issued by SSM (Suruhanjaya Syarikat Malaysia). ACRA (Agensi Kutipan Zakat Perak) manages zakat registration separately, but most business validation focuses on SSM registration. Validation challenge: Malaysia has migrated to SSM Online with 12-digit BRN for most businesses, but old ROC numbers still appear. Your system needs to recognize both, and lookup requires access to SSM's restricted API or a certified intermediary. Singapore: UEN (Unique Entity Number) Format: 9–12 characters, two letters + 7 digits + 1 check letter (e.g., 201234567Z for a company, 12345678-1001 for a foreign company branch). Rules: First two letters encode entity type (PA = partnership, LP = limited partnership, LL = limited liability partnership, FC = foreign company, etc.). Middle digits encode the registration date and sequence. Last character is a check digit (calculated with a Luhn variant). Validation challenge: ACRA's public UEN lookup is free but slow (batch queries require registration). Real-time validation is possible but rate-limited. Key takeaway: Each country's tax authority guards its registry differently. Indonesia is hardest to reach; Malaysia is transitioning; Singapore is most open. Plan your validation strategy around API access, not just format checking. Where validation fails in your workflow Most businesses lose tax ID data at three points: 1. At quote creation—no validation upfront You or your sales rep creates a quote in the CRM, adds a customer contact, and leaves the tax ID field blank or guesses the format. By the time the invoice is issued weeks later, nobody remembers. The invoice reaches accounting, hits a validation block, bounces back to you. Fix: Make the tax ID field required in your CRM when you change the customer's country to Indonesia, Malaysia, or Singapore. Add an inline validation message that shows the expected format. Use a lookup API to confirm the ID exists (if available) or at least validate the check digit. 2. At invoice generation—format accepted but wrong Your invoicing tool accepts any string that looks like 15 digits for an Indonesian NPWP. It doesn't check the check digit. It doesn't hit the LHDN registry. The invoice goes out with a syntactically valid but functionally invalid tax ID. Fix: If your invoicing tool supports webhooks or APIs, intercept the invoice-creation event and run a validation check before the invoice is finalized. If it doesn't, configure a pre-invoice approval step in your accounting software that forces a lookup before submission. 3. At submission to tax authority—real-time rejection You submit the invoice to MyInvois (Malaysia), e-Faktur (Indonesia), or IRAS (Singapore), and the tax ID fails validation in real time. The entire invoice batch