What AutoCount, SQL, Bukku and QNE submit, and what they leave to you

There is a species of integrator content that implies Malaysian accounting packages cannot do e-invoicing. They can, and the modules are more complete than the pitch suggests. Anyone selling you a bridge should start by telling you what you already own, because in a large number of cases the answer is that you own enough.

AutoCount describes a Get TIN function for collecting a customer's tax identification number and details in one action, consolidated e-invoices generated from AutoCount POS for retail and F&B across multiple outlets, self-billed e-invoices produced automatically from purchase invoice data, an intelligent submission mechanism that queues invoices during LHDN downtime and retries until they validate, and QR codes on POS receipts so a customer can request an e-invoice after the transaction. It covers AutoCount Accounting 2.0, Cloud Accounting, POS 5.0 and OneSales.

SQL states individual and bulk submission, a one-click batch submit and email to LHDN, monthly consolidated e-invoices, self-billed e-invoices raised from purchase bills, over 1.4 million business records built in so customer TINs can be searched directly, cancellation within 72 hours with a countdown timer showing which documents are still eligible, importing e-invoices directly from suppliers, and real-time status tracking.

Bukku covers MyInvois and the Peppol network, with standard, consolidated and self-billed submissions, separate or bulk submission, a MyInvois Ready profile check that flags incomplete company information, and 72-hour cancellation. Bukku also claims a permanently free e-invoicing plan, which is its own claim rather than an independent finding, but it is the reason it turns up in so many small-business stacks.

QNE, now branded N3 AI Accounting, connects to the MyInvois portal to generate and validate e-invoices from the accounting system, with customer information collection built around the same capture problem everyone else has.

Summarised from each vendor's current e-Invoice pages. This is what they say they do, not an independent test of it, and it changes with releases. Verify against the version you actually licence before you make a decision on it.

These come from LHDN's own SDK documentation, and they apply to your accounting package, to middleware, and to anything we build, identically. They are the reason bulk submission is an engineering problem rather than a loop.

The TIN validation guidance is the one worth reading twice. LHDN explicitly warns that excessive requests may result in throttling, tells you not to call the API repeatedly or before every document submission, and recommends caching validation results in the ERP. So a tool that offers to validate every TIN in your customer master on demand is describing a way to get throttled.

Every module on this page submits what its own package holds. That is not a limitation of the software; it is the definition of it. The gap opens when the document your customer receives was not created there.

This is the normal state of an operational business. A haulage operator bills from trips. A crane hire company bills from crane-days. A workshop bills from a job sheet with parts and labour on it. A consultancy bills from an engagement and a timesheet. In each case there is an operational record that is the real source of the invoice, and the accounting package receives a summarised version of it afterwards, if it receives one at all.

When somebody re-keys that operational record into the accounting package so the e-invoice module can submit it, you have two systems of record and a manual copy between them. That is where transposed figures come from, and more importantly it is where missed submissions come from, because nothing anywhere knows about the trip that never got typed in. The module cannot fix this. It is upstream of the module.

The test is simple and you can run it today. Take last month's invoices to customers and ask, for each one, whether it was born in the accounting package or arrived there by hand. If a meaningful share arrived by hand, your e-invoicing problem is a capture problem and buying a better submitter will not touch it.

Every package offers some form of TIN help. SQL carries over 1.4 million business records so you can search a customer's TIN directly. AutoCount has a Get TIN function. These are genuinely useful and they solve the wrong half of the problem.

A lookup tells you a TIN of the right shape that is associated with a name resembling your customer's. Only LHDN can tell you whether that TIN is correct for that buyer, and it does so through the Validate Taxpayer's TIN API, which takes the TIN together with an identification type and value — NRIC, passport, BRN or army — and answers 200, 400 or 404. That is a different question from "does this look like a TIN", and it is the question that decides whether your submission validates.

Format validation is not truth validation. A TIN of the right shape can belong to a different entity entirely, and a gap check that reports a customer master as complete is reporting that the fields are filled, not that they are correct. Any tool claiming to have verified your customer list without having called LHDN is overstating itself.

The build consequence is that validation belongs at customer creation, cached, with the identification type and value stored alongside the TIN so the answer can be re-checked. Doing it in the submission path is both slower and, per LHDN's own guidance, a way to get throttled. Most vendor modules do not expose the cache or the identification pairing, which is fine for a hundred customers and a problem for four thousand.

