Direct Clearance · Malaysia · MyInvois

Malaysia e-Invoice
Knowledge Base

Plain-English explanations of the MyInvois system — written by someone who has actually built the IRBM API integration. No marketing language, no reformatted government copy.

1
Identity

TIN & BRN

A TIN (Tax Identification Number) is how LHDN identifies a taxpayer for e-Invoice purposes — every supplier and buyer on a MyInvois document carries one. A BRN (Business Registration Number) is the separate identifier issued by SSM (Companies Commission of Malaysia) for the legal entity itself.

The two are checked together. IRBM's Validate Taxpayer's TIN API confirms that a TIN and its associated registration details match, and from August 2026 that check has tightened — submitters need accurate BRN information on file for their buyers, not just a TIN that happens to resolve.

What TIN Identifies

The taxpayer record LHDN holds — individual or entity. Every invoice, credit note, debit note, refund note, and self-billed invoice must carry the correct TIN for both supplier and buyer.

What BRN Identifies

The legal registration of a business with SSM. For individuals without a business registration, a different ID type applies (e.g. NRIC for MyKAS/MyPR residents).

Why Both Matter

A TIN alone does not prove a business relationship is correctly documented — BRN ties the tax identity to the registered legal entity, which is what the tightened validation checks for.

Where This Bites

Onboarding a new buyer with stale or missing BRN data is the most common cause of TIN validation failures in practice — collect it up front, not at submission time.

From practice: Build TIN/BRN capture into buyer onboarding, not into the invoice submission flow. Chasing down a missing BRN after a document is already assembled is the slowest failure mode to fix.
2
Classification

MSIC Code

MSIC (Malaysia Standard Industrial Classification) is a numeric code identifying the industry a business activity belongs to — published and maintained by the Department of Statistics Malaysia. IRBM requires an MSIC code on e-Invoices so submitted transactions can be classified consistently for tax analysis.

MSIC subcategories were folded into the schema in 2024, meaning the code needs to reflect the specific activity, not just a broad sector.

Where It Applies

Assigned at the supplier level on every submitted document — the classification of the business issuing the invoice, not the individual product or service line.

Getting It Wrong

An incorrect or generic MSIC code will not always fail schema validation, but it misrepresents the business to LHDN's downstream reporting — worth setting deliberately, not defaulting.

Mapping to Your Catalogue

For multi-line-of-business suppliers, MSIC lookup should be tied to a product/service catalogue so the right code is applied automatically rather than hardcoded per integration.

Where to Find Codes

The current MSIC list is published by DOSM and referenced in IRBM's SDK codes reference — always cross-check against the live list rather than a cached copy, since subcategories have changed.

Simple summary: MSIC is to a Malaysian business what an industry/SIC code is elsewhere — a required classification tag, not an optional metadata field.
3
Schema

Document Types & Versions

IRBM defines 5 document types — Invoice, Credit Note, Debit Note, Refund Note, and Self-Billed Invoice (see the full breakdown on the Malaysia integration page). Each type is issued under a schema version, and the version in use determines what the document supports.

Version 1.1 added digital signature support across all document types, restructured to UBL 2.1 sequencing for cleaner validation, and shipped separate XML/JSON sample sets. Systems built only against v1.0 do not automatically gain signature support — the version has to be targeted explicitly.

Version 1.0

The original schema, no signature validation path. Still valid for submission but lacks the structural updates introduced in 1.1.

Version 1.1

Adds digital signature creation/validation guidance, UBL 2.1 sequencing, and per-document-type sample payload pages. The current baseline for new integrations.

Choosing a Version

Sign with X.509 (see the lifecycle steps on the Malaysia page) and target v1.1 for new builds — there is little reason to build fresh against v1.0.

SVDP as a Special Case

The SVDP versions (1.2, 1.3) are a separate track from the standard 1.0/1.1 line — see the dedicated SVDP article below.

From practice: Version handling belongs in the mapping layer, not scattered through submission code — one clean switch on document version keeps signature and field-structure differences from leaking into business logic.
4
Validation

Field Validation Rules

