Your invoice sits in a buyer's queue for approval. Finance flags it: NPWP format invalid, or the tax ID doesn't match the LHDN registry. Payment stalls. You re-issue. Cycle repeats. By the time the invoice clears, you're 30 days behind on cash flow and the buyer has half-forgotten why they owe you. In Indonesia, this is not a corner case—it's the default failure mode. NPWP (Nomor Pokok Wajib Pajak, the Indonesian personal or business tax identification number) validation is mandatory for invoicing, and many platforms either skip it or leave it to chance. The result is invoices that pass your internal checks but fail at buyer payment and tax authority review. The fix is simple but requires intentional design: capture NPWP in your intake workflow, validate the format immediately, match it against the LHDN (Direktorat Jenderal Pajak) registry in real time, and prevent any invoice from being generated until validation passes. This post shows you exactly how to build that workflow and where to embed it in your billing system. Why NPWP validation breaks in standard invoicing tools Most invoicing platforms built for North America or Europe have no NPWP field at all. Some Indonesian-adjacent tools add a text field but do not validate. The result is that buyers enter whatever they remember, or leave it blank, and invoices are issued anyway. Finance catches it later—or the tax authority does during audit. Even tools that support custom fields rarely connect to live LHDN data. You can store an NPWP number, but you cannot verify that: The format matches LHDN standards (16 digits for individuals, specific pattern for businesses). The number actually exists in the LHDN registry. The registered name matches your buyer. The tax status is current (not revoked or suspended). Xero, Wave, and Zoho have some Indonesia support, but their NPWP validation is either limited to format-checking or absent entirely. They do not natively connect to LHDN APIs. This means validation is either manual (your finance team checks each one) or skipped entirely. The cost of this gap is twofold: delayed payments when invoices are rejected, and compliance risk if invoices are issued to invalid or suspended NPWP accounts. Where to capture NPWP in your intake workflow The moment a buyer agrees to work with you, you need their NPWP. This is not something you ask for at invoice time—by then, you are under deadline pressure and the buyer is distracted. Capture it upfront, in your client onboarding flow. If you use booking links or intake forms, add an NPWP field as a required input. Pair it with clear labeling: For individual buyers: "Your NPWP (16 digits, format: XX.XXX.XXX.X-XXX.XXX)" For business buyers: "Your Company NPWP (16 digits)" plus a field for the registered business name. A link to Ortax or the LHDN public registry where they can look up their own NPWP if they do not have it memorized. If you collect contracts or use e-signature workflows, embed the NPWP field in the intake form that precedes the contract—not inside the contract itself. This keeps validation upstream of document execution. Store the NPWP in your CRM contact record , not just in a separate intake system. Your invoicing tool needs immediate access to it. If your CRM and invoicing tool do not sync automatically, you will lose the validation benefit. Format validation: the first gate Before you ping the LHDN registry, validate the format locally. This catches typos and obviously malformed entries in seconds, without API latency. NPWP format rules: Total length: 16 digits (no letters, no spaces, unless formatted for display). Structure: XX.XXX.XXX.X-XXX.XXX in display format; stored as a continuous 16-digit string. Check digit: The 10th digit is a check digit. It is calculated from the first 9 digits using a modulo-11 algorithm. Some validators check this; most do not have the algorithm and rely on LHDN registry match instead. Digits 11–15: Serial number, assigned by LHDN. Not meaningful to validate independently. A simple regex will catch format errors: Regex for 16-digit NPWP: ^\d{16}$ (after stripping any dots or hyphens from display format). This is fast, happens on form submission, and gives the user immediate feedback: "NPWP must be 16 digits." Do not wait to validate against the registry; give format feedback instantly. Real-time LHDN registry matching After format validation passes, call the LHDN API (or a third-party wrapper that queries it) to verify the NPWP exists and is active. This is where the real compliance protection lives. Options for LHDN validation: Direct LHDN API: The LHDN provides a public verification service, but access varies by region and requires registration. Contact your local LHDN office or tax consultant for integration details. Third-party tax ID validators: Services like NPWP checker APIs (available from Indonesian tax consulting firms and some fintech platforms) wrap LHDN data and expose it via REST endpoint. Cost is typically a few thousand