MyInvois rejection is silent. You submit. Silence. Then, days later, your accountant tells you LHDN flagged the batch. By then, you've lost 2–7 days and your payment is stuck. The system doesn't tell you which field broke or why —it just rejects the batch and waits. We've rebuilt invoicing for teams across Malaysia and Indonesia. In that work, we've seen five fields fail repeatedly, each one blocking the entire submission. None of them are obvious until you test in staging. This checklist will save you days. Failure mode 1: NPWP format—leading zeros and segment length The NPWP (Nomor Pokok Wajib Pajak) is Malaysia's tax ID. MyInvois expects it in a specific format: 12 digits, no spaces, no dashes, no leading zeros stripped . Real rejection sample: Submitted: 123456789012 Status: Rejected Reason: Invalid tax ID format (silent—no error message in UI) Why this fails: If you're pulling the NPWP from a contact database and that field has been cleaned (leading zeros removed, or spaces added by a spreadsheet import), MyInvois will reject it. The system doesn't warn you—it just bounces the batch. Test in staging: Pull five real NPWPs from your contact database. Submit them to MyInvois staging environment. Check the response. If any fail, trace back to your data source. Is the import stripping leading zeros? Is the field set to numeric instead of text? If you're using a CRM with contact validation , lock the NPWP field to text-only and enforce 12-digit rules at entry. Real impact: One team lost 3 days because their spreadsheet import had converted the NPWP field to numeric, stripping the leading zeros. When they resubmitted with text formatting, it passed. Failure mode 2: SST (Sales and Service Tax) miscoding—rate vs. code mismatch SST in Malaysia is 6%. But MyInvois requires you to code it correctly. If you submit an invoice with a 6% SST line item but the wrong SST code , the batch fails silently. Real rejection sample: Line item: Service, ₹10,000, SST 6% (₹600) SST code submitted: SR (Service, Recognized) Correct code: SR or SC (depending on service type) Result: Batch rejected, no error message visible in dashboard Why this fails: MyInvois validates the SST code against the transaction type. If you've coded a service as "Goods" and applied the SST code for goods, it fails. The system does not tell you which line item broke. Test in staging: Create a test invoice with three line items: goods only, service only, mixed goods and service. Submit each variation with the correct SST codes (consult LHDN's MyInvois documentation for your transaction type). Note which codes pass and which fail. Document the rule for your team. If your invoicing platform auto-codes SST, verify the logic in staging before going live. Real impact: One team coded all services with the "Goods, Recognized" SST code. Eight invoices failed in one batch. Resubmission took 4 days. Failure mode 3: Sequence gaps—invoice numbers not sequential MyInvois requires invoice numbers to be sequential. If you skip a number (e.g., INV-001, INV-002, INV-004), the batch fails. This is a silent failure—you get no error, just rejection. Real rejection sample: Invoices submitted: INV-001, INV-002, INV-004 Result: Rejected Reason: Sequence gap detected (not explicitly stated in response) Why this fails: If you've manually deleted a draft invoice or canceled a transaction, MyInvois expects the number to still be in the sequence when you submit. You cannot skip numbers, even if the invoice was never sent to a customer. Test in staging: Generate a batch of test invoices with a known starting number (e.g., TEST-001). Delete one in the middle (TEST-003). Try to submit TEST-001, TEST-002, TEST-004. The batch will fail. Now resubmit with a placeholder invoice for TEST-003 (mark it void or canceled). This should pass. If your invoicing system auto-generates numbers, ensure it never reuses or skips. If you cancel an invoice, create a credit memo instead. Real impact: One team canceled an invoice mid-month. When they submitted the next batch, MyInvois silently rejected it due to the gap. They had to create a void invoice to fill the gap, then resubmit. 2 days lost. Failure mode 4: GL posting conflicts—duplicate GL codes or missing journal entries MyInvois validates that every invoice line item posts to a valid GL account. If your GL code is invalid, inactive, or duplicated in a single invoice, the batch fails. Real rejection sample: Invoice line 1: Service income, GL code 4001 Invoice line 2: Service income, GL code 4001 (duplicate) Result: Rejected (no error visible in UI, batch marked failed) Why this fails: MyInvois syncs with your accounting system (Xero, FreshBooks, Wave, or local Malaysia/Indonesia systems). If the GL code doesn't exist in your chart of accounts, or if you've posted the same line twice to the same code, the validation fails. Test in staging: Export your current GL chart from your accounting system. Create a test invoice with each of your top 10 GL code