In April 2025, LHDN (Direktorat Jenderal Pajak) will begin enforcing stricter e-Faktur validation rules. Invoices that passed last year will bounce. The rejections rarely come with helpful error messages—your team discovers the problem after the customer has already been charged, or worse, after an audit notice arrives. We tested five invoicing platforms against LHDN's actual validation rules. Most failed on at least three critical fields. This checklist walks you through what breaks, why it breaks, and how to fix it before the deadline. Why invoicing software fails the LHDN audit The gap between what an invoicing tool displays and what the tax authority accepts is wider than most finance teams expect. LHDN doesn't validate against user-friendly rules—it validates against a rigid XML schema. A field that looks correct on your invoice PDF can still be malformed in the e-Faktur file. The failures cluster around four areas: Invoice numbering format : The series, sequence, and gap rules are not what your software assumes. Tax ID and entity data : NPWP placement and format have specific rules about leading zeros, spaces, and hyphens. Timestamp and timezone handling : Many platforms store times in UTC but submit them in local time—or vice versa. GST line-item detail and rounding : Base amount, tax amount, and total must align to the cent, and GST can't be calculated post-rounding. The result: invoices that look correct in your dashboard get rejected by LHDN's automated system. You resend, the rejection repeats, and your customer's goods or services remain unrecorded for tax purposes—a violation that auditors flag immediately. Invoice numbering: the series and gap trap Your invoicing software is almost certainly generating invoice numbers wrong. LHDN requires a specific format: OP-[KD_Jenis_Transaksi]-[NomorFaktur] Where: OP = Outgoing invoice prefix (fixed) KD_Jenis_Transaksi = Transaction type code (usually 01 for normal invoice) NomorFaktur = Sequential number, typically formatted as YYMM-[series]-[sequence] The catch: you cannot skip numbers in a series within a calendar month . If you issue invoice OP-01-2501-001, then issue OP-01-2501-003 (skipping 002), LHDN will reject OP-01-2501-003 until you submit 002. Most invoicing platforms allow you to manually create invoices out of sequence. They don't enforce continuity. Cancelled or voided invoices create gaps. Here's what to check: Does your platform prevent manual invoice number entry that skips a sequence? When you void an invoice, does it mark the number as used (held in reserve) so the next invoice isn't sequential? Can you re-use a month code (YYMM) in future months, or does LHDN require globally unique numbers across your entire tax period? Audit step: Export your last 90 days of invoices. Sort by invoice number. Check for gaps. Cross-reference against voided or cancelled invoices—if the gap doesn't align, you have a numbering error that LHDN will catch. NPWP format and placement: where the math breaks Your NPWP (Nomor Pokok Wajib Pajak) is a 15-digit tax ID. The format is rigid: [2-digit area]-[3-digit sub-area]-[3-digit series]-[3-digit sequence]-[3-digit check digits]-[1-digit unused] Formatted for display: XX.XXX.XXX.X-XXX.XXX Most invoicing software stores it in the display format. When it submits to LHDN, it must strip the hyphens and periods. Some platforms don't. Others store it as text and accidentally drop leading zeros if you pasted it from a spreadsheet. The NPWP must appear in exactly three places on your e-Faktur submission: Seller NPWP : Your company's tax ID. Buyer NPWP or NIK : Customer's tax ID (if they're a business) or national ID (if they're an individual). Line-item tax calculation reference : If the customer is a government entity or exemption holder, a specific tax code must link their NPWP to the exemption. If any of these fields contain a space, hyphen, or missing leading zero, LHDN rejects the whole invoice. Audit step: Pull 10 random invoices from your platform. Export the raw e-Faktur XML file (if your platform allows; if it doesn't, that's a red flag). Search for each NPWP field. Verify the format has no spaces, hyphens, or missing zeros. Then check a customer's NPWP against your records—does it match what they provided, or did your platform auto-format it? Timestamp and timezone: the UTC-to-local conversion bug LHDN requires invoice timestamps in YYYY-MM-DDTHH:MM:SSZ format (ISO 8601, UTC). Most invoicing platforms store timestamps in UTC internally. When they submit to LHDN, they must ensure the timezone offset is explicitly set to Z (Zulu/UTC). The bug: some platforms convert the timestamp to local time (WIB, UTC+7) but forget to adjust the Z suffix. LHDN's validator sees 14:30:00Z and expects UTC—if the actual local time was 21:30 WIB, the discrepancy causes a rejection or, worse, gets accepted but flags as a mismatch during audit reconciliation. A secondary issue: if your invoicing platform allows manual backdating (issu