The rule behind the search
Malaysia's e-Invoice framework allows many suppliers to aggregate a month's transactions into a single consolidated e-Invoice rather than issuing one for every sale. HASiL's e-Invoice Specific Guideline sets one condition on that convenience that applies across every industry: a single transaction whose value exceeds RM10,000 must be issued as its own individual e-Invoice, and cannot be folded into a consolidated submission. HASiL's guideline states that this applies with effect from 1 January 2026.
That is a HASiL rule, and HASiL's own current guideline is the authoritative statement of it — confirm the position directly there before treating anything below as settled, because a transaction-level rule of this kind can be revised again. What this article adds is the part HASiL's guideline does not cover: how a Dynamics 365 Business Central configuration actually enforces the rule, transaction by transaction, without relying on someone remembering to check.
What "consolidation is not allowed" actually requires
Where a buyer has not asked for an individual e-Invoice, HASiL's guideline allows the supplier to aggregate the month's receipts into a consolidated e-Invoice, submitted within seven calendar days after month end, using one of several accepted presentation methods — each receipt summarised as a separate line, a continuous run of receipt numbers presented together, or branches and locations submitting their own consolidated batches. Consolidated submissions are also capped: a maximum of 100 e-Invoices and 5MB per submission, and 300KB per individual e-Invoice, which is why HASiL allows suppliers to split one month's receipts across several consolidated submissions where volume requires it.
The RM10,000 condition sits on top of that mechanism as an exception route. A transaction that would otherwise have gone into this month's consolidated batch has to be identified, pulled out, and issued as its own individual e-Invoice instead — with the buyer's actual details, not the "General Public" placeholder HASiL permits for consolidated submissions to buyers who have not requested an e-Invoice.
The buyer-request path works on its own clock too
Separately from the RM10,000 threshold, a buyer who has not been issued an individual e-Invoice can still ask for one — but only within the month of the transaction. HASiL's guideline treats a request made after month end as one the supplier may decline, on the basis that the transaction has already been aggregated into that month's consolidated submission. A Business Central configuration that accepts ad hoc buyer requests for individual e-Invoices needs the same discipline as the RM10,000 test: a clear cut-off tied to the posting date, not an open-ended promise to reissue anything a customer asks for weeks later.
Not the only category — but the one every business meets
HASiL's guideline lists several industries and activities where consolidation is never allowed regardless of value — motor vehicle sales, flight tickets and private charter, construction contracts, payouts to betting and gaming winners, and payments to agents, dealers or distributors, among others. Those categories apply to specific sectors. The RM10,000 threshold is different: HASiL's guideline applies it to all industries, which is why it is the condition almost every Business Central user configuring e-Invoice will need to build for, regardless of what the business sells.
Where the RM10,000 test has to run inside Business Central
A consolidated e-Invoice workflow typically works from posted sales invoices or receipts accumulated across a month. For the RM10,000 rule to be enforced reliably, the test has to run before that monthly aggregation happens — evaluating the value of each individual transaction as it is posted, not after a month's population has already been batched together. Waiting until month end to check the rule means finding the exception after the batch has already been assembled, which is a rebuild rather than a filter. In SCSB’s implementation work, this is the single design choice that most often separates a workflow that holds up from one that needs reworking in its first reporting cycle.
The practical design question is which value the test reads. HASiL's guideline speaks in terms of a single transaction's value; a Business Central configuration needs a documented, tested answer for what constitutes "a transaction" in the organisation's own invoicing pattern — one posted sales invoice, one sales order, or one customer's activity across a period — because that definition is what a filter or exception report actually has to be built against. Where this is genuinely unclear against the business's own facts, HASiL's current guideline is the reference to confirm it against, not an assumption carried over from a previous system.
The master data an individual e-Invoice needs that a consolidated one does not
A consolidated e-Invoice, issued to "General Public", needs almost none of the buyer's actual details — HASiL's guideline has the supplier enter fixed placeholder values for most buyer fields. An individual e-Invoice, once a transaction is routed out of consolidation, needs the buyer's real name, Tax Identification Number, registration or identification number, address, and the three-digit product or service classification against HASiL's own catalogue.
This is where the RM10,000 rule most often stalls a configuration in practice: a transaction crosses the threshold, gets correctly flagged for individual treatment, and then fails validation anyway because the buyer's TIN was never captured at the point of sale — a gap that a purely consolidated workflow would never have exposed, because consolidated submissions do not need that data. Deciding, before go-live, which transactions are likely to need buyer-level data captured at the point of sale — rather than reconstructing it afterwards under time pressure — is a design decision, not an afterthought.
Correcting a transaction after it crosses the line
Once an individual e-Invoice has been validated, HASiL's platform allows the supplier to cancel it, or the buyer to request its rejection, only within 72 hours of the validation timestamp; after that window, correction has to go through a new credit note, debit note or refund note submitted as its own validated document. Microsoft's own documentation on correcting or cancelling a posted sales invoice describes separate rules tied to whether the invoice has been paid or shipped — rules that have nothing to do with HASiL's 72-hour clock and do not automatically stay in step with it. A transaction that crossed the RM10,000 line, was correctly issued individually, and then needs a price correction has to be corrected in a way that satisfies both clocks, not just Business Central's own.
Reconciliation: proving the population was split correctly
The control that actually matters here is not the individual e-Invoice count or the consolidated batch total on their own — it is the reconciliation between them. A defensible workflow can show, for any given month, that every posted sales invoice above RM10,000 appears as an individual e-Invoice, that every invoice at or below the threshold appears somewhere in a consolidated batch (unless another exclusion applies), and that nothing has been missed or duplicated between the two routes. Building that reconciliation as a standing report, rather than a one-off check performed under deadline pressure, is what turns the rule from a manual judgement call into something the business can actually evidence.
A rule that has already moved once
HASiL introduced this restriction in an earlier version of its e-Invoice Specific Guideline and has carried it forward through subsequent revisions, including the version current at the time of writing. That history is itself the reason to route a Business Central configuration through a single, clearly owned mapping — a filter value, a report parameter, a threshold field — rather than hard-coding RM10,000 in several places across the workflow. A rule that has already been revised once is a rule that can be revised again, and a configuration built around one changeable value is far cheaper to update than one where the figure is scattered through custom reports, saved views and someone's memory.
Decisions to settle before configuration starts
- What counts as "a transaction" for the RM10,000 test, against the organisation's own invoicing pattern — confirmed against HASiL's current guideline, not assumed.
- Where the threshold value is held in Business Central, so it can be updated in one place if HASiL revises it again.
- How buyer-level data is captured for transactions likely to cross the threshold, rather than reconstructed after the fact.
- How the 72-hour correction window is tracked against Business Central's own invoice correction rules for transactions issued individually.
- What standing reconciliation proves that every posted invoice landed in the correct route — individual or consolidated — each month.
A business with a narrow product range, predictable transaction values and few, if any, sales above RM10,000 may find this a straightforward one-off configuration. The case for implementation support grows where transaction values vary widely, where several systems or branches feed the same consolidated submission, or where existing customer records were never built to capture the data an individual e-Invoice requires.
What to do next
Confirm the current RM10,000 condition, and any other transaction category that requires individual treatment, directly against HASiL's current e-Invoice guidelines before relying on this article or any other secondary summary. Where the organisation has confirmed it needs this routing configured inside Dynamics 365 Business Central, the SAC E-Invoice App can be discussed within an agreed implementation scope.
General-information limitation
This article is general technical information about e-Invoice workflow design concepts in Dynamics 365 Business Central. It is not tax, legal or accounting advice, does not determine any organisation's e-Invoice obligations, and does not confirm that a particular configuration meets HASiL's current requirements. HASiL's guidelines and thresholds, MyInvois platform behaviour, and Business Central's own functionality are set by their respective publishers and are revised over time — as this threshold itself has already been. Confirm the current position against HASiL's published material before implementation.
Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.