IRBM enforces structural rules on individual fields, separate from business-logic validation (tax calculations, TIN checks). These rules were tightened for production deployment in mid-2026, after first running in sandbox from December 2025. Getting them wrong causes rejections that have nothing to do with the actual invoice content.

Field Rule
Date fieldsMust be YYYY-MM-DD; "N/A" or blank placeholders are rejected
Amount fieldsScientific notation is not accepted — always use plain decimal
Bank account numberMax 150 characters
e-Invoice code / numberMax 50 characters
Exporter authorisation numberMax 300 characters
Business activity descriptionMax 300 characters
Payment termsMax 300 characters
Prepayment referenceMax 150 characters
State / postcodeState follows Malaysia's standard codes; postcode is 5 characters for Malaysian addresses, up to 50 for international
From practice: Run these as pre-submission checks in your own mapping layer rather than relying on IRBM's API response to catch them — a local validation pass is faster to iterate on than a round trip to sandbox or production.
5
Document Handling

Consolidated e-Invoice & State Code 17

A consolidated e-Invoice bundles multiple transactions — typically B2C sales over a period, often a month — into a single submitted document, rather than issuing one e-Invoice per sale. It exists because requiring an individual e-Invoice for every retail transaction would be impractical for high-volume, low-value consumer sales.

State Code 17 ("not applicable") is restricted to two specific cases: consolidated e-Invoices issued in Malaysia, or e-Invoices covering transactions that took place outside Malaysia. Using it outside those cases is a validation-rule violation, not a stylistic choice.

Who Uses Consolidation

Retail, F&B, and other high-volume B2C businesses where issuing per-transaction e-Invoices is operationally unworkable.

When It's Submitted

Periodically — commonly monthly — as a single document representing the aggregate of qualifying transactions for that period.

State Code 17 Boundaries

Only valid for: (1) consolidated e-Invoices issued within Malaysia, or (2) e-Invoices for transactions that occurred outside Malaysia. Not a general-purpose fallback for "unknown".

Also Removed

State code '00' is no longer accepted for e-Invoice issuance via API or batch upload — a distinct, now-invalid legacy value worth checking for in older mapping code.

From practice: If your business issues both individual and consolidated invoices, keep the state-code logic branch explicit in code — it is an easy rule to silently violate when consolidation is added to an existing per-transaction flow.
6
Currency

Currency & Exchange Rate Rules

Whenever an e-Invoice's Invoice Currency Code is anything other than MYR, a Currency Exchange Rate element is required on the document. This lets LHDN evaluate the MYR-equivalent value of foreign-currency invoices without a separate lookup.

The currency code list itself has also expanded — CNH (offshore/international Renminbi, used in Yuan trade settled outside mainland China) was added as distinct from CNY (onshore, domestic trade), so the two should not be used interchangeably.

When Exchange Rate Is Required

Any time Invoice Currency Code ≠ MYR. Domestic MYR invoices do not need the element.

CNH vs CNY

CNH is used for international/offshore Yuan trade; CNY is for domestic mainland China trade. Using the wrong one misrepresents the settlement context.

Source of Truth

Pull exchange rates from a rate provider your finance team already trusts for reporting — consistency between the rate on the e-Invoice and internal books avoids reconciliation friction later.

Other Codes Follow Standards

Country, payment mode, tax type, and currency codes generally follow published international/ISO-aligned code lists referenced in IRBM's codes documentation — check the live list rather than hardcoding from memory.

Simple summary: Any non-MYR invoice needs a rate attached, and the currency code itself needs to match the actual settlement context — not just "the currency the buyer paid in".
7
API Design

Rate Limiting

IRBM applies rate limits across the core e-Invoice APIs — login/authentication, document submission, cancellation, rejection, search, and TIN validation. This means a service provider integration cannot treat these endpoints as unlimited-throughput — high-volume submitters need to design around it from the start, not retrofit it after hitting 429s in production.

Affected Endpoints

Login/OAuth token, Submit Document, Cancel Document, Reject Document, Search Documents, and Validate Taxpayer's TIN — the highest-traffic parts of any integration.

Design Implication

