You've built your invoice in your accounting software. The totals look right. You hit submit to LHDN's MyInvois system. Three days later, your batch comes back rejected—and now you're digging through error logs trying to figure out which field broke the submission. By then, you've lost a week of cash flow, your team is firefighting, and your customer is asking where their invoice went. This scenario is avoidable. LHDN publishes a free, real-time MyInvois validation tool that sits between you and batch submission. Most teams skip it. The ones that don't catch 80–90% of failures before they cost time and credibility. Here's how to use it properly—and what to test before you ever touch the submit button. Why validation testing matters: The cost of a batch rejection A single rejected invoice in a batch of 50 can halt the entire submission. LHDN doesn't parse the good ones and retry the bad ones; the system flags the batch and returns it unsigned. Your invoices sit in limbo. Your customers can't record them against purchase orders. Your cash-flow forecast assumes invoices posted on day 5; they actually post on day 12. Common rejection causes: NPWP format —spaces, hyphens, or wrong length (must be exactly 12 digits with no separators in the submission format) Tax code mismatches —invoice line item says SR01 (standard rate) but amount doesn't match the rate percentage applied Rounding errors —total tax calculated as ₹1,299.99 but rounded to ₹1,300; the validator flags the ₹0.01 discrepancy Missing or malformed datetime stamps —invoice date is present but timezone or format doesn't match the schema Customer tax ID absent or invalid —submission requires valid customer NPWP or BRN even for B2C sales in some states Each of these will pass initial submission to your invoicing software but will fail when the software transmits to LHDN. The validator catches them before transmission. Setting up the LHDN validator: Access and environment setup LHDN hosts two validation environments: staging (sand box) and production (live). Staging first. Always. The staging validator uses test credentials and has no rate limits. You can throw 1,000 test invoices at it in a session without hitting throttling or incurring costs. Failures in staging are free. To access staging: Log in to your LHDN MyInvois account (your unique user ID and password, issued during onboarding). Navigate to the Test Environment or Sandbox portal (URL varies by portal version—check LHDN's latest documentation; as of 2025, it's typically under "Portal Settings" → "Environment"). Download the staging validation certificate and keep it in a secure, version-controlled location (same folder as your production cert, but labeled clearly). Confirm your test UID and API key are different from production keys. Most teams label them as UID-staging and UID-prod to avoid accidental production submissions during testing. Once you're in staging, you can submit individual invoices or small batches (10–20 at a time) and see real-time validation output. The validator returns either a success payload (invoice accepted and timestamped) or a structured error message that tells you exactly which field failed and why. Field-by-field validation: Where invoices actually fail The validator works through a checklist. If any field fails, the entire invoice is rejected. Here's the priority order (the order in which the validator checks them): Invoice metadata (highest priority) Invoice number —must be unique within your series; if you're resubmitting a failed invoice with the same number, the validator sees it as a duplicate. Issue date and time —must be in ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ) and cannot be in the future or more than 30 days in the past (LHDN's lookback window). Invoice type code —01 (invoice), 02 (credit note), 03 (debit note). Mismatching the code to the transaction (e.g., marking a credit as 01) will fail at this stage. Supplier and customer tax IDs (second priority) Your NPWP —12 digits, no spaces or hyphens in the submission. The validator checks format first, then cross-references it against the registry (this is where many teams fail; they format the NPWP correctly but don't realize the number itself was never registered with LHDN). Customer NPWP or BRN —format and registry match required. If the customer is unregistered or their NPWP is inactive, the invoice will fail even if the format is correct. Customer identity fallback —if the customer has no NPWP, LHDN allows some invoice types to use alternative ID (e.g., passport for foreign clients). The validator will flag if you've supplied an NPWP that doesn't exist but haven't provided the fallback ID. Line items and tax breakdown (third priority) Tax code per line —SR01 (6%), SR02 (10%), ZR (0%), ER (exempt). Mismatching the code to the amount or the customer type (B2B vs B2C) will fail here. Tax calculation precision —tax amount must equal (line subtotal × rate %) rounded to 2 decimals. If you've rounded the tax in