The invoices you never submitted now have an amnesty window

The e-Invoice Special Voluntary Disclosure Programme is Section 17 of the e-Invoice Specific Guideline. It runs from 7 July 2026 to 31 December 2027, which is the same date the relaxation period for the SME band ends, and it exists because LHDN can see the same thing every accountant can: a large number of businesses crossed into a mandated band, kept issuing invoices the way they always had, and submitted a fraction of them.

It is a disclosure programme, not a waiver. You still submit the documents. What changes is what happens to you for having been late, and the mechanism you use to file the historical ones. The programme is administrative rather than punitive by design, and the guideline sets it out as a defined route with its own document versions rather than as a discretionary concession you have to argue for case by case.

The framing matters for how you plan the work. A concession you negotiate is a legal exercise. A defined route with defined document versions is an engineering exercise: work out exactly what is missing, produce documents in the required shape, and submit them in the required order. The first of those three steps is the one almost nobody has done.

The guideline names three eligible categories, and they are broader than most people assume. The first is taxpayers who missed submissions — invoices that were issued to a customer and never sent to MyInvois at all. This is the largest group and usually the least aware, because a missed submission produces no error message and no rejected document. It produces nothing, which is exactly why it goes unnoticed.

The second is taxpayers who submitted non-compliant e-invoices. The document went in, but something on it was wrong: a buyer TIN that belongs to a different entity, a classification code chosen because it was the closest one in the dropdown, a consolidated document covering a transaction that should have been issued individually. These are harder to find than missing submissions, because the invoice has a validation reference and looks closed.

The third is taxpayers already under an IRBM compliance review. That is worth reading twice, because it inverts the usual assumption that a voluntary programme closes the moment the authority contacts you. Under this programme, being under review does not by itself put you outside it — though it is precisely the case where you should be taking your tax agent's instruction before you file anything, not ours.

Penalty and prosecution relief applies to disclosures made inside the window. Separately, the guideline states that during the relaxation period there is no prosecution under section 120 of the Income Tax Act 1967, which is the provision that would otherwise carry the compliance failure.

There are three carve-outs, and they are stated as exceptions to the relief rather than as exclusions from the programme: fraud, wilful default, and negligence. The first two are the ones people expect. Negligence is the one that determines how you should approach the exercise, because a business that reconciles its position, finds a gap and files it inside the window is doing the opposite of neglecting it — and a business that knows it has a gap, has known for a year, and files nothing is not.

Which is the practical argument for doing the reconciliation early and in writing. The output of the work below is a dated report showing what was booked, what was validated, and what was submitted to close the difference. Whatever your tax agent decides to do with it, that artefact is the thing that distinguishes a corrected position from a neglected one.

This is the whole job, and it is the part nobody sells you. Every route to the SVDP passes through one question that sounds trivial and is not: which invoices exist in your books that LHDN has no validated record of?

You cannot answer it from the MyInvois portal, because the portal only knows what reached it. You cannot answer it from your accounting package, because it only knows what you issued. The answer only exists in the difference between the two sets, and nobody produces that difference by accident. A gap of this kind is found by building the comparison deliberately. It does not surface in the course of normal work, because from its own point of view neither system is missing anything.

The mechanics are a set reconciliation over a period. Pull the full list of invoices booked in your ledger — number, date, buyer, total, tax — and the full list of documents LHDN holds as validated for the same period. Key them against each other. Four states come out, and they need to be kept apart because each one is a different piece of work.

State one: booked and validated, and the figures agree. Nothing to do. State two: booked and never submitted. This is the SVDP population — the documents you file inside the window. State three: booked and submitted, but the figures do not agree. Somebody retyped a number, and this is a correction rather than a fresh submission; the document version and the route depend on what is wrong, and it is the state most likely to need your tax agent's view before you touch it. State four: validated but not booked. Rarer, more alarming, and almost always a duplicate submission or a document raised in the portal by hand and never entered into the accounts.

Two matching row counts are not a reconciliation. A period can show exactly as many booked invoices as validated documents and still be wrong in both directions at once, because a set of missed submissions and a similar-sized set of duplicates cancel each other out in the total. Match on the document identifier and the amount, never on the count.

