The route is chosen twice, and the second choice is the binding one
The Inland Revenue Board of Malaysia (HASiL) provides two transmission mechanisms for submitting an e-Invoice to MyInvois: the MyInvois Portal, and an application programming interface (API) that connects a taxpayer's own system directly to the MyInvois system. HASiL's own developer material, published on the MyInvois software development kit site, documents the API route in detail, including authentication, document submission, and the digital signature each submitted document has to carry. The decision framework that usually follows is familiar enough: low document volume points to the Portal, high volume points to the API, and a service-provider route sits somewhere between them.
That framing is not wrong. For an organisation already running Dynamics 365 Business Central, it simply answers the wrong question first. Volume decides which route an organisation would prefer. The deployment's existing electronic-document configuration decides which routes it can reach without rebuilding the way it already sends documents. Those two answers are often different, and the second one sets the project's real scope.
Malaysia sits on the partner-led side of Microsoft's localisation model
Microsoft's documentation on local functionality and localisation strategy states that Business Central has a combined localisation strategy covering both Microsoft-led and partner-led models, and then lists the countries and regions where Microsoft itself provides the regulatory compliance functionality. Malaysia is not on that list. Microsoft's separate e-documents overview lists the e-invoicing localisations Microsoft currently supports, and Malaysia is not among those either; that page directs readers to the marketplace for non-Microsoft localisations.
This is not a gap to be worked around. It is the design premise. The framework Microsoft ships is deliberately generic, and Malaysian behaviour is expected to arrive through an app installed on top of it. SCSB therefore treats any statement about what Business Central does for MyInvois as a statement about what has actually been installed and configured in one specific environment, not about the product in general.
Without an installed connector, the service produces a file rather than a route
Microsoft's guidance on setting up e-documents requires the E-Document Core app to be installed, and then an E-Document Service to be created. On that service, the Document Format field selects the export format, and the Service Integration field selects the connector. Microsoft's own field description is blunt about the starting position: the only option is No integration. Further down the same page, the option to configure authentication and connection settings for an integration connector is described as available only when integration connectors are installed.
Read together, those two statements describe the constraint the generic decision guides never mention. A deployment carrying the core framework and no connector app can generate an electronic document. It cannot transmit one. Choosing the API model in a planning workshop does not create a route; installing and configuring something that implements the route does. Microsoft's guidance on connecting to external endpoints confirms the same sequence, and adds that Microsoft has no contractual obligations with the access-point providers whose connectors it lists, so credentials and commercial terms are arranged separately with whichever provider is chosen.
The Document Sending Profile is a switch between two generations, set customer by customer
Business Central has carried Document Sending Profiles for a long time, and most established deployments already use them. Microsoft's documentation on preferred methods of sending sales documents describes a profile selected in a field on the customer card, with one profile able to be marked as the default for every customer where no other profile is named.
The e-document setup guidance then adds the part that matters here. To use the current framework, the profile's Electronic Document field has to be set to Extended E-Document Service Flow, and an enabled E-Document Workflow has to be named; Microsoft states that the workflow field is required when that option is selected. A profile left configured any other way keeps that customer on the earlier electronic-invoicing behaviour instead.
Two consequences follow, and both are scoping consequences rather than technical ones. First, the change is made per profile, and profiles are assigned per customer, so an organisation that has assigned different sending profiles to different customer groups is facing a customer-population change rather than a single setting change. Second, Microsoft states that two services cannot use the same document sending profile in workflows, which means running two routes in parallel during a transition requires the customer populations to be separated by profile before either route is switched on.
One caution on Microsoft's e-document setup page: Microsoft's step-by-step instructions tell administrators to set the Printer, Email and Disk options to No, while a table immediately below describes combined sending in which email and e-document options are used together. Confirm the current behaviour against Microsoft's documentation and test it in a sandbox before designing a transition around either reading. This article does not resolve that difference.
A clearance-shaped route is a framework, not a feature
MyInvois validates a submitted document and returns an identifier for it, which makes the Malaysian arrangement clearance-shaped in the sense Microsoft uses that term. Microsoft's statement about clearance support is unusually direct: because the model differs between countries and regions, support for it in Business Central is a framework only, and an extension meeting the local requirements has to be created and used in the e-document service setup.
The structural consequence shows up in the setup itself. When the Is a Clearance field is selected, Microsoft states that the service sends the invoice only to the tax authority for clearance, and that another service must be configured to deliver the cleared invoice to the customer, together with a workflow supporting both the clearance step and the delivery step. Microsoft also notes that the clearance model cannot be used until a dedicated service integration has been chosen.
A clearance-shaped route is therefore not one service with a different setting. It is two services and a multi-step workflow, resting on an extension that implements the authority's rules. An implementation plan that budgets for a single connection has mis-scoped the work before it begins.
Party identification is a mapping decision, not a field
Microsoft's external-endpoint guidance lists the Company Information fields the framework expects to be completed before e-documents are used, including VAT Registration No. and GLN, along with a setting controlling whether the GLN is used in electronic documents as a party identification number. Customer cards carry the equivalent. That identity model is oriented towards network-based exchange between trading parties.
The identifiers HASiL requires for a Malaysian submission are set by HASiL, are documented on the MyInvois SDK site, and are not the same set. Where the two differ, reconciling them is design work inside the connector or extension, not data entry into a standard field. Confirm the current identifier requirements against HASiL's published material rather than assuming the framework's default fields carry them.
Decisions to settle before choosing an integration model
- Whether the E-Document Core app and any integration connector are installed at all in the target environment, since that determines which routes are reachable before any preference is expressed.
- Which Document Sending Profiles exist today, which customers are assigned to each, and which of those assignments would have to change to move onto the current framework.
- Whether the intended route is clearance-shaped, and if so which service performs clearance, which performs delivery, and which workflow sequences both.
- How supplier and buyer identifiers map from the standard company and customer fields onto the identifiers HASiL requires, and where that mapping is maintained when a new customer is created.
- How long e-document records are kept, given that Microsoft exposes retention policies for the E-Document Log, Integration Log, Mapping Log and Data Storage, and whether that period matches the organisation's own record-retention position.
- Which documents remain outside the automated route and will still be issued manually, and how that population is reconciled so nothing is issued twice or not at all.
When an organisation may not need implementation support
HASiL provides the Portal for taxpayers who need to issue documents where an API connection is unavailable. For an organisation issuing a modest number of documents each month from a single entity, with a stable customer list and no requirement to originate the document inside the accounting system, entering them directly through the Portal may be entirely proportionate, and the integration decision can reasonably be deferred.
The case for integration work strengthens on quite specific triggers rather than on volume alone: multiple legal entities issuing under different identifiers, sales documents that already originate in Business Central and would otherwise be re-keyed, correction and cancellation traffic that has to stay reconciled with the ledger, or an existing sending configuration that would silently keep part of the customer base on the older behaviour. Where none of those applies, an organisation with capable internal finance-systems staff can reasonably work directly from Microsoft's documentation and HASiL's published material.
What to do next
Confirm the current MyInvois requirements, submission rules and identifier specifications directly against HASiL's published material at hasil.gov.my and the MyInvois SDK site before relying on this article for anything beyond workflow design. Where the requirement is to connect a Dynamics 365 Business Central deployment to MyInvois, the SAC E-Invoice App can be discussed within an agreed implementation scope.
General-information limitation
This article is general technical information about integration design concepts for Dynamics 365 Business Central and MyInvois. It is not tax, legal or accounting advice, does not determine any organisation's e-Invoice obligations, timing or eligibility, and does not confirm that a particular configuration satisfies HASiL's current requirements. Microsoft's e-document framework has been revised across release waves and continues to develop, so treat the field and option names above as a description of the mechanism rather than a fixed menu, and confirm them against Microsoft's documentation before implementation.
Dynamics 365 Business Central and Microsoft are trademarks of the Microsoft group of companies.