Four ways to get invoices into MyInvois, and what each one costs

LHDN's portal costs nothing and is a complete solution for a real category of business. If you issue a handful of invoices a month to a small set of customers whose details you already hold, you should use it, and anybody selling you something else has not asked how many invoices you issue.

It stops working at a knowable point, and the point is not a number of invoices — it is the moment the invoices already exist somewhere else. The portal is a keyboard. When an invoice has been raised in AutoCount, SQL or Bukku and someone is retyping it into a browser, you have introduced a second system of record and a manual copy between them. That is where transposed figures and missing buyer TINs come from, and more importantly it is where missed submissions come from, because nothing in the portal knows what you failed to type into it.

The second limit is that the portal cannot tell you what you have not submitted. It knows what reached it. Any question of the form "how many of last quarter's invoices are actually validated?" has to be answered by comparing the portal's records against your ledger, and that comparison is not something the portal offers. For most businesses the portal is fine until the first time somebody asks that question and nobody can answer it.

Cost: nothing in fees, and a few minutes of somebody's attention per invoice, plus whatever the errors cost. At twenty invoices a month that is an afternoon spread across the month. At three hundred it is somebody's job.

AutoCount, SQL Accounting and Bukku all ship e-invoicing functionality, and if you already run one of them this is the first place to look. You are buying an upgrade or a module on software you already licence, from a vendor who already holds your data, and the integration risk is theirs rather than yours.

The honest caveats are about fit rather than quality. The module submits what the accounting package holds, which means it inherits whatever your customer master and item master actually contain — if the buyer TIN was never captured, the module cannot invent it. It also generally covers documents raised inside that package. Businesses that raise invoices somewhere else, which is most operational businesses with a job sheet, a trip log or a timesheet feeding billing, find that the module solves the last step of a process whose earlier steps are still manual.

Cost is a vendor question and moves with version, licence count and support tier, so ask your reseller for a current figure rather than trusting any published number, including a range on a page like this one. What is worth asking specifically: does it emit the SVDP document versions for a back-dated disclosure, and can it reconcile submitted documents back against the ledger, or does it only push?

A middleware provider sits between your system and MyInvois and submits on your behalf, usually priced per document with a monthly floor. The appeal is real: no integration to build if a connector for your accounting package already exists, someone else maintains the connection when LHDN changes the specification, and you can be live quickly.

Gotchaa Lab, surveying what Malaysian developers charge, puts what most SMEs pay for middleware or a basic custom integration at RM5,000 to RM25,000. Treat that as a range for the category rather than a quote for your situation, and read carefully whether the figure you are given is a setup cost, an annual subscription, or a first-year total — the three get quoted interchangeably and they are not the same number.

The structural thing to understand about per-document pricing is that it is a variable cost that scales with the thing you want to grow. That is a fair trade at low volume and an increasingly poor one as you get busier, because the cost per invoice does not fall as the invoices become routine. Model it over three years at your expected volume rather than at today's, and compare that total against a one-time build. The crossover arrives sooner than most people assume.

The other question to ask is where your invoice data sits and who else can read it. A middleware provider holds your full sales ledger by definition. That may be entirely fine; it should still be a decision rather than a default.

A bridge reads what your existing system already holds, adds the fields LHDN requires that it never asked for, submits, and writes the validation result back against the invoice. Nothing is replaced. The accounting package stays where it is and keeps being the system of record, which is the point — replacing working accounting software because of an e-invoicing mandate is an expensive way to solve a narrow problem.

Our published price for this is RM 8,500. It is worth putting that next to the market so it reads as a considered number rather than a cheap one. Xantec publishes RM55,000 to RM150,000 for a focused ERP or POS connector, and RM120,000 to RM350,000 and above for multi-system integration. Gotchaa Lab puts middleware and basic custom integration for SMEs at RM5,000 to RM25,000. Our RM 8,500 sits at the bottom of that middleware range for a one-time build rather than a subscription, and an order of magnitude below the enterprise connector figures.

