Common MyInvois Rejection Errors and How to Fix Them

Why e-invoices get rejected

When you submit an e-invoice to MyInvois, LHDN's system runs each document through a series of validation checks before accepting it. Validation is document by document, so a submission can be partially valid, with individual documents receiving different outcomes. The Submit Documents response (HTTP 202) is only the first step: its acceptedDocuments have been accepted for further processing, not finally validated, and its rejectedDocuments are refused there and then with an error. The final result comes afterwards from Get Submission, which reports the overall status as in progress, valid, partially valid or invalid, with each document marked Submitted, Valid, Invalid or Cancelled. A document accepted at the first step can still end up Invalid. A rejected document comes with an error code and a message explaining what went wrong. Only problems with the request as a whole, such as a malformed or oversized request or a DuplicateSubmission, refuse everything at once.

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 typically begin with C followed by digits (e.g., C12345678090) and individual TINs with IG (e.g., IG12345678090). Other taxpayer types use other prefixes, so confirm the exact value with the taxpayer
• Cross-check with the buyer directly — ask them to confirm their TIN as registered with LHDN
• Supply the identifiers that match the buyer's category, as set out in section 4.2.8 and Appendix 1 of HASiL's e-Invoice Specific Guideline:
  • Malaysian business: the buyer's TIN and business registration number (BRN)
  • Foreign business: the buyer's TIN and BRN where available. EI00000000020 is only a fallback for when the foreign buyer's TIN is not available or not provided (for example on an export); if the BRN is not available, NA
  • Malaysian individual (MyKad / MyTentera) or MyPR / MyKAS holder: the TIN, or the identification number, or both. The general public TIN EI00000000010 is for an individual who provides only that identification number (it is also the buyer TIN on consolidated e-invoices)
  • Other non-Malaysian individual: the TIN, or the TIN with the passport number. Only if the individual has no TIN and provides just a passport number does Appendix 1 call for EI00000000020, together with the passport number
  • Government bodies and certain public institutions: Appendix 1 lists a separate general TIN, EI00000000040, as the buyer's TIN for government, state and local authorities, statutory bodies and exempt institutions that are not assigned a TIN
• A general TIN is not a substitute for a Malaysian business buyer's own TIN
• 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 business party do not correspond to the same registered entity. (Individuals are identified by MyKad / MyTentera, MyPR / MyKAS or passport number rather than a BRN.)

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
• Give the buyer's name as it is registered: the business name, or for an individual the full name as per MyKad / MyTentera, or passport / MyPR / MyKAS for non-Malaysians

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

Pre-submission check: Confirm that line-item amounts, subtotals and tax calculations are consistent. LHDN's published validation rules do not identify a separate arithmetic error code for this example.

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 amount for 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
• Keep each amount consistent with the field format the SDK defines for it (monetary amounts are xsd:decimal); showing two decimal places is the usual convention
• As a practice, carry full precision through intermediate calculations and round only the amounts shown on the document, so the figures still reconcile. This is recommended accounting practice, not a published SDK rule

Example of a calculation that does not reconcile:

The line amount should be RM 99.99 (3 x 33.33). Submitting RM 100.00 leaves the document inconsistent with its own quantity and unit price. 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 kind of inconsistency.

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 the documented xsd:time format (for example 15:30:00Z), or not the current time
• The issuance date is not the current date in UTC — easy to get wrong between midnight and 8 a.m. Malaysia time, when the UTC date is still the previous day
• Billing period end date is before the start date
• Invalid dates like February 30 or month 13

How to fix it:

• Date format must be: 2026-02-05 (not 05/02/2026 or Feb 5, 2026), and it must be the current date in the UTC timezone
• Time is an xsd:time value and must be the current time. LHDN's e-invoice specification gives 15:30:00Z as the example, where Z marks UTC, and states that the date must be the current date in the UTC timezone
• Ensure billing period start date is before or equal to end 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 required fields are empty or missing from the submission. Note that of LHDN's 55 listed data fields, 20 are optional and eight are conditional — so "missing field" means missing a field that is required for this document, not missing one of 55.

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:

Payment mode is optional in the SDK's invoice specification (cardinality [0-1]), so leaving it empty is not by itself a missing mandatory field. Include it when you have it.

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 document

