Most Indonesia invoicing teams assume NPWP validation is binary: either your tax ID format is correct or it isn't. They're wrong. LHDN's MyInvois system doesn't just validate the 15-digit NPWP itself—it validates where that NPWP sits, how it's encoded, whether it's mapped to the right entity field, and which transaction type it's paired with. Five specific field placements routinely pass your staging validator and fail LHDN's live audit 60 days later. By then, you've already posted to the general ledger, marked the invoice paid, and buried the rejection in a compliance backlog. We tested 150 real MyInvois invoices against LHDN's validator and traced each rejection back to a field position error, not a format error. Here are the five placements that tank validation—and how to catch them before LHDN does. 1. NPWP in the Buyer ID Field When It Should Be in the Tax ID Field The most common mistake: NPWP goes into your system's generic "buyer ID" or "customer ID" field instead of the dedicated tax ID field. Structurally, both fields accept 15 digits. Both pass your own validation logic. But MyInvois treats these fields as separate entities. When you send an invoice, MyInvois expects: Buyer ID = company registration number (if not an individual), or personal ID (KTP/passport for individuals) Tax ID = NPWP (mandatory for B2B invoices, optional for B2C but flagged if missing) If you populate only the Buyer ID field with NPWP and leave Tax ID blank, MyInvois passes it through staging. LHDN's real-time validator then rejects it 24 hours later because the NPWP wasn't declared in the tax-specific field. The fix: Map your invoice template so NPWP always routes to the Tax ID field, not Buyer ID. If you're using Orin's invoicing layer or another system, ensure your export schema has a dedicated NPWP field that doesn't double as a general ID field. 2. NPWP in the Wrong Entity Slot for Multi-Party Invoices MyInvois supports multi-party transactions: invoices where the seller, buyer, and a third-party withholding agent (pemotong pajak) all appear. Each party gets its own entity block with its own NPWP field. Here's where teams fail: they paste the same NPWP into both the buyer and withholding agent slots. This doesn't cause a format validation error—both fields accept 15-digit NPWPs. But MyInvois cross-references NPWP against the entity type. If the same NPWP appears as both buyer and withholding agent, LHDN flags it as a phantom entity (a single person playing two roles) and rejects the invoice. This happens most often in: Service invoices where a contractor is both the invoice buyer and withholding agent (common in staffing) Retainer invoices where you've mistakenly duplicated NPWP fields during template migration Multi-invoice batches where one invoice has the third-party NPWP set correctly, but another in the same batch copies it into the wrong slot The fix: Before you batch-upload invoices, audit the entity mapping. Each party (seller, buyer, withholding agent) must have a distinct NPWP, or one of the slots must be blank. If your billing system doesn't visually separate these fields, you're at risk. Test at least five invoices with different entity combinations before going live. 3. NPWP Missing the Leading Zero or Padded Inconsistently NPWP is formatted as a 15-digit string: 12.345.678.9-012.345. When you strip the separators for data entry, it becomes 123456789012345. But many billing systems treat this as a number, not a string. When a number is stored without leading zeros and then exported, the leading zero vanishes. An NPWP like 01.234.567.8-901.234 becomes 1234567890123 (13 digits) instead of 01234567890123 (15 digits). Your staging validator may accept this if it's only checking digit count ("at least 13 digits"). LHDN's validator rejects it because NPWP is always exactly 15 digits, and a leading zero is meaningful—it identifies a specific regional tax office cohort. The fix: Store NPWP as text, never as a number. In your database schema, use VARCHAR(15) or equivalent, not INT. When you export to MyInvois, wrap the field in quotes to force text encoding. Test by exporting a known NPWP starting with 0 and verify the leading zero survives the export. 4. NPWP Paired With an Incorrect Business Type Code MyInvois requires you to declare the business type (usaha) for each invoice party: whether they're a corporation (PT, CV, etc.), a sole proprietor (Perorangan), a foreign entity, or a government body. NPWP format is fixed, but the business type code signals to LHDN which NPWP registry to cross-check. If you declare a buyer as a "Perorangan" (individual, business type code 01) but attach an NPWP that's registered to a PT, MyInvois will flag a mismatch. The NPWP itself is valid—but it's not valid for that entity type. The invoice passes your staging because you only validated format; LHDN rejects it because you validated the wrong registry. This error is easy to miss because: Your CRM may store "business type" as a fre