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 must be reviewed when a threshold, exception or submission rule changes.
Separate the platform, the app and the approved treatment
The standard Business Central document lifecycle, Microsoft’s generic e-document framework and the installed SAC E-Invoice App are different layers. Documentation for one layer does not prove the fields, submission route, status transitions or recovery behaviour of another. Record the actual app and Business Central versions, configured document types, identity mappings and accepted test cases before relying on a workflow.
Keep the organisation’s approved HASiL treatment alongside that technical record. Configuration testing should establish what the installed solution does with the approved inputs; it should not be used to infer the tax or legal conclusion.
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. Accurate mapping is essential to validation, alongside a supported app version, complete data, appropriate access and a functioning submission service.
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: the applicable supplier and buyer identifiers, contact information and transaction details. Map supplier MSIC and line classification separately, and apply the required fields and permitted alternatives for each buyer category. 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", can cause a submission to fail — not a defect in Business Central, and not a defect in MyInvois, but a data-entry gap between the two.
Treat this as a data-readiness exercise: confirm the mapping, assign owners for keeping data current, and test with authorised, representative records. Use minimised or masked data where practical, including the formats and exceptions the production workflow must handle.
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. Distinguish submission deadlines from validation response time. Design individual issuance and any permitted monthly consolidation around the applicable requirements, with status checks for delayed or failed validation — 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. These failures may arise from source data, mapping, app behaviour or validation rules. Inspect the actual error and transmitted payload before assigning the cause.
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 direct correction or cancellation of an unpaid posted sales invoice when it is not fully shipped. After partial or full payment, Microsoft directs users to a manually created sales credit memo, optionally through a sales return order. For other cases outside direct correction or cancellation, review the documented Create Corrective Credit Memo route. These Business Central conditions are separate from HASiL’s 72-hour cancellation window, and the two workflows 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 choosing the appropriate cancellation or adjustment route in both systems and reconciling the result. A ledger-only reversal must not leave an incorrect validated MyInvois record unaddressed. 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 low-volume business may use MyInvois directly. A workflow integrated with Business Central still needs a suitable app or integration and tested mappings, even if little custom development is required. 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.