Malaysia MyInvois E-Invoicing on Oracle ERP: LHDN Phases, the RM1 Million Threshold & Integration Model

Malaysia's e-invoicing regime is run by the Inland Revenue Board (Lembaga Hasil Dalam Negeri, LHDN / IRBM) through a platform called MyInvois. It is a clearance model: an invoice is submitted to MyInvois for validation before it is shared with the buyer, and only a validated e-invoice — stamped with a Unique Identifier Number and a validation QR — is a compliant tax document. This is a different discipline from a traditional accounting system, and it lands squarely on the ERP.

The phased rollout by turnover

Implementation dates are set by annual turnover for the financial year 2022. The bands have rolled out in sequence, each with a grace ("relaxation") period during which consolidated e-invoices are permitted while businesses stabilise:

The RM10,000 individual-invoice rule

From 1 January 2026 a further rule bites: consolidated e-invoices are no longer permitted for individual transactions exceeding RM10,000. Above that value each transaction needs its own validated e-invoice. For a high-volume B2C or mixed business this removes the "batch it at month-end" escape hatch and pushes validation closer to the point of sale — which, again, is an ERP and integration question, not a manual one.

How MyInvois validation actually works

The flow is near-real-time and structured:

• The supplier submits the e-invoice to MyInvois in XML or JSON, either through the free MyInvois Portal (manual/light volume) or through the MyInvois API (system-to-system, the only viable path at enterprise volume).
• MyInvois validates the structure and the required data fields in near real time and, on success, returns a Unique Identifier Number (UIN) and a validation link rendered as a QR code.
• The supplier shares the validated e-invoice (with its QR) with the buyer.
• Either party may act within a 72-hour window: the buyer can reject and the supplier can cancel. After 72 hours the e-invoice is locked and a correction requires a fresh credit or debit note.

Peppol is also part of the Malaysian picture: MDEC accredits Peppol service providers, and enterprises can exchange documents over the Peppol network through an accredited provider that interfaces with MyInvois. Whether you connect directly to the MyInvois API or via a Peppol/PDP provider is an architecture decision that depends on your invoice volume and your trading network.

What this demands of Oracle Fusion and EBS

MyInvois expects a rich, structured document — dozens of mandatory and conditional fields covering supplier and buyer identification (including TIN), classification codes, tax details and totals. Mapping the Oracle data model to that structure cleanly is the core of the project:

• Field mapping and validation codes. Every required MyInvois field must resolve from Oracle master and transaction data, including tax classification and product/service codes. Missing or malformed fields are rejected at submission, not discovered later.
• TIN capture and validation. Buyer and supplier Tax Identification Numbers must be present and correct; this usually means enriching the customer and supplier master rather than patching invoices one by one.
• Real-time or near-real-time submission. An integration layer — direct MyInvois API or a certified middleware/PDP — submits from Oracle and captures the response synchronously enough to stay within business cycles.
• Store the UIN and validation QR. Persist the Unique Identifier Number and the validation QR against the AR transaction, and print the QR on the buyer's copy.
• Respect the 72-hour window. Cancellations and rejections must flow back into Oracle so the ERP and MyInvois never disagree about a document's status.
• Encode the RM10,000 logic. The decision to issue an individual versus consolidated e-invoice must be driven by rules in the ERP, not left to a clerk's judgement.