Key Fields Reference & Common Mistakes
Key Fields Quick Reference
The following table shows the most commonly required fields grouped by category, along with whether they are mandatory (M) or conditional (C — required only in certain circumstances).
| Field | Category | Required? | Notes |
|---|---|---|---|
| Seller TIN | Seller | M | Must match LHDN records exactly |
| Seller BRN (SSM) | Seller | M | Company registration number |
| SST Registration No. | Seller | C | Required if SST registered |
| MSIC Code | Seller | M | 5-digit activity code from DOSM |
| Buyer TIN | Buyer | M | For B2B; relaxed for B2C |
| Invoice Number | Invoice | M | Unique, sequential, non-reusable |
| Invoice Date | Invoice | M | Date of supply |
| Invoice Type Code | Invoice | M | 01=Invoice, 02=Credit Note, 03=Debit Note, 04=Refund |
| Currency Code | Invoice | M | ISO 4217 (MYR, USD, EUR…) |
| Exchange Rate | Invoice | C | Required for non-MYR invoices |
| Item Description | Line Item | M | Per line item |
| Item Classification | Line Item | M | UNSPSC or custom code |
| Unit Price | Line Item | M | Pre-tax |
| Tax Type Code per Line | Line Item | M | 01=SST, 02=Service Tax, E=Exempt |
| Tax Rate per Line | Line Item | M | As percentage |
| Tax Amount per Line | Line Item | M | Must equal unit price × qty × rate |
| Total Pre-Tax Amount | Totals | M | Sum of all line subtotals |
| Total Tax Amount | Totals | M | Sum of all per-line taxes |
| Invoice Total | Totals | M | Pre-tax + total tax |
| UIN | Validation | M | Issued by LHDN post-validation |
| QR Code | Validation | M | Generated by LHDN post-validation |
Most Common Invoice Rejection Causes
Based on implementation experience across Malaysian businesses, these are the most frequent reasons MyInvois validation fails:
- Seller name mismatch The company name on the invoice does not match the name registered in LHDN's TIN records. Even punctuation differences can cause rejection.
- Missing MSIC code The MSIC (Malaysia Standard Industrial Classification) code is mandatory but often overlooked in accounting software field mapping exercises.
- Incorrect TIN format TIN numbers must be in the exact format LHDN expects — typically 'C' prefix for companies, 'SG' for sole proprietors, etc.
- Line-item tax type errors Setting all items to the same tax code when they have different tax treatment (e.g., mixing SST-exempt and SST-taxable items on the same tax code).
- Tax calculation rounding Rounding per-line-item taxes to 2 decimal places then summing them may differ from the grand total tax calculation. LHDN expects exact arithmetic match.
- Duplicate invoice numbers Re-using a previous invoice number, or having a gap and restarting the sequence, will cause the submission to fail or create compliance issues.
- Currency-exchange rate missing Invoices in foreign currencies without an exchange rate to MYR will be rejected.
- Invalid classification codes Using a UNSPSC or item classification code that does not exist in the LHDN-approved code list.
Credit Notes and Debit Notes
Credit notes and debit notes issued to correct or adjust a previously validated e-invoice must also go through MyInvois. They must:
- Reference the original invoice's UIN
- Use the correct invoice type code (02 = Credit Note, 03 = Debit Note)
- Contain all the same mandatory fields as a standard invoice
- Be validated and stamped by LHDN before being shared with the buyer
Field Mapping — Why It Matters
Most businesses have existing invoice data — but the field names, formats, and data types in your current accounting software may not match what MyInvois expects. "Field mapping" is the process of connecting your existing data fields to the LHDN-required fields in the correct format.
For example:
- Your software may call it "Company Reg. No." but LHDN requires it formatted as a BRN in a specific pattern.
- Your "Tax %" field may just store a number, but LHDN needs a tax type code plus a rate value as separate fields.
- Your address might be stored as one long text field, but LHDN requires street, city, postcode, state, and country as separate structured fields.
Poor field mapping is the single biggest cause of persistent rejection failures after implementation. A proper field mapping exercise done before go-live saves significant time during and after implementation.