# Accounting Software in Malaysia: The Two Capabilities That Now Decide It

> A vendor-neutral way to evaluate accounting software for a Malaysian company on the two axes that now matter — how it reaches MyInvois, and whether its output can feed an MBRS filing.

- Category: accounting
- Language: en
- Status: published
- Updated: 2026-07-20
- Canonical: https://negaraku.md/en/accounting/accounting-software-malaysia

---

The Malaysian accounting-software listicle is a solved genre: ten products,
a paragraph each, a table of features nobody uses, and an affiliate link. It
was never useful, and since e-Invoice and MBRS 2.0 landed it is actively
misleading, because it ranks products on the things that no longer separate
them.

Two capabilities separate them now. Neither appears on a features grid.

## Axis 1: how the software gets a document into MyInvois

LHDN documents **two transmission mechanisms** — the MyInvois Portal and the
API — and separately allows a taxpayer to appoint an **intermediary** to submit
on its behalf. That produces four practical shapes, and the software you buy
determines which are open to you.

| Path | What the software must do | What to verify |
| --- | --- | --- |
| **Portal only** | Nothing. You key or batch-upload documents in MyInvois | Whether the software can export a file matching the Portal's batch spreadsheet layout, or whether it is re-keying |
| **Direct API** | Build and sign UBL 2.1 documents, manage tokens, handle asynchronous validation | Whether the Malaysian localisation covers self-billed document types and the import annexure fields, not just standard sales invoices |
| **Via an intermediary or middleware** | Export clean transaction data on a schedule | Whose credentials the submission uses, who holds the data, and what leaves with you on exit |
| **Via a Peppol service provider** | Same as middleware, over a Peppol access point | That you actually need interoperable exchange with trading partners — Peppol is not a MyInvois requirement |

The choice between these is a volume and architecture question covered in
[MyInvois integration](/en/taxation/myinvois-integration). What belongs here is
the software-side consequence: a package with no API integration path does not
stop you complying, it commits you to the Portal, and the Portal's cost is
keystrokes and month-end concentration rather than licence fees.

**The intermediary detail worth writing into a contract:** an intermediary can
only view and retrieve the e-Invoices it submitted itself. Change provider and
your submission history does not follow you. Plan a parallel run and keep your
own archive.

## The accreditation claim to distrust

LHDN publishes an SDK, API documentation and an FAQ. It does not publish an
accreditation scheme, a certification programme or an approved-vendor list for
e-Invoice software. If a product is marketed as **LHDN-approved**, that status
is the vendor's own description of itself. Ask to see the instrument.

There is one genuine accreditation in Malaysian e-invoicing, and it belongs to
someone else. **MDEC is Malaysia's Peppol Authority**, and it accredits two
distinct roles:

| Role | What it is |
| --- | --- |
| **Peppol Service Provider (SP)** | Operates a Peppol access point — the connectivity gateway that routes documents |
| **Peppol-Ready Solution Provider (PRSP)** | Builds software or ERP with Peppol compliance for end users |

Both lists are published by MDEC. Neither is an LHDN approval, and neither is
required to comply with the e-Invoice mandate. A vendor holding MDEC
accreditation has demonstrated conformance to Peppol standards, which is a real
credential — for Peppol.

## Axis 2: whether the output can feed an MBRS filing

Here is the fact that reframes the whole category: **no accounting package
lodges financial statements to SSM.**

Filings are built in SSM's own **MBRS Preparation Tool (mTool)**, which
generates a zip that is uploaded to the MBRS portal. That is the accepted
submission artefact. Whatever your ledger produces, it becomes an MBRS filing
only after passing through that tool.

So MBRS-ready, as a software claim, can only honestly mean one thing: the
output is in a shape that maps cleanly onto SSM's **SSMxT** taxonomy. Three
properties decide that:

- **A stable, exportable trial balance** with account codes that do not change year to year. Mapping is rebuilt from scratch whenever codes move.
- **A presentation basis that does not drift.** Switching between presentation formats forces the mapping to be redone even when the numbers are identical.
- **A chart of accounts whose lines have somewhere to land.** The SSMxT architecture states that entities **must not extend the taxonomy** — company-specific extensions are prohibited, and detail belongs in text blocks. An account with no corresponding concept is a manual decision every year.

Two mechanical traps sit downstream and are worth knowing before you blame the
software. Expenses are stored as **positive** values in SSMxT, the reverse of
most ledger exports. And a figure stated in thousands must carry the right
`decimals` attribute — the wrong one passes validation silently and files a
number a thousand times too large or too small.

## An evaluation checklist to send a vendor

1. Which MyInvois transmission mechanism does the product support today — Portal export, direct API, or submission through your own intermediary service?
2. If API: does the localisation cover **self-billed** e-Invoices and the annexure fields for imported goods, or only standard sales invoices?
3. Under whose credentials are documents submitted, and who holds the validated documents?
4. Can we export a complete trial balance with stable account codes, in a machine-readable format, without a consultant?
5. Do you hold MDEC accreditation as a Peppol SP or PRSP — and if you claim LHDN approval, what document evidences it?
6. On exit, what leaves with us: the ledger, the mapping, the submission history?

## Why this page names no products

Because a capability is only publishable if the vendor or LHDN publishes it,
and vendor capability pages change between releases without a changelog. A
product comparison written today is a snapshot of marketing copy, not of
software. The checklist above outlives the snapshot; a ranked table would not.

## Common mistakes

- **Believing an LHDN-approved claim.** LHDN publishes no such list.
- **Confusing MDEC Peppol accreditation with an LHDN approval,** or treating Peppol as mandatory.
- **Buying a filing button.** Nothing files to MBRS except mTool output.
- **Reading MBRS-ready as certification.** At best it means a clean, stable export.
- **Changing the chart of accounts annually** and paying for the mapping again each time.
- **Evaluating only sales invoicing.** Self-billed volume is what breaks most implementations.
- **Assuming validation catches scale errors.** A thousandfold scale error passes.

## What's next

Run two tests on whatever you already own before you shop. Export a full trial
balance and check whether every account has an obvious SSMxT home. Then take
one self-billed transaction — an agent commission or a foreign supplier — and
follow it end to end into MyInvois. Whichever of those two fails is the thing
you are actually buying.

## Sources

- Software Development Kit (SDK) for the LHDNM MyInvois System — https://sdk.myinvois.hasil.gov.my/ (LHDN)
- IRBM e-Invoice Guideline — https://www.hasil.gov.my/wp-content/uploads/IRBM-e-Invoice-Guideline.pdf (LHDN)
- Peppol Service Providers — National e-Invoicing — https://www.mdec.my/national-einvoicing/peppol-service-providers (MDEC)
- SSMxT 2022 Architecture Document — https://www.ssm.com.my/Pages/Register_Business_Company_LLP/Company/document/SSMxT2022_Architecture_Document.pdf (SSM)
- MBRS Preparation Tool — https://www.ssm.com.my/Pages/Services/Other-Services/XBRL%20250918/MBRS-Preparation-Tool.aspx (SSM)

---
Source of truth: https://github.com/negaraku-md/NegaraKu.md
License: CC BY-SA 4.0