Your invoice sits in the government e-invoicing system for approval. Hours later, it bounces back: NPWP mismatch. The client's tax ID on the invoice doesn't match what's registered in the DJP (Directorate General of Taxes) database. Now you're chasing the client for the correct number, re-entering it manually, resubmitting. Meanwhile, your payment is stuck. This happens because most billing teams treat NPWP like a memo field—something you capture if the client mentions it, validate when the system forces you, and store nowhere consistent. Indonesian tax law disagrees. Every transaction on an e-invoice must reference a valid, matching NPWP. Miss this and you expose yourself to penalty, delayed approval, or outright rejection. The fix isn't more diligence during invoicing. It's capturing the NPWP during client onboarding, validating it against the government register once, and binding it to that customer record so it pulls automatically onto every invoice. No repeated lookups. No manual entry. No surprises at submission. Why NPWP mismatch breaks Indonesian invoicing Indonesia's e-invoicing system (Sistem e-Faktur) integrates directly with the DJP's taxpayer register. When you submit an invoice, the system cross-checks: Seller's NPWP against their registered business identity Buyer's NPWP against their registered identity Invoice amount and tax calculation against the format rules for that NPWP's tax class If the buyer's NPWP on your invoice doesn't match DJP records—wrong digit, typo, inactive registration, or the client gave you their personal ID instead of their business tax number—the invoice fails validation. The system doesn't let you correct it inline. You cancel, re-enter, resubmit. For monthly recurring invoices, this compounds. Worse: if you invoice the same client multiple times with different NPWP variations (because you captured it differently each time), you create a audit trail that suggests either negligence or invoice manipulation. The DJP flags accounts with this pattern for deeper review. Capture NPWP during client onboarding, not during invoicing The moment a B2B client signs up or first orders, you need their NPWP. Don't wait until the invoice moment—by then the client is already in your system, possibly under a partial or incorrect name, and you're scrambling to fill a required field before payment can proceed. Build NPWP capture into your client intake form. Treat it like you treat legal company name and business registration number—non-optional for any Indonesian B2B client. What you should ask: Company legal name (as registered with the Ministry of Law and Human Rights) NPWP (15-digit tax ID; format: XX.XXX.XXX.X-XXX.XXX) NPWP registration date (to spot outdated registrations) Business address (must match NPWP registration) Contact person and their role (for tax correspondence) For clients with multiple tax IDs (holding companies with subsidiary registrations, or PMA entities with local tax branches), capture all of them and note which one applies to your transaction category. This matters: a holding company may have one NPWP for corporate tax and another for withholding agent status. Invoice the wrong one and it fails. Make it easy: if you use a CRM with client records , add NPWP as a required field on the company profile. Make it visible on the invoice template preview so your team sees instantly whether the ID is populated before generating the document. Validate NPWP against the DJP register Not every NPWP typed into a form is valid. Clients misremember digits, copy it wrong from letterhead, or give you an old number they're no longer registered under. Validate once, at capture, so you catch errors before they become invoice problems. The DJP doesn't publish a free public API for NPWP lookup, but several Indonesian fintech and tax software vendors offer validation services: Pajak.go.id (official government site): Let clients verify their own NPWP through the portal and screenshot it for you. Not scalable, but zero-error proof. E-filing and accounting software vendors (like Jurnal, Accurate Online, Siap Pajak): Most integrate with the DJP and can validate NPWP against the register as part of their invoice module. If your invoicing system connects to one of these, validation happens automatically. Third-party tax ID verification APIs : Services like Kanvas and Taxer offer NPWP validation that checks format, digit checksum, and (in some cases) registration status. These are faster than manual lookups but verify format more than active status. At minimum, validate the format: a real NPWP is 15 digits with a specific structure. The last digit is a check digit (Luhn algorithm). Catch transposed numbers before they hit the invoice. If the client's NPWP fails validation: flag it immediately in your intake flow. Don't proceed until they confirm it with a screenshot of their DJP registration or tax certificate. This is friction upfront, but it saves rejection cycles later. Store NPWP in your