How to Comply with MyInvois in Malaysia: Onboard with LHDN and Issue Your First UUID-Stamped Invoice (2026)

To comply with MyInvois in Malaysia, an in-scope taxpayer must register on the LHDN MyInvois portal at einvoice.hasil.gov.my, provision an LHDN-onboarded digital certificate bound to its TIN, build a UBL 2.1 (XML) or JSON payload in the MyInvois profile with seller and buyer TINs plus the 8% SST breakdown, submit it to the MyInvois API to receive a UUID and embedded QR, then render the UUID and QR on the buyer PDF — observing the 72-hour rejection window before the cleared invoice becomes final.

Where MyInvois sits in the global e-invoicing landscape

MyInvois is a clearance-model continuous transaction control regime — the same architectural family as ZATCA Phase 2 in Saudi Arabia, GST IRN in India, and NRS / FIRS MBS in Nigeria.

MyInvois is a clearance-model continuous transaction control regime — the same architectural family as ZATCA Phase 2 in Saudi Arabia, GST IRN in India, and NRS / FIRS MBS in Nigeria. The seller submits a structured payload, the regulator validates it, and the invoice only becomes legally valid once an LHDN UUID is returned. The distinguishing trait of MyInvois is the post-clearance 72-hour rejection window — no other major mandate gives buyer and seller a defined cancellation slot after clearance.

If you operate across ASEAN, you are now juggling MyInvois, the Philippines BIR CAS, Vietnam's GDT system, and (from 2030) the EU ViDA Digital Reporting Requirements. The architectures rhyme, but the artefacts diverge. Build a single canonical invoice in your platform and let the integration layer emit the per-jurisdiction payload — MyInvois UBL 2.1 here, INV-01 JSON for India, UBL with TLV QR for ZATCA.

What you need before you start

An active SSM business registration with a Tax Identification Number (TIN) issued by LHDN.

• An active SSM business registration with a Tax Identification Number (TIN) issued by LHDN.
• Confirmation that your business is in the current LHDN rollout wave — Phase 1 (turnover > RM100m) live since 1 Aug 2024, Phase 2 (RM25m–RM100m) live since 1 Jan 2025, Phase 3 (RM5m–RM25m) live from 1 Jul 2025, Phase 4 (RM1m–RM5m) deferred by LHDN to 1 Jan 2026, Phase 5 (below RM1m) per the published LHDN timeline.
• SST registration if you supply taxable services; the SST registration number is mandatory on the payload for SST-registered sellers.
• An invoicing platform that can emit UBL 2.1 or JSON in the MyInvois profile and call the MyInvois API with a valid digital certificate.
• NTP-synchronised server clocks — the MyInvois API rejects payloads whose issue timestamp drifts beyond the tolerated window.

Step 1 — Register on the MyInvois portal

Who has to register — the taxpayer or the software vendor?

The taxpayer registers as the Taxpayer on the MyInvois Portal; the software vendor is not a substitute. The taxpayer-side registration binds the TIN to the MyInvois Portal so every payload submitted under that TIN is attributable.

The taxpayer registers as the Taxpayer on the MyInvois Portal; the software vendor is not a substitute. The taxpayer-side registration binds the TIN to the MyInvois Portal so every payload submitted under that TIN is attributable. Tax agents can be authorised as Representatives via the portal's role management, but the TIN ownership remains with the taxpayer.

What information do I need to register?

TIN, registered company name, SST registration number (if applicable), business address, the email used for portal correspondence, and the principal officer details. The portal then unlocks the API enrolment flow and the digital certificate request.

TIN, registered company name, SST registration number (if applicable), business address, the email used for portal correspondence, and the principal officer details. The portal then unlocks the API enrolment flow and the digital certificate request.

Step 2 — Provision your digital certificate

How is the certificate issued?

LHDN requires every submitted payload to be signed with a certificate issued by an LHDN-approved Certificate Authority (CA).

