Microsoft began staged licence validation for Dynamics 365 finance and operations applications on 15 January 2026. For customers reaching a contract renewal or anniversary after that date, licence assignments, security roles and user access now need to align more visibly than before. (source: microsoft)
That is a licensing change. It also points to a wider reality for organisations planning a multi-country Dynamics 365 implementation: Microsoft Dynamics 365 Finance, enterprise resource planning, legal-entity design, localisation and governance cannot be treated as separate decisions.
A single-entity ERP deployment can be demanding. A multi-country F&O project carries a different level of operational responsibility.
The short version is this. A well-designed Dynamics 365 Finance rollout starts with the group operating model: legal entities, local statutory requirements, finance controls, reporting boundaries, user access and data ownership. The projects that become difficult are often the ones that treat those decisions as configuration details to settle after build has begun.
What changed, and why does it matter now?
Microsoft’s licence validation is designed to help customers align users’ assigned licences with the security roles, duties and privileges they use in finance and operations applications. Microsoft directs organisations to review role-to-licence mappings and licence-usage reporting, then assign the correct licences through the Microsoft 365 admin centre. (source: microsoft)
The immediate consequence is clear: a user without the required assigned licence can lose access until that assignment is corrected.
The broader consequence matters more.
In a single-country deployment, a limited set of finance users may work within one operating model, one primary regulatory context and a contained approval structure. In a multi-country group, access and control decisions extend across legal entities, business units, currencies, local requirements and shared-service functions.
Dynamics 365 Finance changes that model completely.
The issue is not only whether users can access the system. It is whether every user has access that matches their role, entity responsibilities and required licence, and whether the organisation can evidence that design when auditors, finance leadership or operational teams ask why it exists.
What does a multi-country F&O rollout involve?
- Legal entities. A legal entity is an organisation identified through registration with a legal authority and is represented separately within the ERP structure. A multi-country project must decide where entities operate independently, which processes are standardised, and how shared services interact with local finance teams.
- Financial controls. Finance design needs to establish the chart of accounts, financial dimensions, approval paths, period-end controls, intercompany rules and consolidation requirements. These are not solely finance-team decisions. They establish the operating model that procurement, sales, supply chain and leadership reporting will rely on.
- Currencies. Multi-currency processing introduces decisions about accounting currency, reporting currency, exchange-rate governance, revaluation and how group leadership compares results across entities. These choices need consistent ownership before the organisation starts building reports around them.
- Localisation. Microsoft Dynamics 365 Finance includes country- and region-specific functionality. Microsoft states that customers enable relevant functionality based on the primary address of the active legal entity, while the Product localisation and translation availability guide identifies country and regional support. (source: learn.microsoft)
- Security roles. Security roles define what a user can do, while licence requirements depend on the privileges provided through those roles. This is why Microsoft’s licence-validation change is not merely an IT administration task; it requires finance, operations and system ownership to agree on who should perform which work in each legal entity. (source: microsoft)
- Reporting. Group reporting needs a clear answer to a simple question: which figures are local operational records, and which are the group’s controlled management view? Without that answer, every country can produce a technically valid report while leadership still lacks a comparable one.
How does a multi-country F&O rollout differ from a single-country ERP deployment?
| Decision area | Single-country ERP deployment | Multi-country Dynamics 365 Finance rollout |
|---|---|---|
| Legal structure | Often one principal legal entity | Multiple entities with separate registrations, operating responsibilities and controls |
| Finance model | Local chart, dimensions and reporting requirements | Group standards alongside country-specific finance and reporting needs |
| Currency | Primarily one operating and reporting currency | Accounting, reporting, transaction and consolidation currency decisions |
| Compliance | One main tax and statutory environment | Local requirements, regional functionality and jurisdiction-specific reporting |
| Access | A contained user population and approval model | Entity-aware roles, segregation of duties and licence governance across teams |
| Period end | One close process | Local close, consolidation, reconciliations and group reporting timetable |
| Ownership | Primarily local finance and IT | Defined group ownership with local accountability |
This does not mean every multi-entity organisation needs F&O. It means the product decision should follow operational complexity, not organisational ambition or a generic ERP feature checklist.
A group that works across countries, operates multiple legal entities, consolidates financial performance and carries local reporting obligations should assess its finance operating model before selecting the delivery approach.
What do you need before implementation?
A multi-country Dynamics 365 Finance project needs a design baseline before detailed configuration begins.
- Operating model. Define which processes are global, which are local and who owns exceptions. This includes purchasing, sales, inventory, fixed assets, cash management, financial close and management reporting.
- Legal-entity inventory. Create a current list of legal entities, registrations, operational countries, functional currencies, reporting currencies and statutory obligations. An organisation cannot configure what it has not agreed to represent.
- Chart and dimensions. Agree the group chart of accounts, financial-dimension logic and entity-specific extensions. The aim is not to force identical structures everywhere. It is to make group reporting reliable without preventing legitimate local compliance.
- Localisation review. Check Microsoft’s available country and region functionality against each in-scope entity’s requirements. This should cover tax, electronic documents, statutory reports, banking formats and relevant local processes. (source: learn.microsoft)
- Security and licensing. Review roles, duties, privileges and licence assignments together. Microsoft’s documentation makes clear that organisations should use its reporting to identify mismatches and ensure users receive the appropriate licences. (source: microsoft)
- Control model. Establish approval limits, segregation of duties, period-close responsibilities, audit evidence and escalation paths before roles are configured at scale.
There is no responsible universal licence count or implementation timeline to publish without knowing the entity structure, modules, users, country scope and operating model. Those are project inputs, not post-purchase details.
What should you fix first?
Fix the legal-entity and control model first.
Many projects begin with process workshops and screen demonstrations. Both have value. But the harder questions usually sit beneath them: who owns a supplier record used in more than one country; who can create, approve and pay a transaction; what changes when a shared-service team operates on behalf of another entity; and where does local authority end?
Those are operating-model decisions.
Done properly, they become a practical blueprint for finance configuration, security, reporting and testing. Done late, they become exceptions, manual workarounds and increasingly difficult conversations during user acceptance testing.
Start with a controlled inventory of:
- Legal entities and countries in scope
- Finance-process owners for each entity
- Local statutory and tax requirements
- Group reporting and consolidation needs
- Role, approval and segregation-of-duties requirements
- Current licences and future user populations
- Shared-service responsibilities and local exceptions
What is still coming from Microsoft?
Microsoft’s 2026 release wave 1 covers functionality planned for release from April to September 2026. The published Finance and Operations plan includes ongoing work across finance, supply chain management and cross-app capabilities, including improvements intended to connect finance and operations applications more closely with the wider Dynamics 365 platform. (sources: learn.microsoft + learn.microsoft)
That roadmap does not replace foundational design work.
New functionality is valuable when the core model is clear: legal entities are properly defined, local requirements have been assessed, access is governed and finance leadership trusts the reporting structure. Without those foundations, additional capability can add options without solving the operating problem.
How Braintree helps
Braintree runs this as a structured review, starting with the group operating model and legal-entity landscape, then mapping the finance controls, localisation and reporting requirements, then identifying the licensing, security and governance decisions that need resolution before build begins.
The purpose is not to produce a generic transformation presentation. It is to give finance and technology leadership a shared view of the decisions that distinguish a workable F&O rollout from a collection of disconnected entity deployments.
Talk to us about a multi-country Dynamics 365 Finance review, and we will start with your operating model, not a slide deck.
Specialists in Business Applications, Modern Workplace and Azure. Let’s grow.
Frequently asked questions
What makes a Dynamics 365 Finance rollout more complex than a Business Central implementation? Dynamics 365 Finance is typically assessed where the organisation has more complex legal-entity, financial-control, operational and country requirements. The complexity comes from the combined design of entities, intercompany processes, currencies, security, localisation, reporting and governance, and not from one feature alone.
What does a multi-country Dynamics 365 deployment need that a single-country deployment does not? A multi-country deployment needs defined legal-entity boundaries, local statutory and tax requirements, multi-currency rules, group reporting, intercompany design, country-aware access controls and a clear model for global standards versus local exceptions.
How does Dynamics 365 Finance support country-specific requirements? Dynamics 365 Finance includes country and region functionality. Microsoft states that the functionality is enabled based on the active legal entity’s primary address, with localisation resources available for supported countries and regions. (source: learn.microsoft)
What are legal entities in Dynamics 365 Finance? Legal entities represent organisations registered with legal authorities. They allow a group to operate distinct finance, tax, reporting and transaction structures within a shared Dynamics 365 Finance environment.
Why do security roles matter in F&O licensing? Microsoft’s licence requirements are linked to the privileges users receive through their roles. Licence governance therefore requires organisations to review security roles, duties, privileges and assigned licences together. (source: microsoft)
Can Dynamics 365 Finance and Business Central operate in the same group? Potentially, yes. The group needs explicit boundaries for master data, consolidation, intercompany processes, reporting and responsibility. The decision should be based on the requirements of each entity and the group’s operating model, rather than treating the applications as interchangeable.
What should a group standardise before a multi-country ERP rollout? Groups should standardise the areas that support reliable control and reporting: chart-of-accounts principles, financial dimensions, master-data governance, approval controls, close processes, reporting definitions and security-policy principles. They should also identify where country-specific requirements legitimately require variation.
