BOOTINGJRV//SYSTEMS/
You're already in scope. Is your system?
MyInvois is LHDN's e-invoicing platform: every invoice has to be submitted to the tax authority in a structured format and validated before it counts. We build the system that produces and submits those documents from your existing data.
LHDN's last rollout band went live on 1 January 2026. If your turnover clears RM1 million you are mandated today, not next year, and the question is no longer whether to prepare but whether what you're issuing actually validates. We build the invoicing side: documents that carry the fields LHDN requires, a submission path into MyInvois, and a ledger underneath that still balances when the tax engine changes.
The phase-in finished. Above RM100 million came in on 1 August 2024, RM25–100 million on 1 January 2025, RM5–25 million on 1 July 2025, and everyone up to RM5 million on 1 January 2026. Businesses under RM1 million turnover are exempt. Every other band is mandated now, which means the interesting question is no longer when, it is whether what you are issuing actually validates.
The common state we find is a business that is compliant in principle and manual in practice. Invoices are produced in the accounting package as before, then someone retypes them into the MyInvois portal. It works at ten invoices a month. At two hundred it produces exactly what you would expect: transposed figures, missing buyer TINs, and a growing set of invoices that were issued and never submitted.
That gap is the real exposure. Not the penalty schedule — your tax agent handles that — but the fact that nobody can currently say how large the gap is. An invoice booked in your ledger that LHDN has no record of is invisible until someone goes looking, and the first person who goes looking is usually not you.
Which entity, which band, what is being issued today and in what form. We reconcile what you have booked against what LHDN has validated, so the gap becomes a number on a screen rather than an unknown.
Most failures happen before submission. Buyer TIN, SST registration and classification codes have to be captured when the customer is created and the line is entered, not chased at month end. This is the unglamorous step that determines whether the rest works.
UBL 2.1 invoices, credit notes and debit notes generated from your existing data. Built against LHDN's own SDK specification, not against an assumption about it.
API submission with retry, status tracking and the validation reference stored against the invoice. When something is rejected you see which invoice, which field, and why — a queue you can work, not a portal error you have to interpret.
The QR-coded validated PDF goes to your buyer as the copy they keep, and the validation reference sits in your ledger against the same document.
Bulk submission of invoices already issued, reconciled against what LHDN accepts, so the historical position is closed rather than carried forward.
Quoted from what already exists. A bridge onto working accounting software is a much smaller project than replacing it, and we scope it that way.
Read what your accounting package already holds, add the fields LHDN requires, submit, and write the validation result back. No replacement.
Full ledger with e-invoicing native to it — issue, submit, validate and account for a document in one system rather than three.
Bulk submission of the existing backlog and a reconciliation of booked against validated, delivered as a report you can act on.