During the relaxation period, free-text product descriptions are permitted, which is why nobody is currently feeling this. The relaxation for the SME band runs to 31 December 2027 and full enforcement begins on 1 January 2028. From that date each line needs a proper classification code.

This is a data project, not a software feature. Every product and service you sell has to be mapped to a code, the mapping has to be stored against the item rather than chosen at invoicing time, and somebody with commercial knowledge has to make the calls where the mapping is not obvious. A business with forty products does this in an afternoon. A business with four thousand SKUs is running a project.

The vendor modules will happily submit whatever code sits on the line. What none of them does is tell you which of your four thousand items has no defensible code yet, or catch the pattern where a whole product family was assigned the nearest code in the dropdown because it was faster than thinking. That report — coverage and confidence across the item master — is the thing worth building, and it is worth building now while it is a gradual job rather than in the last quarter of 2027 alongside everyone else.

A submission module pushes. Almost none of them pull back and compare, and that asymmetry is the reason so many businesses cannot answer the only question that matters: how many of last quarter's invoices does LHDN actually hold as validated?

You cannot answer it from the portal, because the portal only knows what reached it. You cannot answer it from the accounting package, because it only knows what you issued and, at best, what it thinks it sent. The answer exists only in the difference between the two sets, keyed on document identifier and amount. Matching row counts prove nothing — a set of missed submissions and a similar-sized set of duplicates cancel out in the total.

This matters more since July 2026, because there is now a defined route for the population it uncovers. The e-Invoice Special Voluntary Disclosure Programme runs from 7 July 2026 to 31 December 2027, and disclosures under it use dedicated document versions, SVDP 1.2 without a digital signature and SVDP 1.3 with one. A back-dated document submitted under the ordinary version validates perfectly well and is simply not a disclosure under the programme.

So there is a specific question to put to your vendor, and it is not "do you support e-invoicing". It is: can this emit the SVDP document versions, and can it show me booked against validated for a closed period? Several tools that submit competently cannot do either, because the programme post-dates them.

QNE's own setup instructions are worth reading whichever package you use, because they make a structural feature of this market explicit. The instructions have you add QNE Software Malaysia Sdn. Bhd. as an Intermediary in the MyInvois portal, with its TIN and business registration number, set representation dates, and toggle all permissions on. The product is then registered as your primary ERP system with a client secret set to expire in three years.

That is not a criticism of QNE. It is how the intermediary model works and it is legitimate — somebody has to be technically capable of acting for you, and the portal has a proper mechanism for it. But it means a third party is representing your company to LHDN under a permission set you granted, and most businesses granting it have not read what it covers.

Three things worth knowing, for any vendor. Who is the intermediary, what representation dates did you set, and how do you revoke it. Those answers should be written down somewhere your finance lead can find them, alongside the client secret expiry, because a secret that quietly expires in three years is a submission outage on a date nobody has in a calendar.

The alternative model is that your own company holds the ERP registration and the digital certificate, and the software submits as you rather than on your behalf. That needs an ERP registration with LHDN and a certificate from a Malaysian licensed certification authority held by your company. It is more work to set up and it means the LHDN-facing identity is yours.

Run down the left column. If most of your answers sit in the middle, your vendor module is the right purchase and you should spend the money on data cleanup instead. If they sit on the right, a bridge is doing work no module is scoped to do.

Four things, in order, and none of them needs a vendor in the room. Take last month's customer invoices and count how many were born in the accounting package versus typed into it. That number decides the capture question on its own.

Then run a completeness check over your customer master: how many records carry a buyer TIN, an identification type and value, an SST registration where one exists, a state code and a contact. Keep blank fields and malformed fields apart, because a blank is work not done and a malformed value is work done wrong that currently looks finished.

Then do the same over your item master for classification codes, and be honest about which codes were chosen because they were nearest rather than right. Then, finally, pull your ledger's invoice list for a closed period and compare it against what LHDN holds as validated for the same period, keyed on identifier and amount rather than on counts.

Those four numbers tell you which purchase you are making. If capture is clean and the data is complete, buy the module and spend nothing else. If the gap is in the data, the money goes on cleanup and capture rather than on a submitter. If the invoices are born outside the ledger, no module reaches them, and that is the case where a bridge is the actual answer rather than the upsell.