Two routes exist, and the choice between them is more consequential than it first appears.
Route one: the MyInvois portal
You log in and enter the invoice. LHDN validates it, and a validated document comes back carrying a QR code. No integration, no project, nothing to build.
It works, and it stops working at volume. Every invoice is someone's manual task, and every manual task is a rekeying error waiting to be reconciled later. For a business issuing a handful of documents a month, that is a fair trade. For one issuing thousands, it is a headcount problem disguised as a compliance solution.
Route two: the API
Your system submits directly, gets validation results back, and nobody retypes anything. That is the destination for most businesses of any size — and it is a project, with the usual project questions about who builds it and who runs it afterwards.
How the API works, in plain language →
Readiness is a data question
Whichever route you take, the document has to carry a substantial field set: seller and buyer detail, line items, quantities, prices, taxes, totals, payment information.
This is where implementations actually stall. Not the connection — the connection is well-documented and largely solved. What stalls them is discovering that:
- Supplier tax identifiers were never captured, because nothing previously needed them
- Classification codes were never mapped to anything
- Buyer details live in a CRM rather than the finance system
- The same customer exists three times under slightly different names
None of those are technology problems and all of them are on the critical path. A team that audits its master data before scoping the integration finishes sooner than one that discovers the state of it during testing.
What comes back
A validated invoice returns with a QR code, which is what makes it a valid document. Two things follow from that which are easy to miss.
First, validation is not instantaneous in the sense that matters operationally — you need a process for what happens to a document that is rejected, and it needs to run before the invoice is due rather than at reconciliation.
Second, if you are the buyer, the QR code is the thing that tells you the invoice you have received is real. That is a control most AP functions have not yet built, and the exposure runs the other way from the one everyone plans for. The same gap in Indonesia's clearance model →
The order to do this in
Audit the data, then choose the route, then build. Teams that reverse the first two steps buy an integration and then spend the project cleaning records to feed it — which is the same work, done later, under more pressure, with a licence already running.