Start with the taxpayer’s regime, then choose the transaction route
Under the ordinary rules in HASiL’s e-Invoice Specific Guideline v4.9, issued 7 September 2026, a single transaction above RM10,000 falls within the restriction on consolidated e-Invoices from 1 January 2026. However, section 16 permits qualifying taxpayers to use consolidated e-Invoices during their applicable interim relaxation period, subject to its conditions. Establish the taxpayer’s applicable regime before using the threshold as an unconditional routing rule.
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 to design and test a Dynamics 365 Business Central routing control against the organisation’s approved requirements. The installed app and configuration must be checked before any automated enforcement is assumed.
What "consolidation is not allowed" actually requires
Subject to the applicable transaction and interim-relaxation rules, 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.
Where the ordinary restriction applies, 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
Under the ordinary rules, 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 underlying transaction date, not an open-ended promise to reissue anything a customer asks for weeks later.
Value is only one routing condition
Outside applicable interim relaxation or other concessions, HASiL’s guideline lists several industries and activities where consolidation is not 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 ordinary RM10,000 restriction applies across industries. The workflow should first record the taxpayer’s applicable implementation and relaxation position, then apply the transaction rules for that position.
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. Check each transaction before it enters a consolidated submission. This can be a posting control or a tested pre-submission review, provided applicable individual-issuance requirements are met. Record the routing decision before consolidation and review any late changes before submission as part of the exception review.
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 interpretation of the relevant transaction under HASiL’s rule, applied to the organisation’s invoicing pattern — 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
An individual and a consolidated e-Invoice do not use the same buyer-data rules. Map the required identifiers and other fields against the current guideline for the buyer category and transaction. Do not replace every individual buyer’s information with consolidated “General Public” values, or insist on the same TIN and identification-number combination for every category: the current Specific Guideline includes particular concessions for individual buyers.
Before go-live, test how the required information is obtained, validated, corrected and retained with appropriate access. A transaction may be routed correctly but remain unresolved because the applicable buyer information is missing. Assign that exception to an owner rather than silently returning it to consolidation.
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 reconciles every in-scope transaction to the route required or permitted for that taxpayer and period. Outside applicable relaxation, this includes checking transactions above RM10,000 for individual treatment. Lower-value transactions may also require individual treatment, including where a buyer requests it or another restriction applies. Nothing should be omitted or duplicated. 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.
Keep a routing decision record
- Entity and period: identify the supplier, transaction date and the implementation or exemption position approved by the organisation and its advisers.
- Applicable concession: record whether an interim relaxation applies, its conditions and end date, with the exact guideline version or later authority clarification relied on.
- Transaction route: document the ordinary value, activity and buyer-request rules that apply, and any permitted alternative under that regime.
- Required data: record the buyer category, identifier rules and fields needed for the chosen route.
- Evidence: keep the original transaction reference, routing result, submission status and reconciliation record, with an exception owner.
Test transactions below, at and above any approved threshold, a buyer request, a restricted activity and the end of any applicable relaxation. Expected results must come from the approved regime. This is a test design, not a statement that every taxpayer must follow the same route.
Keep the rule in one controlled mapping
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
- Which ordinary or interim-relaxation regime applies to the taxpayer and period, and what counts as a transaction under that regime, confirmed against HASiL’s current guideline.
- 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 predictable transactions may need only a limited configuration, with periodic review of rules, concessions, buyer requests and new transaction types. 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.