Why e-invoices get rejected
When you submit an e-invoice to MyInvois, LHDN's system runs it through a series of validation checks before accepting it. If any check fails, the entire submission is rejected — you get an error code and a message explaining what went wrong.
Rejection is not a penalty. It simply means the e-invoice data did not pass validation and needs to be corrected and resubmitted. However, repeated rejections waste time, delay your billing, and can create confusion with customers who are waiting for validated invoices.
Understanding the most common errors — and how to prevent them — saves you from the frustrating cycle of submit, reject, fix, resubmit.
The most common rejection errors
1. Invalid or missing TIN
Error: Supplier or buyer TIN is invalid, not found, or does not match LHDN records.
What causes it:
- Typo in the TIN (wrong digit, missing character)
- Using an old or deactivated TIN
- The buyer's TIN has not been registered with LHDN
- Confusing TIN with BRN (they are different numbers)
How to fix it:
- Verify the TIN format: Company TINs follow the pattern
Cfollowed by digits (e.g.,C12345678090). Individual TINs start withIG(e.g.,IG12345678090) - Cross-check with the buyer directly — ask them to confirm their TIN as registered with LHDN
- For individual consumers without a TIN, use the general public TIN:
EI00000000010 - Do not use the BRN in the TIN field or vice versa
Prevention: Build a verified customer database. Once you confirm a client's TIN works, save it. Do not re-enter it manually each time.
2. TIN and BRN mismatch
Error: The TIN and BRN provided for a party do not correspond to the same registered entity.
What causes it:
- Copying the TIN from one company and the BRN from another
- Using a subsidiary's BRN with the parent company's TIN
- Transposing digits in either number
How to fix it:
- Confirm both the TIN and BRN belong to the same legal entity
- Ask the buyer: "Please provide your TIN and BRN exactly as registered with LHDN and SSM"
- Check the SSM eInfo portal to verify the BRN matches the company name
Prevention: When collecting client details, always collect TIN, BRN, and registered company name together. Verify they match before the first invoice.
3. Calculation mismatch errors
Error: Line item amounts do not sum to the stated subtotal, or tax calculations do not match the expected values.
What causes it:
- Manual rounding errors (rounding line items individually then summing, vs. summing then rounding)
- Tax amount calculated on the wrong base (e.g., calculating SST on the total including previous tax instead of the net amount)
- Discount applied incorrectly (subtracted from the wrong subtotal)
- Line item quantity times unit price does not equal the stated line amount
How to fix it:
- Verify that:
quantity x unit price = line item amountfor every line - Verify that:
sum of all line item amounts = subtotal - Verify that:
tax amount = subtotal x tax rate(for each tax type) - Verify that:
subtotal + total tax + rounding = payable amount - Use 2 decimal places for all monetary amounts
- Apply rounding only at the final total level, not per line item
Example of a calculation that fails:
| Line | Qty | Unit Price | Calculated | Submitted |
|---|---|---|---|---|
| 1 | 3 | RM 33.33 | RM 99.99 | RM 100.00 |
LHDN expects RM 99.99 (3 x 33.33). Submitting RM 100.00 triggers a mismatch. Always let the line amount be the exact product of quantity and unit price.
Prevention: Use software that calculates amounts automatically. Manual calculations are the primary source of this error.
4. Invalid date or time format
Error: The invoice date, time, or billing period is in an incorrect format or contains an invalid value.
What causes it:
- Using a date format other than ISO 8601 (
YYYY-MM-DD) - Time not in 24-hour format or missing timezone offset
- Billing period end date is before the start date
- Invoice date is in the future
- Invalid dates like February 30 or month 13
How to fix it:
- Date format must be:
2026-02-05(not05/02/2026orFeb 5, 2026) - Time format must be:
14:30:00+08:00(24-hour, with Malaysia timezone offset +08:00) - Ensure billing period start date is before or equal to end date
- Invoice date should be on or before the submission date
Prevention: Let your e-invoicing software handle date formatting. If entering manually, always use YYYY-MM-DD format.
5. Missing mandatory fields
Error: One or more of the 55 mandatory fields are empty or not included in the submission.
What causes it:
- Not filling in all required fields (easy to miss less obvious ones like MSIC code or state code)
- Leaving optional-looking fields blank that are actually mandatory
- Supplier or buyer address missing required components (city, state, postal code, country)
The fields most commonly left blank:
| Field | Why it is missed |
|---|---|
| Supplier MSIC code | Businesses do not know their classification code |
| Buyer address state code | Client did not provide their state |
| Supplier SST registration number | Assumed optional if not SST-registered |
| Invoice currency code | Assumed to default to MYR |
| Payment mode | Forgotten during manual entry |
| Product classification code | Not mapped for all line items |
How to fix it:
- Check every field against LHDN's 55-field requirement list
- For supplier SST: if not registered, use "NA" or the format specified by LHDN
- For state codes: use the official Malaysian state codes (e.g., "14" for Kuala Lumpur, "10" for Selangor)
- Every line item must have a classification code — look up the appropriate code in LHDN's product classification list
Prevention: Set up your business profile completely once, with all 14+ supplier fields pre-configured. This eliminates the most common source of missing fields.
6. Duplicate invoice number
Error: An e-invoice with this supplier invoice number has already been submitted and validated.
What causes it:
- Reusing an invoice number that was previously submitted
- Your numbering system reset (e.g., starting over at INV-001 for a new year without a year prefix)
- Resubmitting an invoice that was already accepted (perhaps you forgot it went through)
How to fix it:
- Use a unique invoice number. If the number already exists in MyInvois, you cannot reuse it
- If you need to correct a previously submitted invoice, cancel it within 72 hours or issue a credit/debit note — do not try to resubmit with the same number
Prevention: Use a sequential numbering system with a prefix that includes the year (e.g., 2026-INV-0001). Never reset your counter without changing the prefix.
7. Invalid classification codes
Error: The MSIC code or product classification code is not recognized by MyInvois.
What causes it:
- Using an outdated MSIC code that has been superseded
- Entering the code with wrong formatting (e.g., spaces or dashes in a 5-digit code)
- Using a product classification code that does not exist in LHDN's lookup table
How to fix it:
- Look up your MSIC code on the Department of Statistics Malaysia (DOSM) website
- Product classification codes must match LHDN's published list exactly
- Remove any spaces, dashes, or extra characters from the code
Prevention: Configure your MSIC code once in your business profile. For product classification, map your products/services to valid codes and store them in your product catalog.
8. Invalid state or country code
Error: The state code or country code in the supplier or buyer address is not valid.
What causes it:
- Using state names instead of codes (e.g., "Selangor" instead of "10")
- Using incorrect country codes (e.g., "MY" for a field that expects "MYS" or vice versa)
- Leaving the state code blank for a Malaysian address
Malaysian state codes reference:
| State | Code |
|---|---|
| Johor | 01 |
| Kedah | 02 |
| Kelantan | 03 |
| Melaka | 04 |
| Negeri Sembilan | 05 |
| Pahang | 06 |
| Pulau Pinang | 07 |
| Perak | 08 |
| Perlis | 09 |
| Selangor | 10 |
| Terengganu | 11 |
| Sabah | 12 |
| Sarawak | 13 |
| Kuala Lumpur | 14 |
| Labuan | 15 |
| Putrajaya | 16 |
How to fix it:
- Use the numeric code from the table above for Malaysian addresses
- Use ISO 3166-1 alpha-3 for country codes (e.g.,
MYSfor Malaysia,SGPfor Singapore) - Every Malaysian address must include a valid state code
9. Currency and tax mismatch
Error: Tax amounts are not in MYR, or the currency exchange rate is missing for non-MYR invoices.
What causes it:
- Submitting a USD invoice without including the currency exchange rate fields
- Calculating tax in the document currency instead of MYR
- Missing the tax currency code field (must be MYR)
How to fix it:
- For any non-MYR invoice, include the
CurrencyExchangeRateelement with the conversion rate to MYR - Set the tax currency code to MYR
- Calculate all tax amounts in MYR, not in the invoice currency
Prevention: If you invoice in foreign currencies, refer to the detailed multi-currency invoicing guide for the full field requirements.
10. Document type code errors
Error: The document type code does not match the document content, or an invalid code is used.
What causes it:
- Using code 01 (invoice) for a credit note, or 02 (credit note) for a regular invoice
- Credit or debit notes missing the required reference to the original invoice
- Using an unrecognized document type code
Document type codes:
| Code | Document Type |
|---|---|
| 01 | Invoice |
| 02 | Credit Note |
| 03 | Debit Note |
| 04 | Refund Note |
| 11 | Self-billed Invoice |
| 12 | Self-billed Credit Note |
| 13 | Self-billed Debit Note |
| 14 | Self-billed Refund Note |
How to fix it:
- Ensure the document type code matches what you are actually submitting
- Credit notes (02) and debit notes (03) must include the original invoice reference number and UUID
- Self-billed documents use codes 11-14, not 01-04
How to debug a rejected e-invoice
When LHDN rejects your submission, you receive an error response. Here is a systematic approach to debugging:
Step 1: Read the error message carefully
LHDN's error messages are structured. They typically include:
- An error code
- A property path (which field has the problem)
- A message describing the issue
For example: "propertyPath": "invoice/supplier/tin", "message": "Invalid TIN format" tells you exactly where to look.
Step 2: Check the specific field
Go to the field identified in the error and verify its value against LHDN's requirements. Is the format correct? Is the value valid? Is it the right field for what you are trying to express?
Step 3: Validate calculations
If the error involves amounts, recalculate from scratch:
- Start with line items: quantity x unit price
- Sum line items to get subtotal
- Calculate tax on the subtotal
- Add subtotal + tax + rounding = payable amount
- Compare each calculated value with what was submitted
Step 4: Fix and resubmit
Correct the specific issue and resubmit. There is no penalty for resubmission — LHDN expects that some submissions will need correction. You can resubmit as many times as needed until the e-invoice passes validation.
Reducing rejection rates
The businesses with the lowest rejection rates share common practices:
- Pre-validate before submitting — Check all 55 fields against LHDN's rules before sending to MyInvois. Catch errors locally instead of waiting for LHDN to tell you.
- Automate calculations — Never calculate line totals, tax, or grand totals manually. Let software do the math.
- Maintain clean master data — Keep an up-to-date database of customer TINs, BRNs, and addresses. Verify once, reuse reliably.
- Use templates — Pre-configure your common invoice types with correct MSIC codes, tax types, and classification codes.
- Test with sandbox first — LHDN provides a sandbox environment for testing. Use it to validate your invoice format before submitting production documents.
