There are two ways to get an invoice into MyInvois. You can key it into the portal one at a time, or you can connect a system to the API and let it submit them. For anything past a low volume the portal stops being viable quickly, which makes the API the real question for most finance teams.
This is what it does, without the jargon.
What the API is for
LHDN runs the MyInvois platform, and the API is how a business system talks to it. Connecting to it buys three things:
- Efficiency — submission happens without anyone rekeying invoice data, which is both faster and less error-prone than the portal.
- Compliance — documents go in the expected format with the required fields, which is where most rejections come from.
- Transparency — real-time visibility of each document's status, rather than finding out at month end.
Authentication: taxpayer or intermediary
The first thing to settle, and the one that most often gets decided by accident.
Taxpayer authentication is for a business submitting its own invoices. The system sends a client ID and secret, MyInvois validates them and returns an access token that is stored securely and used for subsequent calls.
Intermediary authentication is for a service provider submitting on behalf of clients. The flow is similar, but the token is scoped to act for a specific taxpayer.
Which model you use shapes who holds credentials, who is accountable for a failed submission, and what happens if you change providers. It is worth deciding deliberately rather than inheriting whatever your first vendor set up.
Security
Transmission is encrypted, access is controlled so only authorised users can manage documents, and the platform is audited. Worth noting because tax identification numbers and full invoice detail are exactly the data a payment redirection attempt wants, and an integration that is casual about credential storage undoes the platform's protections at your end.
Documents, notifications and errors
Beyond submission, the API handles the lifecycle: retrieving a document's status, receiving notifications as validation completes, and returning errors when something fails.
Error handling is the part that decides whether this works in practice. A submission can fail for reasons that have nothing to do with your code — a supplier identifier that was never captured, a classification code that was never mapped, a buyer record that lives in a CRM rather than the finance system. What matters is whether someone finds out in time to fix it.
An integration that submits and never reports back looks like it is working right up until reconciliation. Ask, of any implementation: when a document is rejected, who is told, how quickly, and in language that says what to do about it?
Portal or API
Not really a technology decision. Volume decides it, and so does whether your invoice data already lives somewhere structured. A business issuing a handful of invoices a month has no integration problem. A business issuing thousands, from an ERP that was never asked for LHDN's field set, has a master data problem wearing an integration costume.
That distinction is worth making before anyone scopes a project, because the two need very different amounts of work and only one of them is mostly about the API.
Malaysia's current requirements → · Integrating SAP → · Our access point →