NPWP Tax ID Validation Indonesia

Q: Can I use a contractor's NPWP from their business card or email?

No. Business cards are often outdated or typographical errors slip through. Always request it from official tax registration documents and cross-check it against the free tax authority search tool (ortax.org) before storing it. A ten-minute verification saves 14 days of rejection.

Q: What if the contractor's NPWP has leading zeros and my spreadsheet drops them?

Format the cell as text before pasting. In Excel: Right-click → Format Cells → Text. In Google Sheets: Format → Number → Text. This prevents automatic zero truncation. Better yet: store NPWP in a dedicated CRM field that enforces text-only input.

Q: Does MyInvois staging validate NPWP the same way production does?

Yes. The staging environment runs the same checksum and entity-type logic. A test invoice that passes staging will pass production. Always run one staging test before your first production invoice.

Q: Can I batch-validate NPWPs for 50+ contractors at once?

Yes, but do it carefully. Use the tax authority's bulk search tool or write a script that loops through the MyInvois validation API and logs results. Never assume all NPWPs are correct; validate each one individually and flag failures for manual review before invoicing.

You've invoiced before. You've done it correctly dozens of times. Then you land your first Indonesian client, submit an invoice through your billing software, and it vanishes into the tax authority's system. Two weeks later: rejected. The reason? A five-character field placement error in your NPWP number that your platform didn't catch. This happens to roughly three out of ten businesses invoicing in Indonesia for the first time. The cost is not just the resubmission delay—it's the cascade: delayed payment approval, client confusion, tax authority flags on your account, and the grinding work of tracking down which field silently failed. Most accounting platforms don't validate NPWP syntax before submission. They assume your data entry is correct. It usually isn't. Here's what fails, why it fails, and the 14-day checklist that stops it. Why 30% of first invoices fail: The five NPWP field traps An NPWP (Nomor Pokok Wajib Pajak) is a 15-digit tax identifier. It looks simple. It's not. Each position encodes something specific, and tax authority validation—especially since MyInvois 2.0 went live—checks every single one. Position trap 1: Leading zeros get truncated in text fields An NPWP often starts with zeros: 00.123.456.789.012 . When you paste it into a text field that doesn't explicitly format as text, Excel, Google Sheets, and some billing platforms automatically drop the leading zeros, converting it to 123456789012 . The tax authority's system immediately rejects it. You don't see this happen. Your data looks correct on screen. Position trap 2: Formatting characters in the wrong places NPWP formatting varies by context. The authority accepts both 00.123.456.789.012 (dots) and 00123456789012 (no formatting). But if you submit 00-123-456-789-012 (dashes) or mix formats like 00.123456.789.012 , MyInvois rejects it. Most platforms either strip all punctuation or pass it through raw. Either works—unless your data has inconsistent formatting, which most spreadsheet-sourced data does. Position trap 3: Spaces in positions 14–15 (check digits) Positions 14 and 15 are check digits calculated from positions 1–13. If your NPWP entry accidentally includes a space in position 14 or trailing whitespace after position 15, the checksum validation fails silently. The invoice looks complete; the tax system rejects it. Position trap 4: Wrong entity type encoding in position 9 Position 9 encodes entity type: 0 = individual, 1 = non-individual (business). If you invoice an Indonesian business partner using their personal NPWP with a 0 in position 9, the system flags it as a mismatch during entity cross-check. The invoice doesn't immediately fail, but the tax authority's system queues it for manual review, adding 5–14 days. Position trap 5: Branch code mismatch (position 11–13) For businesses with multiple branches, positions 11–13 encode the branch identifier. If your vendor provides an NPWP that belongs to their main office but you invoice the branch, MyInvois cross-references the entity registry and flags it as a mismatch. This is less common but catches 2–3% of multi-location businesses. Real-time validation: The MyInvois API check that catches all five Instead of discovering this two weeks after submission, you can validate in real-time before the invoice ever leaves your system. The MyInvois API (Indonesia's e-invoicing standard) includes a tax ID validation endpoint that returns pass or fail within 200–400ms. Here's what a real-time check workflow looks like: Contractor enters NPWP into the invoice form (or you pull it from your CRM contact record). Your system sends it to MyInvois validator : The API checks syntax (15 digits, valid checksum, entity type logic). Validator returns pass/fail + reason : If it fails, you show the error immediately and block submission. Example failure: "Position 14–15 check digit mismatch; recalculated value is 47". Only valid NPWPs flow to invoice generation . Tax authority receives zero-defect invoices . The math: Real-time validation eliminates 28 out of 30 failures before submission. The remaining 2% are usually branch code mismatches or stale entity registry data—fixable with one phone call to the contractor, not a tax authority escalation. Most standalone invoicing tools (Wave, Zoho Invoice, Square Invoices) don't include this check. They assume NPWP data is correct. Platforms like Orin that integrate accounting and CRM can layer real-time validation on top because they control the full invoice workflow—entry through MyInvois submission. What happens after you submit invalid data: The 14-day cascade If an invoice with an invalid NPWP reaches the tax authority, here's the timeline: Day 0–1: Submission accepted (the system doesn't immediately reject, it queues for processing). Day 1–3: Automated syntax check fails . The tax authority's system generates a rejection notice and sends it back to your e-invoicing platform. Day 3–5: You discover the rejection (if you check your dashboard; most