LHDN requires every submitted payload to be signed with a certificate issued by an LHDN-approved Certificate Authority (CA). Your invoicing platform generates a Certificate Signing Request (CSR) bound to your TIN; you submit the CSR to the chosen LHDN-listed CA (such as MSC Trustgate, Pos Digicert or Telekom Applied Business); the CA returns the X.509 certificate, which is then registered on the MyInvois Portal. The private key never leaves your tenant. Invoicemonk runs the CSR + CA + portal-registration sequence inside the product so you never handle key material.

Does each branch need its own certificate?

No. The MyInvois certificate is bound to the TIN, not to a device or branch.

No. The MyInvois certificate is bound to the TIN, not to a device or branch. A single certificate signs every outgoing payload. Large operators sometimes provision per-branch certificates for audit segregation, but it is not a regulatory requirement.

Step 3 — Map your invoice to the MyInvois schema

The MyInvois payload follows UBL 2. 1 (XML) or JSON in the LHDN profile.

The MyInvois payload follows UBL 2.1 (XML) or JSON in the LHDN profile. The mandatory blocks are:

• Header: document type code (Invoice, Credit Note, Debit Note, Refund Note, Self-billed Invoice), invoice number (seller-controlled), issue date and time (UTC + Kuala Lumpur offset), currency.
• Parties: seller TIN, seller name, seller SST registration number (where applicable); buyer TIN, buyer name, buyer SST registration number (B2B) or a generic identifier for B2C consolidated invoices.
• Line items: LHDN classification code, item description, quantity, unit price, line subtotal, applicable SST rate (8% for taxable services, 0% for SST-exempt or zero-rated).
• Tax summary: SST breakdown per rate, total taxable amount, total tax amount.
• Totals: total excluding tax, total including tax, payable amount.
• Payment terms and reference data: payment mode, due date, currency code, FX rate for foreign-currency invoices.
• Signature block: XAdES enveloped signature using the LHDN-onboarded certificate, computed over the canonicalised payload.

Step 4 — Submit to the MyInvois API and receive the UUID

Step 4 — Submit to the MyInvois API and receive the UUID includes: The platform builds the UBL 2. 1 or JSON payload.

1. The platform builds the UBL 2.1 or JSON payload.
2. The payload is canonicalised and signed with the LHDN certificate.
3. The signed payload is POSTed to the MyInvois API submission endpoint.
4. MyInvois validates schema, TINs, SST computation, and signature.
5. On success the API returns the LHDN-issued UUID, the validation date-time, and the embedded QR URL synchronously.
6. The platform persists the UUID, the validation receipt, and binds the UUID + QR to the buyer PDF.

Step 5 — Manage the 72-hour rejection window

After UUID issuance, both seller and buyer have a 72-hour window to cancel or reject the invoice via the MyInvois API or Portal.

After UUID issuance, both seller and buyer have a 72-hour window to cancel or reject the invoice via the MyInvois API or Portal. Within the window:

• Seller cancellation: the seller can cancel its own cleared invoice (e.g. wrong buyer, wrong line items) without issuing a credit note.
• Buyer rejection: the buyer can reject a cleared invoice — the seller must then re-issue or cancel.

After 72 hours the invoice is final — corrections must be made through a credit note that gets its own UUID and references the original. Surface the window timer in your dashboard or finance teams will miss it; Invoicemonk shows the countdown on the invoice timeline.

Step 6 — Present the UUID and QR on the buyer-facing invoice

Every buyer-facing invoice must display the LHDN UUID and the embedded QR.

Every buyer-facing invoice must display the LHDN UUID and the embedded QR. The QR resolves to LHDN's public verification endpoint that confirms the UUID, the seller, the buyer, the totals, and the validation date-time. The buyer's accounts payable system uses the QR to verify the invoice before posting; without it, the invoice is not legally valid for SST recovery and the buyer is likely to block payment.

Common validation errors and how to fix them

