Nothing makes an e-Invoice project feel fragile faster than this message:

Rejected. Invalid. Submission failed.

For many Malaysian SMEs, that moment usually creates two wrong reactions at the same time:

IT says it is a finance data problem.
Finance says it is a system integration problem.

Usually, it is both.

Because most LHDN e-Invoice rejections do not happen because the business “forgot to submit.” They happen because the data being submitted fails one of three tests:

the structure is wrong,
the field value is wrong,
or the document logic is wrong.

Malaysia’s MyInvois environment validates documents through structured APIs and formal validation rules, and documents can move through statuses such as Submitted, Valid, Invalid, and Cancelled. The SDK FAQ also shows that supplier and buyer fields are checked against field-format rules, and recent SDK / sandbox updates have tightened format validation in several areas. (MyInvois SDK)

This guide explains the most common root causes of e-Invoice errors and how to prevent rejections before they start causing:

month-end delays,
note-document clean-up work,
broken audit trails,
and very annoying re-submission cycles.

We will focus on practical prevention for businesses using Shopify, Shopee, TikTok Shop, POS, ERP, and accounting integrations.

First: understand the three big categories of rejection

Most errors fall into one of these buckets.

1. Format and structure errors

The document payload itself is not compliant. This includes malformed JSON or XML, invalid UBL mapping, missing required fields, or incorrect document structure. The SDK explains that JSON / XML documents must follow strict formatting rules, including correct hashing, Base64 encoding, and valid UBL JSON value mapping. (MyInvois SDK)

2. Field validation errors

The document structure may be fine, but the contents of one or more fields fail validation. This includes bad TIN format, invalid email format, address length breaches, wrong postal code structure, or invalid code values. The SDK FAQ lists validation rules for supplier / buyer fields such as name length, email format, phone length, postal code rules, SST number format, and TTX number format. (MyInvois SDK)

3. Business logic errors

These are the most painful, because the data may look “reasonable” to humans, but the submission logic still fails. Examples include:

wrong original reference on a credit note,
duplicate submission,
buyer / supplier mismatch,
note document raised without proper link to the original invoice,
or operational timing errors that should have been handled through note documents instead of cancellation. The SDK FAQ explains duplicate detection exists, while the broader LHDN framework distinguishes document statuses and adjustment logic. (MyInvois SDK)

If your business only prepares for the first category, the second and third categories will still hurt you.

The most common root causes of rejection

1. TIN formatting errors

This is one of the biggest causes of avoidable failure.

The SDK FAQ gives very specific formatting rules:

individual TINs now use the IG prefix instead of old prefixes like OG or SG,
non-individual TINs have specific formatting expectations,
and non-individual TINs must end with zero in the required format. It also advises taxpayers to validate TIN using the MyTax portal or the Validate Taxpayer’s TIN API before submission. (MyInvois SDK)

Why it happens

Businesses often rely on:

old customer master data,
manually keyed tax IDs,
copied values from outdated invoices,
or channel data that was never cleaned.

How to prevent it

Before go-live:

clean all B2B customer TINs,
convert outdated individual TIN prefixes correctly,
validate high-volume customer TINs in advance,
and build TIN validation into your onboarding or invoice-preparation workflow. (MyInvois SDK)

This is a classic case where “we have the customer’s tax number” is not the same as “we have it in valid MyInvois format.”

2. Buyer and supplier field formatting issues

Many businesses underestimate how often simple field rules cause rejection.

The SDK FAQ sets specific rules such as:

supplier / buyer name cannot exceed 300 characters,
email must follow valid format and can be left blank if unavailable,
phone number must be 8 to 20 characters with only an optional leading plus sign,
address lines have maximum lengths,
and Malaysian postal codes must be 5 digits. (MyInvois SDK)

Why it happens

These errors usually come from:

messy CRM exports,
long free-text addresses,
phone numbers with spaces or symbols,
or finance systems inheriting customer data from ecommerce checkout forms.

How to prevent it

Create a pre-submission data cleanse for:

phone,
email,
postal code,
address fields,
and buyer name length.

The easier approach is not waiting for rejection. The better approach is running field validation before the API call.

3. Invalid code values

MyInvois relies on code tables for many fields such as:

tax types,
classification codes,
currency codes,
state codes,
country codes,
payment modes,
and units of measurement. The SDK keeps these as official code lists, and the FAQ notes that tax exemption code handling was updated in the SDK. (MyInvois SDK)

Why it happens

Businesses often:

hardcode old values,
use internal abbreviations,
or assume that “close enough” text will pass.

It usually does not.

How to prevent it

Do not key these fields manually if you can avoid it.
Instead:

map your master data to the official code tables,
keep a controlled lookup list,
and review SDK release notes periodically because some field expectations and code handling do change. (MyInvois SDK)

4. Wrong JSON / XML structure

This is more technical, but still common.

The SDK explains that:

the document must be hashed with SHA-256 for documentHash,
the same document must be Base64 encoded for the document value,
and UBL JSON values need proper structure, including use of the _ key for attributes in UBL JSON. It also explains XML / JSON escaping rules for special characters. (MyInvois SDK)

Why it happens

This usually comes from:

custom middleware,
bad transformations,
incorrect sample adaptation,
or developers not following UBL JSON conventions closely enough.

How to prevent it

Use official sample payloads, test with sandbox, and validate:

field nesting,
hash generation,
Base64 encoding,
and character escaping.

This is one place where a technically “working” integration can still be invalid.

5. Duplicate document submission

The SDK FAQ confirms the system identifies duplicate e-Invoices by comparing certain fields together. (MyInvois SDK)