The reason we can quote that is scope discipline, and it is fair to be explicit about what it excludes. RM 8,500 buys a bridge onto a system that can export its data and can be written back to, for a business whose customer and item records are largely complete. It does not buy a rewrite of an accounting package, a migration, or the cleanup of several thousand incomplete customer records. Where the accounting package is genuinely the problem, the answer is invoicing native to a full ledger, which is the RM 25,000 tier, and we say so rather than quoting a bridge we know will not hold.

The other thing the bridge should do, and the reason we build them rather than reselling middleware, is the reconciliation. A submission pipe that only pushes leaves you in exactly the position that created the current mess: no way to answer what was booked against what was validated. A bridge that writes the validation reference back against the invoice makes that question a query.

Every quote you receive will be for the integration. The integration is rarely what makes the project long. The data is.

LHDN's field model wants things a Malaysian sales ledger has generally never carried: the buyer's TIN, an identification scheme and number, an SST registration where one exists, a state code, a contact, and a classification code per line. Those fields were not on the paper invoice, so they were never asked for when the customer was created. On a customer list built up over years, the proportion of records carrying all of them is generally small, and finding out what it actually is on your list is a morning's work we do before quoting rather than after.

Two failure states have to be kept apart, because they cost different amounts to fix. A blank field is work not done yet, and it is fixed by contacting the customer. A field that is filled but malformed — a TIN of the wrong shape, a state code that is not on LHDN's list — is work done wrong, and it is fixed by someone checking a record that currently looks complete. The second category is worse, because it passes a casual glance and fails at submission.

There is also a limit worth stating on the screen and not in a footnote: a TIN of the right shape can still be the wrong TIN. Validation of format is not validation of truth. Only LHDN can confirm the second, at submission. A gap check tells you what is missing, not what is correct, and any tool claiming otherwise is overstating itself.

The classification codes are the other quiet cost. During the relaxation, free-text descriptions are permitted, so nobody is forced to resolve them. From 1 January 2028 they are. A business selling forty products can map them in an afternoon. A business with four thousand SKUs is running a project, and it is much cheaper to run it now, gradually, than in the last quarter of 2027 alongside everyone else.

The MSME Digital Grant MADANI is a 50% matching grant of up to RM5,000, administered by Bank Simpanan Nasional, and it is claimable only through a Technology Solution Provider registered with MDEC. On a RM 8,500 build, a successful claim of the maximum would cover a meaningful share of it, and it is worth asking about before you commit to any route.

The condition that decides eligibility is the provider, not the project. The work has to be bought from an MDEC-registered TSP for the grant to apply. So the question to ask any vendor, including us, is a direct one: are you MDEC-registered, and can you evidence it?

For our part: our own MDEC TSP registration status is not something we are going to claim on this page, because we have not verified it for publication. Ask us directly and we will tell you where we stand rather than let a grant do sales work it may not be entitled to do. Everything above about the grant is a description of the scheme, not a statement that our work qualifies for it.

Volume is the crude driver and the one that decides most cases. Read the last column first — it is usually what actually forces the change, rather than the invoice count on its own.

Ask every vendor the same five questions and the price differences usually explain themselves. Does it read from the system we actually raise invoices in, or only from the accounting package? Does it write the validation reference back against the invoice, or only push? Can it reconcile booked against validated and show us the gap? Can it emit the SVDP document versions for a back-dated disclosure? And whose accounts does it run in — ours or yours?

The last one decides whether you have bought an asset or a subscription. Our builds are deployed into the client's own GitHub, Supabase and Vercel accounts, with the credentials held by the client. That is not a philosophical position; it is what makes it possible for you to fire us without your invoicing stopping.

One caution on API submission specifically. Submitting to MyInvois over the API requires an ERP registration with LHDN and a digital certificate from a Malaysian licensed certification authority, held by your company. Any quote that includes live API submission without those in place is quoting for code that cannot be tested. Where they are not yet in place, the correct interim answer is LHDN's own batch workbook, produced correctly and completely, for your staff to upload — which is what OKAYA Transport runs today, with the submission client left as a defined addition on top of data that is already right.