Common validation errors and how to fix them includes: TIN not found — seller or buyer TIN failed the LHDN registry lookup. Confirm the TIN format (10 digits for individuals, 12 for entities) and re-check the registration.

• TIN not found — seller or buyer TIN failed the LHDN registry lookup. Confirm the TIN format (10 digits for individuals, 12 for entities) and re-check the registration.
• SST registration mismatch — declared SST registration number does not match the LHDN SST registry for the TIN. Update the registration on the portal before resubmitting.
• Classification code invalid — line item carries a code outside the LHDN MyInvois classification list. Map to the closest valid code (the LHDN classification list is published as part of the SDK).
• Tax amount mismatch — line-level SST does not equal the applied rate × taxable amount. Recompute at the line level and resign.
• Signature failure — the XAdES signature does not validate against the certificate on file. Usually a canonicalisation drift; re-canonicalise (XML C14N for UBL) and resign.
• Duplicate invoice number — the seller invoice number was already submitted under the same TIN. Use a unique sequence per seller.
• Timestamp out of tolerance — issue date-time drifted from the MyInvois clock. Re-sync NTP and resubmit.

Pre-go-live compliance checklist

Pre-go-live compliance checklist includes: ☐ Taxpayer registered on the MyInvois Portal and TIN bound to the platform. ☐ LHDN-approved CA chosen; certificate issued from CSR and registered on the portal.

• ☐ Taxpayer registered on the MyInvois Portal and TIN bound to the platform.
• ☐ LHDN-approved CA chosen; certificate issued from CSR and registered on the portal.
• ☐ UBL 2.1 or JSON payload validates against the MyInvois SDK schema in sandbox.
• ☐ Seller and buyer TINs resolve against the LHDN TIN registry.
• ☐ SST 8% computation matches LHDN expectation on every taxable line.
• ☐ Classification codes mapped against the LHDN classification list.
• ☐ NTP synchronisation in place; issue timestamps in UTC + Kuala Lumpur offset.
• ☐ UUID and QR rendered on the buyer PDF in the prescribed format.
• ☐ 72-hour rejection window timer surfaced in the invoice dashboard.
• ☐ Credit-note and self-billed-invoice flows tested end to end.
• ☐ Consolidated B2C monthly submission tested (if applicable).
• ☐ Archive policy proven for the seven-year LHDN retention period.

Key takeaways

Key takeaways includes: MyInvois is clearance with a twist — every invoice needs a UUID, and the 72-hour rejection window is unique to Malaysia. One certificate per TIN, not per device.

• MyInvois is clearance with a twist — every invoice needs a UUID, and the 72-hour rejection window is unique to Malaysia.
• One certificate per TIN, not per device.
• TIN and SST registration are validated synchronously on every submission; pre-validate buyer data at onboarding.
• B2C is handled by monthly consolidated e-invoices; B2B is per-transaction clearance.
• The Phase 4 (RM1m–RM5m) wave was deferred to 1 January 2026 — confirm your wave on the LHDN portal before assuming you are out of scope.

Related reading

Start at the e-invoicing pillar, then the MyInvois Malaysia mandate page. For the regulatory context, read MyInvois Malaysia explained.

Start at the e-invoicing pillar, then the MyInvois Malaysia mandate page. For the regulatory context, read MyInvois Malaysia explained. The original 2024 launch context lives in e-invoicing in Malaysia with MyInvois. To compare across regimes, read clearance vs reporting models. For the artefact details, see QR codes on tax invoices and real-time invoice reporting.

Authority sources

• LHDN — e-Invoice landing page
• LHDN — e-Invoice Implementation Timeline (phases 1–5)
• LHDN — e-Invoice General FAQs (updated May 2026)
• BERNAMA — Phase 4 deferral to 1 January 2026 for RM1m–RM5m taxpayers
• MyInvois Developer SDK — UBL 2.1 schema, classification list, API reference