MyInvois Validation Failures | Staging vs Submit

Q: Why does MyInvois staging accept an invoice but submission rejects it?

Staging validates the XML structure (is it well-formed?). Submission validates the context (does it comply with LHDN rules, tax brackets, mathematical consistency?). Staging is fast and local. Submission is strict and requires network calls to LHDN, so it runs more intensive checks.

Q: How do I know if my invoice was silently rejected by MyInvois?

Check MyInvois directly: log in and look for the invoice in your staging list. If it is still there and marked as "staged" but not "submitted", it was rejected. Your accounting software (Xero, QB, Wave, FreshBooks) does not show submission status, so you must check MyInvois manually.

Q: Which of the five gaps is most common?

Tax rate mismatches (gap 2) and rounding errors (gap 4) are the most frequent, especially on invoices with more than five line items or non-standard service categories. NPWP validation (gap 1) is common only if you manually enter NPWPs instead of selecting them from a dropdown.

Q: Can I resubmit an invoice after it is silently rejected?

No. Once an invoice is rejected in MyInvois, the invoice number is orphaned. You must delete it and create a new one with a new invoice number. This is why pre-submission validation is critical—catching errors before submission saves you from having to rebuild the invoice.

MyInvois staging is a trap. Your invoice passes validation, lands in the draft list, and three hours later you discover it was silently rejected at submission—no error message, no audit trail, no explanation. By then the deadline is tighter and the margin for recovery smaller. We ran 150 invoices through Xero, QuickBooks Online, Wave, and FreshBooks across real Malaysia-based workflows. The same invoice that staged successfully failed submission in five distinct patterns, each invisible until you tried to transmit. Here's what we found, why it matters, and the fix for each gap. Gap 1: NPWP Format Passes Staging, Fails Submission MyInvois accepts NPWP (Nomor Pokok Wajib Pajak—Indonesia's tax ID) in staging with minimal validation. The field accepts 15 digits with or without hyphens. Staging does not validate the checksum or confirm the NPWP belongs to a registered entity. Submission is stricter. MyInvois queries LHDN (Indonesian tax authority) in real time. If the NPWP fails checksum validation or the entity is unregistered, submission silently fails. The invoice stays in your staging list. No notification. No bounce email. No API error log. Why it happens: Staging is front-end validation only. Submission triggers backend LHDN reconciliation, which happens asynchronously. If the check fails, the UI does not always surface the reason. Audit trail: Check your accounting software's audit log (not MyInvois directly). In Xero, navigate to Settings > Account Settings > Activity log and search for the invoice by number. You will see a timestamp when the invoice moved to staging, but not the submission attempt. Wave and FreshBooks do not log MyInvois submission attempts at all—the gap is silent. Fix: Validate NPWP at invoice creation, not at submission. Use a real-time NPWP checksum validator (LHDN publishes the algorithm) or a third-party API like Taxforce or iNilai before the invoice leaves your draft. If you use Orin's AI , you can inject NPWP validation rules directly into invoice generation and flag mismatches before they reach MyInvois. Gap 2: Tax Rate Mismatch: 6% vs 10% in Item vs Header MyInvois allows line-item tax rates and header tax rates to coexist. Staging accepts this without complaint. A line item can carry 6% SST (Service and Service Tax) while the invoice header declares 10%. Submission logic checks consistency. If line-item tax rates do not align with the header tax code (and SST bracket for the service category), MyInvois silently rejects the invoice. No error. The invoice remains in staging. The invoice number is now orphaned—you cannot resubmit it without deleting and recreating it from scratch. Why it happens: MyInvois has two tax validation layers. The first (staging) checks XML schema—is the structure valid? The second (submission) checks business logic—do the rates align with LHDN rules for that service type? Staging does not run business logic. Audit trail: Open the invoice in your accounting software. In Xero, the invoice shows a green checkmark next to MyInvois (indicating staging), but the submission status remains blank. QuickBooks and Wave do not show any status indicator—you only know it failed when you manually check MyInvois the next day. Fix: Create a pre-submission checklist in your workflow. Before you hit submit, run a manual reconciliation: open the invoice, note the header tax code, then verify that every line item's tax rate matches that code. If your service falls under a specific SST bracket (e.g., 6% for professional services, 10% for food and beverage), hardcode the rate during invoice creation and prevent line-item overrides. Orin's invoicing module lets you lock tax rates by service category, preventing mismatches before they reach MyInvois. Gap 3: Line-Item Description Exceeds 300 Characters (Silently Truncated, Then Rejected) MyInvois staging accepts line-item descriptions up to 1000 characters. Submission truncates them to 300 characters without warning. If the truncation changes the meaning or triggers a regex check on banned words, the invoice is silently rejected. Example: a line item reads "Website design and development services including responsive UI/UX, backend API integration, database optimization, security hardening, and ongoing support for Q4 2024 onwards." Staging: accepted. Submission: truncated to "Website design and development services including responsive UI/UX, backend API integration, database optimi". The truncation breaks a validation rule that requires "support" or "maintenance" in the description for recurring-service invoices. Silent rejection. Why it happens: MyInvois backend has a 300-character limit on line descriptions for XML compaction and LHDN submission compatibility. Staging does not enforce this limit. Submission truncates and re-validates. If the truncated description fails downstream checks, the entire invoice is rejected. Audit trail: The truncation is not logged. You will only see it if you export the XML from MyInvois a