Two different questions sit behind one search
"How does e-Invoice work in Dynamics 365 Business Central" is not the same question as "does my business need to issue e-Invoices". The Inland Revenue Board of Malaysia (HASiL) answers the second question, through its own e-Invoice guidelines and the MyInvois programme. This article answers the first question: what happens inside Business Central once an organisation has confirmed, from HASiL's current guidance, that it needs to configure e-Invoice submission.
That distinction matters because the two questions have different owners. Applicability — phase, exemption, turnover, transaction type — is a HASiL determination that changes as HASiL revises its guideline. Configuration — master data, document lifecycle, validation, correction — is a Business Central design decision that SCSB and its clients control directly, and that does not change just because a threshold moves.
What Business Central does not decide
Dynamics 365 Business Central can hold, structure and submit the records a configured e-Invoice workflow needs. It does not decide whether a transaction is in scope, does not interpret HASiL's guideline, and does not resolve a disputed tax position. Microsoft does not publish a Malaysia-specific e-Invoice guide for Business Central: Business Central's own local functionality documentation lists Microsoft-led compliance functionality for a defined set of countries, and Malaysia is not among them. Malaysia falls under what Microsoft describes as "other markets" served through partner-built localisation apps found on Microsoft AppSource — which is why organisations correctly find implementation partners, rather than a Microsoft manual, when they ask the configuration question.
That is a fact about ownership, not a limitation to apologise for. It means the mapping between a HASiL data requirement and a Business Central field is deliberate implementation work, done by someone who understands both the guideline and the platform — and it means the quality of that mapping determines whether submissions clear validation, not the licence tier or the product version.
The master data an e-Invoice depends on
HASiL's e-Invoice Specific Guideline sets out the data fields a validated e-Invoice must carry for the buyer and the supplier: name, Tax Identification Number (TIN), registration or identification number, address, contact number, SST registration number where applicable, Malaysia Standard Industrial Classification (MSIC) code, and a description of the product or service classified against HASiL's own three-digit classification catalogue. Where an e-Invoice is issued to the general public rather than a specific buyer, HASiL's guideline specifies a fixed placeholder — the buyer name "General Public" and the general TIN reserved for that purpose — rather than a blank field.
Inside Business Central, most of that data already exists somewhere: on the Customer card, the Vendor card, the Company Information page, or an item's classification fields. The configuration question is whether it exists in the right field, in the right format, and whether it is actually populated before a document reaches the point of submission. A customer record created quickly at the counter, with the tax fields left blank "to fix later", is the single most common reason a submission fails — not a defect in Business Central, and not a defect in MyInvois, but a data-entry gap between the two.
SCSB's implementation practice is to treat this as a data-readiness exercise before it is a configuration exercise: confirm which master data fields map to which HASiL requirement, decide who owns keeping them current, and test the mapping against real customer and item records — not specimen data — before a workflow goes live.
Where submission sits in the document lifecycle
A Business Central sales document moves through a lifecycle: quote or order, shipment, and posting to a posted sales invoice. HASiL's own guidance describes near real-time validation, in the order of a few seconds, once a document is submitted to MyInvois — whether through the MyInvois Portal, the MyInvois Mobile App, or a direct API integration. That timing has a direct configuration consequence: submission has to be tied to a point in the Business Central lifecycle that represents a final, unambiguous transaction, which in practice means the posted sales invoice rather than an editable order or quote.
Consolidated e-Invoices work on a different rhythm. Where a buyer has not requested an individual e-Invoice, HASiL's guideline allows a supplier to aggregate the month's transactions into a consolidated submission within seven calendar days after month end, using receipts rather than individual e-Invoices as the working record until that point. A workflow therefore has two clocks running against each other — near-real-time validation for individual e-Invoices, and a monthly batch cut-off for consolidated ones — and the configuration has to route each transaction to the correct clock rather than defaulting every transaction to one path.
What an invalid submission actually looks like
The categories of failure follow directly from the required fields: a Tax Identification Number that does not match HASiL's records, a missing or incorrectly formatted registration number, an MSIC or classification code that has not been mapped to HASiL's current catalogue, or a buyer record missing a required field entirely. None of these are failures of the MyInvois system or of Business Central; they are the predictable consequence of source data that was never validated against the guideline's requirements.
The practical response is upstream, not downstream. A workflow that only discovers a bad TIN at the point of submission has already cost someone time chasing the correction. A workflow that validates the customer or vendor record when it is created, or before it is used on a document destined for e-Invoice submission, catches the same error earlier and cheaper. This is a design decision made once, during configuration, rather than a habit imposed on every user afterwards.
The 72-hour window, and why it does not match Business Central's own model
Once MyInvois has validated an e-Invoice, 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, neither party can cancel or reject the document through MyInvois; any correction has to be made through a new credit note, debit note or refund note submitted as its own validated e-Invoice.
Business Central has its own, separate model for correcting a posted sales invoice. Microsoft's documentation on correcting or cancelling a posted sales invoice allows a full cancellation or correction only where the invoice is unpaid and not fully shipped; once it has been paid, or shipped in full, the only route is a manually created sales credit memo. Neither of Business Central's internal timing rules has anything to do with HASiL's 72-hour clock, and the two do not automatically stay in step.
The practical implication: a finance team that cancels a posted invoice in Business Central after the 72-hour MyInvois window has closed has changed its own ledger without changing what HASiL holds as the validated record. The workflow needs a deliberate check — has 72 hours passed on the MyInvois side — before deciding whether the correction is a Business Central-only reversal or requires a fresh credit note submitted to MyInvois as well. Leaving this to memory is how a ledger and a regulator's record quietly drift apart.
Reconciliation: what should tie back to what
A configured workflow is only as trustworthy as the reconciliation behind it. At minimum, that means comparing the population of posted sales invoices for a period against the population actually submitted to MyInvois — individually and, separately, within consolidated batches — and investigating any variance rather than assuming the totals will match. It also means retaining evidence: which guideline version was current when a mapping decision was made, who approved a change to a classification code, and what the validated MyInvois response actually said, rather than relying on the posted invoice alone as proof that submission succeeded.
Decisions to settle before configuration starts
- Which master data fields map to which HASiL requirement, and who owns keeping them accurate.
- The trigger point for submission — posted invoice, not order or quote — and how consolidated batches are assembled separately.
- How a missing or invalid Tax Identification Number is caught, and by whom, before a document reaches submission.
- How the 72-hour cancellation window is tracked against Business Central's own correction rules, so the two do not silently diverge.
- What evidence is retained to reconcile the posted invoice register against submitted e-Invoices, and who reviews it.
Not every organisation needs a bespoke build to answer these. A single-entity business with clean customer records and a low transaction volume may configure this directly from HASiL's own guideline and Business Central's standard document flow. The case for outside implementation help grows with transaction volume, multiple entities or branches, legacy customer data that has never been validated against HASiL's field requirements, or an existing consolidated-billing pattern that now needs to route some transactions individually.
What to do next
Confirm the current applicability position directly from HASiL's e-Invoice guidelines before configuring anything — that determination sits with HASiL, not with this article or with Business Central. Where the organisation has confirmed it needs an e-Invoice workflow 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 configuration 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, MyInvois platform behaviour and Business Central's own functionality are set by their respective publishers and change over time. Confirm the current position against HASiL's published material and Microsoft's current Business Central documentation before implementation.
Dynamics 365 Business Central, Microsoft, and Microsoft AppSource are trademarks of the Microsoft group of companies.