Legal entity architecture in D365 F&O: a 2026 reassessment

Every large multi-entity D365 Finance & Operations implementation needs to answer this design question: how many legal entities should we create?

It sounds like a finance question. From an implementation stand point it is not that simple. It is an architecture question that sits at the intersection of company law, tax, treasury, audit, operational usability, licensing, and — as of 2026 — AI agent design as well.

The practical advice typically was to avoid too many legal entities and try to use financial dimensions instead. For most industries that advice is still probably correct. For others like REIT-structured real estate, SPV-heavy private equity, or any group where statutory reality is genuinely federated, it never was straight forward decision — and now with new recently released features and capabilities, it deserves a fresh look.

The change: the latest D365 platform has changed what "easy to run" in large multi-entity roll-out means

Pre-D365 F&O, (Dynamics AX, Axapta) was not particularly friendly to heavy multi-entity deployments; risks of operational complexity because period close, master data governance and intercompany reconciliation all scaled badly.

A few platform changes rolled out recetly have shifted that view, however some of these are generally available today, some are in public preview, and at least one will not reach public preview until late 2026. An architecture that depends on all of them simultaneously is a target state with a 12–18 month runway.

Globalization Studio and the Regulatory Configuration Service let you author electronic-reporting configurations once, and share them across every LE that needs them. When a regulator publishes a new schema, you update it once, not two hundred times. One important note: the older Regulatory Configuration Service (RCS) has been merged into Globalization Studio from 10.0.39 and is being deprecated. Customers still on standalone RCS face a migration to Globalization Studio; greenfield deployments use Globalization Studio directly.

Tax Calculation Service and multiple VAT registrations let a single legal entity carry the VAT registrations of many underlying units, with automatic determination per transaction and per-registration tax reporting. Only note, that country coverage for the multi-VAT reporting feature is currently limited to 18 European jurisdictions. More on this below, because it changes the shape of what an entity can reasonably represent.

Project Operations pulls the operational project experience — timesheets, expenses, schedules, WBS, resource allocation, change orders — out of F&O and into Dataverse, while keeping F&O PMA as the statutory cost book. Native support for the intercompany vendor-invoice pattern (a preview release at the time of writing) can potentially simplify what used to be a six-step posting chain into a single approval action.

Microsoft is introducing autonomous finance agents (such as Account Reconciliation and Financial Reconciliation agents) and agent management in Dynamics 365 Finance and Microsoft 365 Copilot for Finance, designed to automate reconciliation, data preparation, and matching between subledgers and the general ledger to speed up financial close. Recognised Gold partners are also delivering Copilot‑based agents such as the PayFlow Agent for Dynamics 365 Finance, which automates payment‑related activities and provides near real‑time payment insights. Please note, Microsoft designates the Agent Management feature as "production-ready preview". These agents should be able to accelerate close cycles substantially.

Dataverse Dual-write and Virtual Entities provide bidirectional, near-real-time integration between F&O and Dataverse. This is what makes it possible to put the system of engagement (operational UX) on Dataverse while keeping the system of record (statutory ledger) on F&O. However, a few constraints to note: Dual-write is strictly 1-to-1 between a single F&O environment and a single Dataverse environment — Dataverse cannot sit as a hub between multiple F&O environments; live synchronisation supports up to 250 legal entities per transaction; initial synchronisation is capped at 40 legal entities per run, which means onboarding more LEs to Dual-write requires a phased initial sync plan.

The new journal framework and accounting rules engine (Public Preview Sep 2026; General availability (GA) not yet announced) supports multi-company journals in a single entry, voucher-level processing with improved error isolation, and a centralised accounting rules engine for posting setup. This is the feature that most directly addresses the intercompany-journal explosion in large multi-LE deployments — but it is not GA at the time of writing.

Net effect. Even treating the preview items as future-GA rather than current capability, the direction of travel is as following: a well architected 2026 deployment can now run large numbers of legal entities with a close cadence and less staff effort then before — provided the operating model is designed around the platform features rather than in spite of them and provided the programme plan explicitly accommodates feature GA timelines.

The case: ~200 SPVs, one ERP, no obvious answer

The case that prompted this post is a pan-European logistics real estate investor — REIT-structured, multi-country, ~€15bn GAV, ~300+ owned assets. The portfolio is held through a deep federation of Special Purpose Vehicles: roughly one hundred UK property companies under a REIT umbrella, a comparable multi-SAS/SNC stack in France, more subsidiaries in Germany, the Netherlands, Poland, Spain, Italy, Sweden and the Czech Republic, plus Luxembourg bond-issuing vehicles. All in, circa two hundred active legal entities, with every one of them required by law to file separate statutory accounts.

Four options considered

Option 1 — LE-per-SPV. One D365 F&O legal entity for every registered SPV. Each SPV has its own ledger, trial balance, VAT and CIT filings, auditable books. Auditors like it. Operations teams hate it - risks would include the following - period close is multiplied, master data can drift, regression testing may become a full-time function, etc.

Option 2 — Country aggregate. Collapse to one LE per country. Every SPV becomes a financial dimension. Single chart of accounts, single master data lake, one close process per country. Beautiful on paper. In practice however, authorities expect per-entity statutory accounts. Corporate income tax is per entity. REIT ring-fencing is per entity. Testing is per entity. Banking is per entity. Risks of complience. Microsoft's own guidance is explicit that while financial dimensions can technically represent legal entities, they are not designed to address the operational or legal needs of legal entities.