The reconciliation also has to be repeatable, because you will run it more than once: before you file, after you file, and monthly afterwards to make sure the gap is not reopening. A one-off spreadsheet built by hand at month end is how the gap appeared in the first place. This is the part of the work we build as software rather than deliver as a report.

The output of the reconciliation, in the form we put it on screen. The counts are yours; the states are fixed.

Disclosures under the programme use dedicated document versions. SVDP 1.2 is the version without a digital signature; SVDP 1.3 is the version with one. Which of the two you use follows from how you are submitting — a signed submission path uses 1.3, an unsigned one uses 1.2.

The field is easy to overlook because a submission built for normal operation carries the ordinary version and validates perfectly well. That is the trap. A back-dated document submitted under the standard version is a valid e-invoice; it is just not a disclosure under the programme, and it does not carry the programme's treatment. The version field is what marks the submission as an SVDP filing at all.

In practice this means the backlog run is a separate code path from your day-to-day submission, not the same function called with older dates. If you are building or buying a bridge, ask specifically whether it can emit the SVDP document versions. Several tools that submit competently cannot, because the programme post-dates them.

Example 23 in the guideline works through the point that catches out anyone trying to be efficient about this. Where the disclosure is made through consolidated e-invoices covering past periods, those consolidated documents are filed month by month. You do not lump eighteen months of unsubmitted sales into a single consolidated document dated today.

The reason is that a consolidated e-invoice represents a period, and the period it represents is part of what makes it correct. One document covering a year and a half is not a late filing of eighteen monthly documents; it is a nineteenth document that matches none of your monthly accounts. Reconciling it back to your books afterwards is close to impossible, which defeats the purpose of the exercise.

This has a direct effect on how the work is planned. A disclosure covering, say, fourteen months is fourteen consolidated submissions, each built from that month's transactions, each reconciling to that month's ledger. If your data cannot be sliced by month cleanly — because it was migrated, or because the periods were closed and adjusted — that becomes the first problem to solve, before any submission code runs.

Example 24 deals with the RM10,000 transactional threshold, which is the line the guideline draws between transactions that may sit inside a consolidated document and transactions that are treated on their own.

It interacts with the relaxation in a way worth being explicit about. During the relaxation period, consolidated e-invoices are permitted for all activities, so the threshold is not the constraint on your current operations that it will be once the relaxation ends. For a back-dated disclosure it is a question about the period being disclosed, not about today, and the answer can differ across the months you are filing.

This is a case to read Example 24 with your tax agent against your own transaction sizes before you decide how a period is composed. It is a judgement about your filings; we build to whichever answer you are given, and we build it so the threshold is applied by the system per transaction rather than by a person eyeballing a list.

The MyInvois portal is a keyboard. For a business disclosing thirty invoices it is a slow afternoon. For a business disclosing two thousand across fourteen months it is not a plan, and the failure mode is not that it takes too long — it is that manual entry at that volume introduces its own errors, which is the second eligible category of the programme you have just filed yourself into.

The alternatives are LHDN's batch workbook, which a person uploads, and API submission, which requires an ERP registration with LHDN and a digital certificate from a Malaysian licensed certification authority. Both are real routes. The workbook is the honest answer for a business that does not yet hold the registration and certificate, and it is what we build for clients in that position rather than writing a submission client against credentials that do not exist. It is the path shipped for OKAYA Transport, whose ledger exports as LHDN's own batch workbook for a person to upload.

Whichever route you use, the submission run should refuse to be naive. Before anything is sent, it should answer how many documents would go, which are held back, and what each held-back one is short of. The alternative is a rejection an hour later that names a row number instead of a customer, on a file you can no longer reconstruct.

The order of work, for a business starting from nothing: reconcile first and get the gap onto a screen; fix capture at the source so the gap stops growing while you work on it; compose the disclosure month by month; submit under the correct SVDP version; then reconcile again and keep reconciling monthly. Building the submission before the reconciliation is the common sequence and the wrong one — it produces a system that files confidently against data nobody has checked.