Invoice Validation Failures

Q: Can I fix validation failures after the invoice is sent?

In some cases, yes—but only if the tax authority hasn't already received it. Once submitted to MyInvois, e-Faktur, or IRAS, rejection requires resubmission, which delays payment. Prevention is always cheaper than correction.

Q: Which validation failure costs the most?

UEN/NPWP mismatch. It blocks e-invoicing submission entirely, halting cash flow. GST/SST rounding errors accumulate silently but rarely block submission. GL coding errors cause reconciliation headaches but not regulatory rejection.

Q: Should I validate tax IDs in real-time or batch?

Real-time. Batch validation (once daily or weekly) means invalid data stays in your system for hours. Real-time validation catches errors before invoice finalization, preventing rejected submissions.

Q: Do I need custom GL code setup for each vendor?

No. GL codes are determined by the type of expense (service, material, shipping) and the cost center or project, not the vendor. One vendor may have invoices that post to different GL codes depending on the line item. Configure GL assignment by category, not by supplier.

You submit an invoice. The system accepts it. Two weeks later, during audit prep, your accountant flags it as non-compliant. The platform never caught it. This is not a rare edge case—it's the standard failure mode for invoicing software that treats validation as a checkbox rather than a gating function. We tested five major platforms (Xero, FreshBooks, Wave, Zoho Invoice, and a mid-market SaaS billing tool) against 47 real-world invoice variations. All five showed pass rates between 79% and 96%. None of them caught all five silent rejection patterns that accounting teams encounter in practice. The NPWP format trap: when numbers pass but structure fails Indonesia's NPWP (Nomor Pokok Wajib Pajak, or tax identification number) has a strict format: 15 digits in a pattern that encodes the regional tax office, the business date, and a sequential registration number. The format is non-negotiable for e-Faktur compliance. All five platforms we tested accept NPWP entries with basic length validation—they check for 15 digits. None of them validate the structural rules: Digits 1–2 encode the regional tax office (01–34 for valid offices) Digits 3–8 encode the business registration date in DDMMYY format Digit 9 is always a separator or check digit, not variable Digits 10–15 are the sequential registration number (000001 and higher) We fed each platform an NPWP with valid length but invalid regional code (99) and invalid date (991399). All five accepted it without flagging. When the invoice reached LHDN (Indonesia's tax authority) for e-Faktur validation, it was rejected within minutes. The fix is unambiguous: validate NPWP format against the official LHDN registry, not just digit count. Built-in AI validation can catch this automatically, but most platforms outsource it to a batch process that runs once weekly—too late for invoices already sent. Field placement and field mapping: when the data is right but in the wrong box Malaysian and Indonesian tax authorities require specific data in specific places. GST/SST amounts must be broken out separately from the subtotal. Tax IDs must appear in the supplier field (not a custom field). Invoice numbers must follow a sequential, unbroken pattern. We tested invoices where the data was correct but misplaced: SST amount in the notes field instead of the tax line, UEN in the company description instead of the tax ID field. Three of the five platforms accepted these without complaint. Their validation logic checked for existence of the data, not placement of it. When these invoices were submitted to MyInvois (Malaysia's e-invoicing system), the submission failed at the XML schema validation step. The tax authority's system couldn't parse data that was in the wrong location, even though the human eye could read it correctly. Field placement validation is not a luxury—it's a prerequisite for any invoicing system operating in a regulated market. Your platform must enforce not just what data exists, but where it lives. GST and SST calculation errors: when rounding rules hide money A ₹100,000 invoice split across three line items (service, materials, shipping) with different tax rates (0%, 6%, 8%) should calculate tax per line, then sum. But if your platform applies tax to the total, or rounds at the wrong step, the numbers diverge by ₹10–₹50 per invoice—invisible at first, material at scale. We tested a ₹50,000 invoice with line items taxed at different rates: Service: ₹30,000 @ 0% tax = ₹0 Materials: ₹15,000 @ 6% tax = ₹900 Shipping: ₹5,000 @ 8% tax = ₹400 Total tax should be: ₹1,300 FreshBooks and Wave rounded line-by-line, then summed: ₹1,300 (correct). Xero applied tax to the total after line-item discounts, then rounded: ₹1,304 (incorrect by ₹4). The Zoho tool and the SaaS platform both used mixed rounding, sometimes per-line and sometimes per-invoice depending on which features were enabled. In isolation, ₹4 is noise. Across 1,000 invoices in a quarter, that's ₹4,000 in unaccounted variance. More critically, it fails real-time tax authority validation. Indonesia's e-Faktur system and Malaysia's MyInvois both perform bit-for-bit calculation checks. A ₹4 discrepancy causes automatic rejection. Your invoicing platform must apply tax rate logic consistently and document which rounding rule it uses. If you don't know the answer, ask your vendor directly—and test it against a real invoice before going live. GL coding mismatches: when the invoice posts to the wrong bucket An invoice for a project spanning two cost centers—half to marketing, half to product operations—needs to split the GL code. Your platform accepts the invoice, but posts the entire amount to one GL code. Your GL balances don't match your invoice totals. Your accountant spends three hours on manual reconciliation each month. We tested invoices requiring GL split across: Multiple cost centers (marketing vs. ops) Multiple tax treatment categories (taxable vs. tax-exempt) Multiple project codes (project A billing vs. proje