Establishments in D365 Finance 10.0.48: One Legal Entity, Many Identities, No More Multi-LE Workarounds
If you have ever stood up a separate French legal entity in D365 F&O just to hold a second SIRET, this article is for you. Microsoft has finally given us the architectural primitive we should have had years ago.
It is called Establishments. It ships in Dynamics 365 Finance version 10.0.48 (preview April 2026, GA self-update June 2026, GA auto-update July 2026, build 10.0.2645). And it changes how you should be modelling multi-site, multi-registration, multi-branch businesses inside a single legal entity.
Here is the truth. Most consultants and product owners have been working around the absence of this feature for years. We invented financial dimension hacks. We spun up phantom legal entities. We built clunky reporting layers to roll subsidiary numbers back together at month-end. None of that is needed any more.
This is the no-BS guide to what Establishments actually does, what else it unlocks beyond the headline SIRET use case, and how to decide whether you should model your next location as an establishment, an operating unit, or a separate legal entity.
The problem Establishments fixes
Plenty of businesses have one legal entity that operates from many locations. Each location may need its own regulatory identifier on every invoice it issues or receives. France is the famous example: every establishment of a French company has its own SIRET, and electronic invoices submitted via the French e-invoicing reform must carry both the SIREN (legal entity) and the SIRET (establishment).
The same pattern shows up across Europe. Many EU jurisdictions support multiple VAT registrations under a single legal entity. Microsoft Learn lists Austria, Belgium, Czechia, Denmark, Estonia, Finland, France, Germany, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Spain, and Sweden as supported markets for the multiple VAT registrations framework. Branch ID is a recognised registration category in its own right. EAN location codes are used in Denmark. Italy uses fiscal codes (codice fiscale) alongside P.IVA, with the multi-VAT-registration framework covering local sub-registration scenarios.
Until 10.0.48, D365 Finance had no clean way to attach a registration ID to anything smaller than the legal entity itself, except by abusing addresses or financial dimensions. That left two bad options.
Option one: spin up a separate legal entity for every operational location. You inherit a new DataAreaId, a new chart-of-accounts mapping (or you replicate the existing one), new intercompany configuration, new period-close work, and new licensing implications. For a CFO or programme sponsor, that is not a configuration choice. It is a permanent operational tax.
Option two: glue everything together with financial dimensions and pray. The legal entity holds one VAT ID. You filter reports by dimension. Your invoices show the wrong registration number, your statutory filings are a manual reconciliation, and your auditor asks awkward questions every year.
Neither option is good. Establishments is the third option that should have existed all along.
What Establishments actually is
Per the Microsoft Learn page on organisations and organisational hierarchies, an establishment is “an operational unit of a legal entity that carries out economic activity on a stable basis and might require its own regulatory identifiers, such as registration numbers used on invoices and regulatory reports.”
The mechanics are clean. You model establishments using existing operating units. You then include those operating units in an organisational hierarchy with a new dedicated purpose called “Enterprise establishment structure”. Only operating units that sit inside such a hierarchy are treated as establishments by the system. The legal entity remains the sole legal and accounting entity. The establishments inherit the legal identity but can carry their own operational identity for invoicing and regulatory purposes.
To turn it on, enable the “Establishment and Registration ID governance on invoices” feature in Feature management. With the feature off, none of the establishment-specific behaviour applies, which gives you a clean fallback during rollout.
The setup sequence is short and worth getting right:
1. Enable the “Establishment and Registration ID governance on invoices” feature in Feature management.
2. Create one operating unit for each location you want to treat as an establishment (Organization administration > Organizations > Operating units). Any operating unit type works — the establishment role is conferred by the hierarchy, not the operating unit type.
3. Create or extend an organisational hierarchy and assign it the “Enterprise establishment structure” purpose (Organization administration > Organizations > Organization hierarchies, then Assign purpose).
4. Add the operating units from step 2 into the hierarchy from step 3. Only operating units inside that hierarchy are recognised as establishments.
5. Assign the relevant Registration IDs (SIRET, VAT, Branch ID, EAN, etc.) to each establishment’s address.
Once those steps are complete, the Establishment field appears on every document that can post an invoice:
- Free text invoices
- Sales orders
- Purchase orders
- Vendor invoices
- Pending vendor invoices
- Project invoice proposals
- Intercompany customer invoices
- General journals
At posting, the system runs the Invoice party applicability rules for the relevant Registration category, validates that all mandatory Registration IDs for that establishment are present, and then immutably stores them on the posted invoice. If a required ID is missing, posting is blocked. No more posting French invoices with no SIRET because someone forgot to populate a field.
Defaulting that makes establishments usable in real workflows
Microsoft built two defaulting mechanisms. Both matter for adoption, because nobody is going to manually pick an establishment on every line.
The first is inventory site association. Link an inventory site (Inventory management > Setup > Inventory breakdown > Sites) to an establishment, and the system will derive the issuing or receiving establishment from the site on the transaction. If your warehouse footprint already maps cleanly to your physical establishments, you are most of the way there.
The second is financial dimension association. Link a financial dimension value (typically the dimension you already use to identify location or branch) to the operating unit that represents the establishment. The system then defaults the establishment from the dimension on any invoice-generating document. This complements site-based defaulting and covers the cases where you bill from a service location that does not have an inventory footprint.
Both mechanisms reduce manual work to near zero once the configuration is set. That is the difference between a feature people use and a feature people document and ignore.
What it unlocks beyond SIRET
The SIRET headline is real, and France is the obvious first beneficiary because of the ongoing e-invoicing rollout. The dedicated Microsoft Learn article “Use establishments in France” walks through the legal entity, customer, and vendor establishment patterns explicitly. Establishments are required for the B2G and B2B e-invoicing flows where electronic addresses are derived from Branch IDs and SIRET registrations.
But the use cases run wider:
Branch reporting and statutory filings. Branch ID is a first-class Registration category in D365. Any business filing branch-level returns under a single legal entity benefits, including foreign-branch tax filings, sector-specific regulatory submissions, and segment reporting tied to operational locations.
Multiple VAT registrations. The multiple VAT registrations framework already supports a long list of EU markets. Establishments adds the structural governance layer on top: you can now tie each VAT registration to a specific operational location, derive it from the site or dimension on the transaction, and enforce its presence at posting. The reporting framework handles the filings; establishments handle the source-of-truth governance.
AP-side vendor identification. A companion feature in 10.0.48, “Vendor ship-from address support on invoices”, lets you capture and validate the vendor’s establishment via the ship-from address on a vendor invoice. The same Registration ID validation logic applies. If your vendor operates from multiple locations under one parent, you can now record which one actually shipped, with the right registration number stored immutably on the posted invoice. That matters for VAT recovery, customs documentation, and audit trails.
Project invoicing for multi-site service businesses. Project invoice proposals support the Establishment field. Consultancies, infrastructure, and field-services businesses with multiple operating offices under one LE can finally issue project invoices with the correct local identifier without inventing intercompany transactions.
Establishments vs separate Legal Entity vs Operating Unit
This is the decision your finance consultants and product owners should be using on the next greenfield design or remediation. Here is the practical framework.
Use a separate Legal Entity when you genuinely have a separately incorporated company, separate statutory accounts, a different functional currency for accounting purposes, or a regulatory regime that requires the entity to file independently. Per Microsoft Learn, a legal entity is “an organisation that has a registered or legislated legal structure” that can enter into legal contracts and must prepare statements that report on its performance. If your legal counsel says it is a separate company, model it as a separate LE.
Use an Establishment when you have a single legal entity that operates from multiple physical or operational locations, and at least one of these is true: (a) invoices need to carry a location-specific registration number, (b) you need different regulatory identifiers per site for tax or statutory reporting, or (c) your e-invoicing or compliance regime requires explicit establishment identification. The LE remains the single accounting and legal entity. You avoid the LE proliferation tax.
Use a plain Operating Unit (cost centre, business unit, department, value stream, retail channel) when you need internal financial control, management reporting, or process boundaries, but no external regulatory identifier is involved. The operating unit framework has not changed. What is new is that the same operating unit construct can now be promoted to an establishment by adding it to the Enterprise establishment structure hierarchy.
The elegant part of Microsoft’s design is that you do not need to pick between operating unit and establishment. An operating unit becomes an establishment when (and only when) it joins the establishment hierarchy. You can keep your existing OU model and selectively layer establishment governance on top.
What to do this quarter
For finance consultants advising on a 10.0.48 upgrade or a new implementation in any multi-site European market, your action list is short and specific.
Audit every legal entity that exists primarily to hold a separate registration number. Most of them are candidates for collapse into a single LE with multiple establishments once 10.0.48 is in place. Quantify the saving: fewer LEs means fewer intercompany transactions, faster consolidation, simpler period close, and lower licensing exposure.
Map your existing site and financial dimension structures to your physical establishments before you turn the feature on. The defaulting only works if the underlying associations are clean. Bad data here will surface as posting failures, not as silent miscoding.
Review your Invoice party applicability rules for every Registration category you use. The validation behaviour is opinionated. Get your rules right before you move users onto the feature, or you will block invoice posting on day one.
For ERP product owners, the strategic question is bigger. Establishments is the kind of feature that quietly removes a long list of historical workarounds. If your D365 F&O estate is the result of years of “we had to spin up an LE for that”, 10.0.48 is the moment to start the cleanup conversation. Done well, this reduces the entity count on your platform, simplifies your governance model, and removes a category of localisation risk from every future regulatory change.
Done badly, you turn it on, validation breaks invoice posting in four jurisdictions on the same day, and you spend a week firefighting. Plan it like the architectural change it is.
The bottom line
Establishments in D365 Finance 10.0.48 is a structural feature, not a cosmetic one. It moves D365 F&O from “one legal entity, one regulatory identity” to “one legal entity, many regulated operational identities.” That is overdue, and it is exactly what European multi-site businesses have been asking for.
If you are mid-implementation, factor it into your design now. If you are post-go-live and carrying a fleet of single-purpose legal entities, start scoping the consolidation. If you advise CFOs or programme sponsors, this is the kind of change that pays back in lower platform complexity for years.
If you want a deeper review of how Establishments fits into your specific D365 F&O architecture, or a second opinion on whether your current multi-LE setup is still justified after 10.0.48, that is the work I do at Dr Dynamics. Send me a message and we can take a look.
Sources