Batch submitters need queueing and backoff logic, not a tight loop firing requests as fast as documents are generated. Token caching also matters — don't re-authenticate more than necessary.

Sandbox vs Production Limits

Rate limits differ between environments (see the next article) — load-testing against sandbox limits alone can give a false sense of production headroom.

Search API Ceiling

The Search Documents API caps at up to 10,000 documents returned per call — plan pagination/filtering for high-volume search rather than assuming unlimited result sets.

From practice: Build retry-with-backoff and OAuth token caching as first-class parts of the integration, not an afterthought — this is the single most common cause of intermittent submission failures at volume.
8
Environments

Sandbox vs Production

IRBM's sandbox environment is not a permanent mirror of production — it behaves differently in ways that matter for integration testing. Data submitted to sandbox is retained for a maximum of 3 months, and rate limits differ from production, so long-running test data or throughput assumptions built in sandbox do not automatically carry over.

Data Retention

Sandbox data expires after roughly 3 months. Do not rely on sandbox as long-term test-data storage — re-seed test scenarios periodically.

Rate Limit Differences

Sandbox and production rate limits are not identical — a load test that passes comfortably in sandbox may still hit limits in production.

Staged Rule Rollouts

New validation rules are sometimes enabled in sandbox first (e.g. the field validation rules from Article 4 ran in sandbox from December 2025 before their production deployment) — sandbox can preview upcoming production behaviour.

Certificate Handling

Sandbox and production typically use separate PKI/certificate chains — a signing setup that works in one does not automatically work in the other.

From practice: Treat a sandbox pass as necessary but not sufficient — retest against production-equivalent rate limits and fresh test data before calling an integration go-live ready.
9
Compliance Programme

SVDP — Special Voluntary Disclosure Programme

The e-Invoice Special Voluntary Disclosure Programme (SVDP) is a limited-time channel for businesses to bring historical e-Invoice compliance up to date, running until 31 December 2027. It uses its own document versions — separate from the standard 1.0/1.1 schema line — so systems supporting SVDP need to be updated specifically for it, not assumed to work automatically.

SVDP 1.2

Without digital signature — the lighter-weight version of the two SVDP document formats.

SVDP 1.3

With digital signature — mirrors the security posture of the standard v1.1 schema but under the SVDP programme.

Programme Window

Effective until 31 December 2027. Not a permanent alternative submission path — it exists to clear a compliance backlog within a defined window.

What to Update

Systems intending to use SVDP need explicit support for the 1.2/1.3 versions and their sample XML/JSON structures — a generic "any version" submitter is not automatically SVDP-compatible.

From practice: SVDP is a special case, not the default path — most integrations should keep standard v1.1 submission as the primary flow and only add SVDP support if the business specifically needs to disclose historical gaps.
10
Changelog

Recent SDK Changes

IRBM updates the MyInvois SDK and API behaviour on a rolling basis. The table below summarises the most consequential recent changes — a starting point, not a substitute for checking the official release notes before a go-live.

Date Change
Jul 2026SVDP document versions (1.2, 1.3) introduced, programme runs to Dec 2027
Aug 2026Tightened field validation rules move from sandbox to production (see Article 4)
Aug 2026TIN/BRN validation enhancement takes effect — accurate buyer BRN now required
Apr 2026State Code 17 restricted to consolidated MY invoices and non-MY transactions; scientific notation banned in amounts
Apr 2026"Hectare" added as a unit of measurement
Feb 2026MyInvois portal SSL certificate renewed
Dec 2025Field validation rules first enabled in sandbox ahead of production rollout
Sep 2025Currency Exchange Rate element becomes mandatory in production for non-MYR invoices
Source of truth: This table is a working summary, not a live feed. For the complete, authoritative changelog, check IRBM's own SDK release notes before making integration decisions.
Let's Talk

Need Help Building
on MyInvois?

These articles cover the concepts. If you are implementing a Malaysia e-Invoice integration — IRBM API middleware, ERP connector, or a compliance gap assessment — reach out directly.

hello@peppwise.com
Send an Enquiry Book a Discovery Call