MyInvois Integration When You Already Have a POS or ERP — You Probably Do Not Need to Replace It

The most common thing we hear from SME owners working through the e-Invoice mandate is some version of: "So I have to change my whole system?"

Usually, no. If you already run a POS, an ERP or accounting software that holds your invoice data, the realistic path is to connect that system to LHDN’s MyInvois API rather than replace it. Replacing a working system is the expensive answer to a problem that is mostly about field mapping.

Here is what connecting an existing system actually involves, and where it tends to go wrong.

First: does the vendor already support it?

Before anyone builds anything, ask your software vendor one direct question — is MyInvois submission live in your product, in development, or not planned?

Three possible answers, three different projects:

• Live. You configure it, test it, and you are done. Do not pay anyone to build what you already own.
• In development. Get a date in writing, then decide whether you can wait for it. If the date is after your enforcement date, treat it as "not planned".
• Not planned. This is where an integration layer makes sense.

Plenty of POS and accounting products used by Malaysian SMEs fall into the third bucket, particularly older on-premises installations and anything customised years ago by a developer who has since moved on.

What an integration layer is

It is a small service that sits between your system and LHDN. It reads an invoice from your system — through an API, a database view, or a scheduled export if that is genuinely all that is available — maps it into the MyInvois document format, submits it, and records what came back.

That last part matters more than the rest, and we will come back to it.

The five things that have to be mapped

Every integration we have done comes down to the same short list.

1. 1Tax identification numbers. Every buyer record needs a TIN. Most existing customer databases do not have one for every customer, and this is the single most common blocker. It needs no software to fix — it needs someone chasing customers for a number — which is exactly why it should start before the technical work, not after.
2. 2Classification codes. Each line item needs the correct code. Getting these wrong is the most common cause of rejection, and the mapping has to be decided by someone who understands what you sell, not by whoever writes the integration.
3. 3MSIC code and business details. Validated by LHDN against SSM records, so they have to match what is registered rather than what is on your letterhead.
4. 4Document types. Invoices, credit notes, debit notes and refund notes are separate document types. If your system handles credit notes as negative invoices — many do — that needs translating.
5. 5Consolidated invoices. Retail and F&B counter receipts are handled differently from standard B2B invoices. If you run a shop or a restaurant, this is the part to get right first, because it covers most of your volume.

Rejections are the part people underestimate

When a submission fails, LHDN returns a rejection code and a reason. If that only lands in an API log, your staff will carry on invoicing as though everything is fine, and you will find out weeks later.

Any integration worth paying for has to answer: who sees a failed submission, where, and how soon? A named person, a screen they already look at, and the same day. We build a visible queue of failures with the reason attached, because a silent integration is worse than manual entry — with manual entry, at least someone notices.

POS and F&B: one extra consideration

If you run a café, a restaurant or a retail counter, your invoice volume is mostly small receipts. Two things follow.

First, consolidated invoicing is your main workflow, not an edge case. Second, submission cannot slow down your counter. Nobody is going to wait at the till while an API call retries. The integration has to queue and submit asynchronously, and reconcile afterwards — so a slow response from LHDN never becomes a queue of customers.

A sensible order of work

1. 1Confirm your phase and your dates against LHDN’s current guidance rather than assuming.
2. 2Ask your vendor the direct question above.
3. 3Clean your buyer data — TINs especially. Start this now; it does not depend on anything technical.
4. 4Map fields and classification codes with someone who knows your products.
5. 5Test in LHDN’s sandbox until validations, rejections and consolidated invoices all behave.
6. 6Run a live month while the relaxation period still covers you, and watch the rejection queue every day.

Where the dates stand

Phase 4 — annual turnover RM 1 million to RM 5 million — came into scope on 1 January 2026, with a 12-month relaxation period running through 31 December 2026 and penalties applying from 1 January 2027. Businesses below RM 1 million in annual turnover are currently exempt; the planned sub-RM 1 million phase was cancelled on 6 December 2025.

Thresholds and timelines are set by LHDN and can change. This reflects publicly available information as of September 2026 — confirm your own position at myinvois.hasil.gov.my or with LHDN before making decisions.

Getting a straight answer about your own setup

Take a free digital checkup → — tell us how you work today and we will tell you what would actually need to change, and roughly what it involves. No sales pressure. If you would rather just ask, message us on WhatsApp.