LHDN's MyInvois and Your Website: What a Practical Integration Has to Do

Start with who is actually asking

MyInvois is not a website feature you can bolt on. It is a tax administration system run by Lembaga Hasil Dalam Negeri (LHDN), Malaysia's Inland Revenue Board — also referred to as IRBM. Every transaction a business makes that falls under Malaysia's e-Invoice mandate needs to be reported to LHDN, validated by them, and returned with a unique identifier and a QR code before it counts as a valid tax invoice. Whether or not a website is involved, the obligation sits with the business, not the site. What a website integration has to do is get the business's sales data into that reporting flow correctly and on time — nothing more, nothing less.

This is worth stating plainly because a lot of confusion around "e-Invoicing for websites" comes from treating it as a design or checkout problem, when it is actually an accounting and compliance problem that happens to need a technical connection into whatever platform runs the store.

Where things stand, as of 31 August 2026

The rollout has happened in phases based on annual turnover, and — importantly for anyone reading older articles about this — the phase boundaries and exemption threshold have been revised more than once since the mandate was first announced. As of LHDN's own implementation timeline page (last updated 30 August 2026), the phases are:

• Phase 1 — businesses with annual turnover above RM100 million: effective 1 August 2024
• Phase 2 — annual turnover above RM25 million up to RM100 million: effective 1 January 2025
• Phase 3 — annual turnover above RM5 million up to RM25 million: effective 1 July 2025
• Phase 4 — annual turnover up to RM5 million: effective 1 January 2026

The same page states that taxpayers with annual turnover or revenue below RM3,000,000 are exempted from the e-Invoice implementation entirely. Given how often these thresholds have moved, treat this as a snapshot rather than a permanent fact, and check LHDN's own timeline page directly for the current position before making a decision based on it: hasil.gov.my — e-Invoice Implementation Timeline.

If your business is close to any of these thresholds, or your turnover has moved between bands recently, it's worth confirming your own phase directly with LHDN or your tax adviser rather than relying on a threshold you read somewhere else — including this article, several months from now.

The MyInvois Portal versus API integration — two different technical asks

LHDN provides two distinct ways to submit e-Invoices, and they lead to very different amounts of development work.

The MyInvois Portal is a web-based system provided directly by IRBM. A business (or its staff) logs in and creates e-Invoices manually, one at a time or via a bulk upload template. It requires no integration work at all — no code, no connection to your website or accounting system — but it means someone is manually re-entering or uploading transaction data, which doesn't scale well once order volume increases.

API integration connects a business's own system — an ERP, an accounting platform, or in this context, a website's order/checkout system — directly to MyInvois, so that e-Invoices are generated and submitted automatically as transactions happen, without manual re-entry. This is the option that actually qualifies as a "website integration": your site (or the platform behind it) needs to construct a compliant invoice record and submit it to LHDN's system through their published interface, then handle whatever response comes back — success, rejection, or a request for correction — as part of the order flow.

Which one is right for a given business depends entirely on transaction volume and existing systems, not on which sounds more "proper." A low-volume service business with a handful of invoices a month may be genuinely well served by the manual Portal. A WooCommerce store processing dozens of orders a day is not — the integration work pays for itself quickly in staff time saved.

What a website integration actually has to do

At a practical level, the API path means the site (or the platform sitting behind it) needs to be able to:

1. Capture the data an e-Invoice requires — buyer and seller details, itemised line items, tax treatment, and the other fields LHDN's e-Invoice Guideline specifies — at the point of sale, not reconstructed afterwards.
2. Submit that data to LHDN's system in the format their current guideline requires, and handle the validation response, which LHDN's own documentation indicates is typically returned quickly.
3. Store and expose the validated result — the unique identifier and QR code LHDN issues back — against the order, so it can be shown to the customer or attached to a receipt.
4. Handle rejections and cancellations correctly. IRBM's guidelines describe a limited window after submission during which an e-Invoice can still be rejected or cancelled; after that, correction has to happen through a separate mechanism (such as a credit note), not by editing the original record.
5. Decide how to handle consumer sales where the buyer doesn't need an individual invoice. LHDN's e-Invoice Specific Guideline permits suppliers to summarise these into a single consolidated e-Invoice covering a period, submitted afterwards, rather than issuing one per transaction — with specific categories of transaction excluded from consolidation under the guideline. Whether this applies to a given store, and which of its transactions qualify, is a business and accounting decision that should be confirmed against the current guideline (or with a tax adviser) before being built into the checkout flow, not assumed from a general description like this one.

None of this is exotic engineering, but all of it depends on the current version of LHDN's guideline, which has already been revised multiple times (the e-Invoice Guideline and e-Invoice Specific Guideline were both at version 4.x as of mid-2026). A website integration built against an old version of the spec, or against a threshold that has since moved, is a compliance risk sitting quietly in the codebase. This is exactly the kind of detail that should be pulled from LHDN's current published guideline at build time, not from a description written months earlier — including this one.

What we're not going to guess at

We're deliberately not listing the full technical field-by-field specification here, or asserting exact figures for things like the value threshold above which a transaction can't be included in a consolidated e-Invoice — that level of detail changes with guideline revisions, and getting it wrong in an article is exactly the kind of error this piece is trying to avoid making. For the authoritative, current version of any of these details, go to LHDN's e-Invoice guidelines directly: hasil.gov.my/en/e-invoice.

If you want a second opinion

If you're trying to work out where your business sits in the current phase schedule, whether your website's order data is structured in a way that could feed an API integration, or whether the Portal is genuinely sufficient for your volume, JagaWeb's Essential System Review (RM1,500, reduced to RM999 until 16 September 2026, excluding SST) is a fixed-scope technical review that can look at what your current site actually captures at checkout. It's one option among several ways to get an outside, practical read on this before committing to a build — not a substitute for advice from your tax adviser on which obligations actually apply to your business.

This is general information about how e-Invoicing affects a website, not tax advice. LHDN revises its guidelines periodically — confirm your own obligations against the current guideline on hasil.gov.my, or with your tax agent.