Option 3 — Tiered hybrid. Keep only trading SPVs as legal entities. Cluster dormant or near-dormant SPVs into country-level "holdco" LEs, with the SPV identity carried as a financial dimension. Extract statutory packs for the dormant entities from the holdco ledger filtered by dimension. A pragmatic compromise, but with risks and overhead: who decides when an SPV moves between tiers, and what happens when a dormant SPV suddenly starts trading again?

Option 4 — Separate operations with a Dataverse 'sub-ledger'. Keep the legal entities (all of them, as in Option 1), but redesign the operating model so the SPVs are quiet legal entities. Route all day-to-day property operations through a Dataverse-hosted system built on Power Platform. The Dataverse layer writes to D365 F&O only as a recipient of pre-classified accounting journals (aka sub-ledger to general ledger pattern), typically in daily or weekly batches via Dual-write. The PropCo owns the asset; the OpCo runs the business. Separating the two lets each entity do what it is best suited for.

In the weighted decision matrix — twelve criteria across four lenses (statutory compliance, total cost of ownership, AI/automation readiness, consolidation speed) — Option 4 won by a meaningful margin. Option 2 rated third despite looking superficially easy. Option 1 came last because it was the most difficult to run without delivering any benefit that Option 4 doesn't also deliver.

Option 4 is also the option with the most dependencies on preview-stage features. But it is being a forward-looking target architecture rather than as-is compatible one.

The PMA problem, and why Project Operations is the answer

Among all the modules in F&O, Project Management and Accounting (PMA) is the one most likely to turn a multi-SPV deployment into an operational nightmare. The reason is structural. In the PropCo/OpCo pattern (PropCo is the Property Company that owns the asset and bears the CapEx, OpCo is the Operating Company that runs the business on its behalf), the OpCo employs the staff and holds the operational vendor contracts. Every hour spent on a project for an SPV, every contractor invoice paid by OpCo on behalf of an SPV produces a six-step posting chain in PMA: posting cost on the lending LE, intercompany AR invoice, intercompany AP invoice on the borrowing LE, project cost on the borrowing LE, settlement payment, and FX revaluation where currencies differ. Scaled across dozens of SPVs and a few active CapEx projects each, you are looking at thousands of PMA intercompany postings a year — the single biggest source of friction in a classic implementation.

Project Operations Integrated is the 2026 answer to this specific problem. PO is Microsoft's Dataverse-native successor to Project Service Automation. In Integrated mode it keeps F&O PMA as the statutory book of project cost while moving the operational project experience to Dataverse. Timesheets, expenses, Gantt schedules, WBS, resource assignments, change orders and what-if scenarios live natively in Dataverse. Only approved, accounting-relevant events — approved timesheets, approved expenses, posted vendor invoices, period cost allocations — cross the Dual-write boundary into F&O PMA.

Here are a few caveats however

The cross-company intercompany project vendor invoice via Dual-write - it's a preview feature, lets us turn a single subcontractor vendor invoice in F&O into a full intercompany project recharge, with Project Operations and Dual‑write handling most of the plumbing between the lending and borrowing legal entities.
Scope is for non‑stock subcontracting. For stock/physical goods, we are still back into classic intercompany procurement/transfer scenarios.
Volumes and performance consideration - Real‑time Dual‑write has known constraints, it will need performance testing, especially around async vs real‑time maps.

In the future, it can potentially be also combined with the new multi-company journal framework (also preview — public preview September 2026, GA not yet announced), where a week's worth of OpCo-to-PropCo project-cost recharges across dozens of PropCos can be batched into one F&O journal, posted once, and reconciled in parallel by Copilot for financial close. The detailed transactional granularity stays in Dataverse for audit; the statutory postings compress by something like an order of magnitude.

What to take away

A legal entity doesn't have to be where the work happens. The 2026 Microsoft stack lets you separate the book of record (D365 F&O legal entity) from the system of engagement (Dataverse + Power Platform). Operational users never need to see the ledger. Customers should be in Power Pages. Finance controllers can be looking at Copilot-generated close summaries, not reconciling spreadsheet exports.

Project Operations is the feature that turns PMA intercompany traffic from a operational disaster into a batched, Dual-write-assisted background process. If the target operating model has staff in OpCos (Operating Companies) and assets in PropCos (Property Companies), then PO Integrated is the right way forward. With one note however, its cross-company intercompany vendor invoice pattern is presently in preview, which means the target architecture may need to have a classical-PMA-IC fallback still.

Copilot agents can accelerate operational productivity in the near future, they are upside to the architecture as they move from production-ready preview to GA.

Get the architecture decision out of Finance and into the architecture DA group. It is a joint decision across the tax director, the group treasurer, the programme director (delivery risk), and the enterprise architect (platform features, AI strategy).

The good news, is that modern platform gives us more options and much better tools for designing robust architectures, even though quite a few of them are still conditional on feature graduation to GA.

Status note (April 2026):

Globalization Studio, Tax Calculation Service, Dual-write, Project Operations Integrated core: GA.
RCS: Deprecated, merged into Globalization Studio from Finance 10.0.39.
Copilot Agent Management (Account Reconciliation, Financial Reconciliation, Payflow Agent): Production-ready preview (usable in production under supplemental terms).
Project Operations cross-company intercompany vendor invoice via Dual-write: Preview.
New financial journal framework (multi-company journals, accounting rules engine): Public preview targeted September 2026; GA not yet announced.