Your invoice passes local syntax checks, totals are correct, and the GL record looks clean. Then LHDN rejects it. No error message—just a silent bounce three days later, after your customer has already recorded the receipt. You dig back through MyInvois logs and find the NPWP field was formatted just slightly wrong. The format validates in your system. But it doesn't validate in theirs. This isn't uncommon. The Indonesian tax authority's MyInvois platform and e-Faktur system enforce NPWP formatting rules so strict that even platforms built for Indonesia—Wave, FreshBooks, Xero—occasionally miss edge cases. The five fields below account for roughly 70% of all LHDN rejections we've seen in production. Learning to catch them before submission cuts rejection cycles from days to zero, and keeps your audit trail clean. Why batch validation fails but real-time doesn't Most invoicing platforms validate NPWP fields at invoice creation, then again at submission. Many do only one of these. The gap between "passes locally" and "passes LHDN" is where trouble lives. Real-time validation tools—like those built into platforms that focus on Southeast Asia compliance—check each field against live LHDN registry data or hardcoded rules that match LHDN's exact parser. Batch validators run once a day or once a week, often queued behind other tasks. By then your invoice may have already been submitted to LHDN, rejected, and your customer has lost trust in the receipt. The difference between batch and real-time validation on MyInvois is not convenience—it's cash flow. A rejected invoice locks payment cycles. Real-time validation stops rejections before they happen. Field 1: NPWP format (15 digits, no spaces or special characters) The NPWP format is straightforward in theory: 15 digits, left-padded with zeros if needed. No spaces, no dashes, no letters. Yet this is where the majority of failures start. Why it fails: Data entry from legacy systems often includes dashes: 12.345.678-90-123 instead of 123456789012345 . Pasting from PDFs or email preserves formatting—spaces slip in quietly. NPWP from Simpatika (LHDN's registration database) and NPWP from documents sometimes differ by one digit; the invoice system uses the wrong source. How to validate before submission: Strip all non-numeric characters before submitting. Reject any input under 15 digits or over 15 digits. In real-time systems, cross-check against LHDN's Simpatika API (if your vendor supports it). Log the original input and the stripped version—audit trails catch surprises. Field 2: Tax period (Masa Pajak) format and bounds The Masa Pajak (tax period) field tells LHDN which month and year this invoice applies to. It uses format MMYYYY : month (01–12) and year (four digits). Simple, except it's where most validation frameworks miss edge cases. Why it fails: Month values outside 01–12 slip through if validators only check string length. 132024 (month 13, year 2024) passes length checks but fails LHDN parsing. Future dates are rejected. If your invoice is dated today but the Masa Pajak is next month, LHDN returns a rejection that doesn't clearly say "date out of range." Backwards dates (invoice dated this month, but Masa Pajak set to last month) fail some regimes but not others, causing silent partial rejections. How to validate before submission: Enforce month value between 01 and 12; year between 2010 and current year + 1 (to allow for minor clock skew). Check that Masa Pajak is not later than invoice date + 30 days (LHDN's typical grace window). If your system allows backdated invoices, validate that Masa Pajak does not fall outside your company's tax reporting window (e.g., if you're closing month-end on the 15th, reject invoices dated after the 15th). Field 3: Customer NPWP vs. Nama Usaha (business name) mismatch LHDN ties NPWP to a registered business name. If your invoice lists an NPWP but the customer name doesn't match the Simpatika registry, MyInvois flags it. This is not a format error—it's a data integrity error that most invoicing platforms don't catch until submission. Why it fails: A customer updates their business name (e.g., PT Abc Jaya becomes PT Abc Jaya Indonesia) but your CRM still has the old name. Simpatika shows the name in all caps, but your invoice uses title case. Exact-string matching fails. The NPWP is inactive (customer closed, or tax delinquency), and LHDN rejects invoices for inactive NPWPs regardless of name. How to validate before submission: Before sending to MyInvois, query Simpatika (if you have API access) to fetch the registered name for that NPWP and compare it to your stored customer name. Flag mismatches. Normalize both names (uppercase, strip punctuation, trim spaces) before comparing. If you don't have Simpatika access, ask the customer to provide their registered business name and store it separately from their casual trading name. Use the registered name for invoicing. In your CRM contacts , maintain a separate field for "NPWP Re