Error: The document is flagged as a duplicate of one already submitted (error DV302).

What triggers it: according to LHDN's duplicate-document validation rules, a document is treated as a duplicate only when all of these match an earlier one: the e-invoice type and version, the issuance date and time, the invoice number, and the supplier's TIN (the buyer's TIN for self-billed documents), compared against documents the system has already processed within a 2-hour period. Separately, the submission API returns DuplicateSubmission when an identical submission arrives from the same taxpayer within 10 minutes.

What causes it:

• Resubmitting a document that was already accepted — typically a retry after a timeout, or a manual resubmission when you were not sure the first one went through
• A system submitting the same document twice from the same data

How to fix it:

• Check whether the first submission was actually accepted before sending it again
• If you need to correct a document that was already validated, cancel it within 72 hours or issue a credit/debit note — do not resubmit the same document

Prevention: Record each submission's status against your own invoice before retrying. Keeping invoice numbers unique — a sequential series with a year prefix, such as 2026-INV-0001 — is still good practice for your own records and reconciliation.

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:

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., MYS for Malaysia, SGP for Singapore)
• Every Malaysian address must include a valid state code

9. Currency and tax mismatch

Error: The Currency Exchange Rate element is missing from a document whose invoice currency is not MYR (MyInvois rejects it since 1 September 2025), or the tax currency code or the currency of the amounts does not meet the validation rules.

What causes it:

• Submitting a USD invoice without the Currency Exchange Rate element (input 0.00 where no rate applies)
• Providing a tax currency code that is neither the document currency nor MYR (validation rule DC512)
• Tax amounts in a currency different from the tax currency code you provided (DC501), or other amounts not in the document currency (DC502)

How to fix it:

• Where the rate is needed, include the cac:TaxExchangeRate element with cbc:SourceCurrencyCode (the document currency), cbc:TargetCurrencyCode (MYR) and cbc:CalculationRate
• The tax currency code is optional. If you provide it, it can only be the document currency or MYR; use MYR if you report tax in MYR
• Make every tax amount use the tax currency code you provided, and the other monetary amounts the document 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, debit or refund notes missing the reference to the original document, where it applies
• Using an unrecognized document type code

Document type codes:

How to fix it:

• Ensure the document type code matches what you are actually submitting
• Credit, debit and refund notes reference the document they adjust. The SDK maps this to cac:BillingReference/cac:InvoiceDocumentReference, with the original's unique identifier number in cbc:UUID and its internal ID in cbc:ID (mandatory where applicable)
• Self-billed documents use codes 11–14, not 01–04 — see self-billed e-invoices in Malaysia
• The Original e-Invoice Reference Number takes LHDN's IRBM Unique Identifier Number for the document being adjusted, not your own invoice number — see credit notes and debit notes in MyInvois

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. The standard error response can include:

• errorCode — the code your system should handle
• propertyName and propertyPath — which field has the problem
• error (English) and errorMS (Malay) — a message describing the issue
• innerError — nested errors, so several problems can be fixed in one pass

An error whose propertyPath points at the supplier's TIN and whose message describes a format problem 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:

1. Start with line items: quantity x unit price
2. Sum line items to get subtotal
3. Calculate tax on the subtotal
4. Add subtotal + tax + rounding = payable amount
5. Compare each calculated value with what was submitted

Step 4: Fix and resubmit

Correct the specific issue and resubmit. When you do, use the current issuance date and time (the date must be the current date in UTC) and stay within the MyInvois API rate limits.

Reducing rejection rates

The businesses with the lowest rejection rates share common practices:

1. Pre-validate before submitting — check the document against LHDN's field requirements before sending it to MyInvois. Catch errors locally instead of waiting for LHDN to tell you.
2. Automate calculations — Never calculate line totals, tax, or grand totals manually. Let software do the math.
3. Maintain clean master data — Keep an up-to-date database of customer TINs, BRNs, and addresses. Verify once, reuse reliably.
4. Use templates — Pre-configure your common invoice types with correct MSIC codes, tax types, and classification codes.
5. Test with sandbox first — LHDN provides a sandbox environment for testing. Use it to validate your invoice format before submitting production documents.