Why it happens

This usually occurs when:

the system retries blindly after timeout,
finance resubmits manually without checking status,
or middleware has poor idempotency control.

How to prevent it

You need:

one internal invoice code number per document,
controlled retry logic,
and a clear status-check process before resubmission.

Never solve uncertainty by “just submit again.” That is how duplicates become self-inflicted problems.

6. Poor original reference handling for credit notes, debit notes, and refund notes

This is one of the biggest business logic issues.

The SDK FAQ explains how to include multiple Original e-Invoice Reference Numbers in a single note document by adding separate InvoiceDocumentReference lines. That means the original invoice reference logic is a formal and required part of adjustment handling. (MyInvois SDK)

Why it happens

Businesses often store:

order ID,
refund ID,
or accounting journal ID,

but not:

the original validated invoice UUID.

Then later, when they need to issue a note document, they do not have the right reference chain.

How to prevent it

Your adjustment register should store at minimum:

original internal invoice code,
original validated UUID,
note-document type,
adjustment reason,
and adjustment date.

If you only keep the commercial order number, you are creating future rejection risk.

7. Wrong handling of cancellation versus adjustment

This is not only a compliance issue. It is also a rejection-risk issue because businesses may try to handle old changes the wrong way.

LHDN’s framework distinguishes document statuses such as Valid, Invalid, and Cancelled, and the broader e-Invoice guidance separates cancellation workflow from post-validation adjustment workflow. The public guidance on e-Invoice emphasises structured lifecycle management rather than informal correction. (MyInvois SDK)

Why it happens

Teams often say:

“just cancel and reissue”
when in fact the transaction should be handled by a credit note or refund note because the original document is already established and the issue arose later.

How to prevent it

Define one clear internal rule:

when cancellation is used,
when note documents are required,
and who decides.

Even without memorising every scenario, your team must know that not every later change is a cancellation case.

8. Master data not aligned across channels

This is especially common in omnichannel businesses.

Shopify, Shopee, TikTok, POS, and ERP may all store the same real-world transaction in slightly different ways:

buyer name format differs,
product code differs,
tax treatment differs,
shipping logic differs,
and internal invoice numbering may not be tied cleanly to source transaction IDs.

Why it happens

The business grew faster than the master data design.

How to prevent it

Build a mapping layer for:

customer master,
product / service master,
tax code,
invoice code,
and channel identifier.

This is the difference between “integration” and “control.”

9. File size and batching issues

The SDK FAQ notes a 300KB submission limit for XML documents and advises minification where needed. It also recommends batch submission and warns about rate limiting on Submit Documents, while login tokens remain valid for 60 minutes and should not be regenerated for every operation. (MyInvois SDK)

Why it happens

Large invoices, too many lines, heavy payloads, or poor batching strategies can trigger technical submission issues even when the data itself is correct.

How to prevent it

Plan for:

document minification where needed,
smart batching,
token reuse,
and rate-limit-aware retry logic. (MyInvois SDK)

This is especially important for high-volume retail or consolidated flows.

10. Authentication and environment mistakes

The SDK FAQ also notes:

production and sandbox require different credentials,
401 Unauthorized usually means expired token,
and 429 Too Many Requests means the API rate limit has been exceeded. (MyInvois SDK)

Why it happens

Teams often:

mix sandbox and production credentials,
refresh tokens too aggressively,
or build poor retry handling.

How to prevent it

Document and separate:

sandbox credentials,
production credentials,
token refresh logic,
and retry handling.

Not every rejection is a tax problem. Some are just poor integration discipline.

A practical prevention model that works

1. Validate before submission, not after rejection

Your system should perform a local pre-check for:

TIN format,
mandatory fields,
code values,
lengths,
email and phone format,
and duplicate prevention.

The SDK FAQ gives enough field-level rules to build many of these checks in advance. (MyInvois SDK)

2. Keep one master mapping table

At minimum, keep controlled mappings for:

customer fields,
product / classification fields,
tax type,
payment mode,
unit of measure,
and channel-to-entity logic.

This reduces repeat errors dramatically.

3. Store the validated UUID early

Once a document becomes valid, store:

internal invoice code number,
validated UUID,
validation timestamp,
and channel reference.

This is essential for later note-document control.

4. Separate technical errors from business logic errors

Do not let everything become “system failed.”

Track rejection causes by category:

formatting,
field validation,
duplicate,
business rule,
authentication / API.

This lets finance and IT fix the right layer.

5. Review SDK changes periodically

The SDK release notes and FAQ matter because field handling and validation expectations evolve. Recent updates have included field-format enforcement changes and tax-type clarifications. (MyInvois SDK)

This is not a one-time setup forever.

A simple rejection dashboard finance should ask for

A useful internal dashboard should show:

total submitted
valid
invalid
top 10 rejection reasons
rejection rate by channel
rejection rate by entity
average time to correction
number of note documents delayed due to missing original reference

This turns rejections from a hidden technical problem into a visible control metric.

Final thoughts

Most LHDN e-Invoice rejections are preventable.

They usually come from:

bad field formatting,
poor master data,
wrong code values,
duplicate handling issues,
weak original-reference logic,
or confusion between technical submission and business reality.

The good news is that prevention is usually much cheaper than correction.

If your business focuses on:

pre-validation,
master data cleanup,
proper UUID storage,
clean note-document logic,
and disciplined API handling,

then rejections drop sharply.

Because the best way to handle LHDN e-Invoice errors is not getting very good at fixing them.

It is building a process that stops most of them from happening in the first place.