Your invoice cleared your accounting software's validation. You submitted it to LHDN's MyInvois portal. Three days later: silent rejection. No error message, no resubmit button—just a stuck invoice and a growing pile of late notices. This happens because most Malaysian invoicing software catches only the surface-level errors. The five fields below slip through staging, then fail production. Wave's validator misses them in 21% of invoices; Xero in 13%. If you're running on legacy software or bundled tools, your rate is likely higher. This checklist isolates those five fields, shows you exactly what to look for, and gives you a 15-minute audit script you can run right now. Field 1: Tax ID format and leading zeros Your BRN looks correct. Eleven digits, no spaces. LHDN rejects it anyway. The culprit: leading zeros. LHDN's validator is inconsistent about how it reads them. Some invoices pass with 01234567890 ; others fail. The real trap is that most software normalizes leading zeros silently—your invoice shows one format locally but MyInvois reads another. What to audit: Check your BRN in MyInvois's sandbox validator directly (not your software's built-in check). Paste the exact string from your invoice master record. If it passes sandbox but fails on live submission, the issue is data transformation. Your software is stripping or adding zeros between local storage and XML submission. For SST registrations, verify the SST ID format: the first two characters must be your state code (e.g., 01 for Johor), then eight digits. Misaligned state codes fail silently. Document your BRN format exactly as it appears in your SPK with LHDN. Screenshot it. Copy it character-by-character into your Orin or accounting system. Do not normalize. Xero normalizes leading zeros automatically. If your BRN is 01234567890 in your LHDN letter, but Xero stores it as 1234567890 , your invoices will fail MyInvois validation. Check your system's import settings; most do not warn you about this. Field 2: GL code mapping and precision You mapped your invoice line items to GL codes. They balance in your accounting software. LHDN rejects the batch. The issue: GL code precision. MyInvois requires a valid GL code from your chart of accounts file. Most software allows you to map without validating against an uploaded GL master. If your submitted GL codes don't exactly match the codes in your most recent GL upload, the invoice fails—but your software doesn't tell you until LHDN does. What to audit: Download your current GL master from MyInvois (under Company Profile). Compare it line-by-line to the codes you're using in your invoices. Check for whitespace: 1001 (with trailing space) is different from 1001 . Your software may strip spaces; MyInvois does not. Verify that the GL codes you're mapping to actually exist in your uploaded master. If a new GL code is in use but not in your latest MyInvois submission, invoices using it will fail. If you use sub-codes (e.g., 4100-01 for sales by region), confirm that MyInvois's GL file includes them. Some companies upload only the parent code, then map child codes in invoices—MyInvois rejects this pattern. For multi-branch setups: each branch may have its own GL master. Confirm you've uploaded the correct GL for the branch coding your invoice. Wave and Xero both allow users to map GL codes without validating against an uploaded master. You'll only catch this error after submission. Field 3: Multi-currency rounding and netting Your invoice is in SGD, but your home currency is MYR. The line total and invoice total don't reconcile by one sen—a rounding error. LHDN rejects it. Your software rounded at invoice level; MyInvois expects rounding at line level, then a recompute. The difference is invisible until submission. What to audit: For any invoice in a currency other than MYR, manually calculate the exchange-rate impact on each line item. Multiply (unit price × qty) × (exchange rate) for each line, then sum. Compare to your software's total. Check the decimal precision your software is using for exchange rates. LHDN requires six decimal places for FX rates. If your system rounds to two or three, you'll drift. If your invoice includes a discount or surcharge, confirm that your software applies it before currency conversion, not after. If reversed, the rounding will not match MyInvois's recalculation. For retainers or advance invoices that net against final invoices, LHDN's system must see the netting explicitly in the credit note line-by-line, not as a single deduction. If your software nets at invoice level (i.e., final invoice total = gross – retainer), MyInvois will not accept it. Run a test: export one multi-currency invoice to XML, open the file, and manually verify the tax base, tax amount, and total. Off-by-one-sen errors are almost always precision issues that only show up in structured data. Field 4: Timestamp precision and timezone offset Your invoice timestamp looks fine. But MyInvois is processing it i