You've built a clean invoice. The line items add up. The customer's name is spelled right. You hit submit to MyInvois, and three days later it bounces back with a cryptic validation error—or worse, it silently fails and never reaches the LHDN system at all. The five most common MyInvois rejections don't scream. They hide in field format, tax logic, and GL code placement. And they cost you delay, manual rework, and audit risk. This is the 15-minute staging audit that catches them before you submit. The NPWP format trap: Leading zeros and hyphens matter Your vendor's NPWP looks correct: 123456789012 . LHDN disagrees. MyInvois validation requires NPWP in the exact format LHDN publishes it—and that format includes leading zeros and hyphens in a specific pattern. The canonical NPWP format is: XX.XXX.XXX.X-XXX.XXX . If you strip the dots and hyphens, or if you omit leading zeros during import from your CRM or accounting system, the invoice fails validation silently. The system does not flag it as malformed; it simply rejects the entire document during LHDN submission. What to check: NPWP field contains exactly 15 characters (including dots and hyphens). If you're pulling NPWP from your CRM , verify the import does not strip formatting. For batch invoices, run a sample of ten NPWPs through LHDN's real-time validation API before submission. If your invoicing platform supports it, enforce NPWP format validation at field entry—do not wait until staging. The cost of missing this: One invoice, three days delay, plus manual rework of the entire batch if you discover it only after submission. GST on services: The line-item tax code mismatch You invoice a service retainer. The invoice total is correct. But MyInvois validation fails because you've applied service GST code to a line item that MyInvois classifies as supplies —or vice versa. Indonesia's tax treatment of services diverges sharply from goods in MyInvois. A consulting retainer, a software license renewal, and a training delivery each require different tax codes. And those codes don't always align with how you've classified them in your accounting system. More subtly, some service retainers are taxable and others are not—depending on whether the customer is a registered tax entity. MyInvois requires you to flag this correctly at the line-item level. If you use a blanket "service" tax code across all line items, some invoices will validate and others will not, with no obvious pattern. What to check: For each line item, confirm the tax classification: is it a good, a taxable service, or an exempt service? Cross-check against LHDN's current service GST rules—they shift with quarterly guidance updates. If you're invoicing the same service type to both registered and unregistered customers, validate both paths in staging. In your invoicing system, set tax code rules at the GL account level, not at the invoice level. One wrong default will corrupt an entire batch. A batch of 50 consulting invoices passed validation—except those for unregistered customers, which failed silently. The difference was a single tax code flag that your accountant had marked as "service" instead of "service (non-GST)". The second pass, after correction, took six hours and delayed payment by two weeks. GL code placement: Where the ledger-account mismatch hides Your invoice posts to the right GL account in your accounting system. But MyInvois validation requires the GL code to match LHDN's chart of accounts for the customer's industry and registration tier—and that mapping is not automatic. You've coded the line item to GL 4100 (Service Revenue). LHDN's validation expects 4150 for consulting or 4200 for third-party services, depending on the customer's status. The mismatch doesn't cause an error message; it causes the invoice to fail the structural validation phase silently. This is especially painful in batch submissions. One invoice in a batch of 20 might have the wrong GL code. The entire batch fails, and you have to resubmit all 20 to correct the one. What to check: Pull your current GL mapping from your accounting platform. Compare it to LHDN's published chart of accounts for your industry. For each invoice, verify that the line-item GL code matches both your local chart and LHDN's expected structure. In staging, create a test invoice for each customer type (registered GST, unregistered, B2B, B2C) and confirm GL placement. If your invoicing system supports GL validation rules, enable them. If not, add a manual check to your staging audit. Field placement order: MyInvois is picky about sequence MyInvois validation has a strict field sequence requirement. Invoice number, date, customer NPWP, line items, tax total—they must appear in the XML payload in the exact order LHDN specifies. If your invoicing system or billing integration reorders fields to match your internal database schema, validation fails silently at the structural phase. You won't see a red flag that says "field out of order." T