Your systems already hold the invoice. MyInvois needs it in a shape they don't speak

Most businesses we talk to have already worked out whether e-Invoicing applies to them. What they have not worked out is why it is taking three people a week to do something the tax office describes in one sentence.

Where you sit in the timeline

LHDN rolled this out in four phases by annual turnover. The last one has passed:

• More than RM100 million: 1 August 2024
• RM25 million to RM100 million: 1 January 2025
• RM5 million to RM25 million: 1 July 2025
• Up to RM5 million: 1 January 2026

Businesses with annual turnover below RM3 million are exempt. That leaves a real band, RM3 million to RM5 million, of companies who became mandatory at the start of this year and are the least likely to have an ERP that handles it.

The actual problem is shape, not submission

An e-Invoice is not a PDF with a new logo on it. LHDN wants a structured document submitted to MyInvois, validated, and returned before the invoice counts as issued. Submission is the easy half.

The hard half is that the invoice does not exist in one place in your business. A typical Malaysian SME we assess has the same transaction living in three systems at once:

• The POS or order system knows what was sold, at what price, to whom.
• The accounting system knows the tax treatment, the customer's registration details and the credit terms.
• A spreadsheet somewhere holds the part nobody automated: the delivery reference, the project code, the thing the customer actually asks about.

None of those three agrees on how a customer is identified. That is the work. Not the API call.

What usually happens instead

The common first response is to buy a portal licence and have someone key invoices into it by hand. It works, it is cheap on day one, and it scales linearly with headcount, which means it stops working in the same month your business has a good quarter.

The second response is to ask the accounting vendor for an add-on. That is often the right answer, and we will tell you so when it is. It stops being the right answer when the data the add-on needs is not in the accounting system to begin with.

What we look at first

Before anyone writes code, the questions worth answering are dull and specific:

• Which system is the single source of truth for a customer's identity, and what happens today when two systems disagree?
• How many invoices a month, and what is the largest batch you would ever need to submit at once?
• What is the correction path? Cancellations and credit notes are where integrations break, not the happy path.
• Who gets told when a submission is rejected, and how do they find out before the customer does?

The answers decide whether this is a fortnight of work or a quarter. We would rather tell you which one before you commit to either.