Finance and Operations numbers that reconcile across every legal entity

You cannot get one trusted, consolidated view across your Finance and Operations legal entities because F&O’s standard reports and Financial Reporting work one legal entity at a time and group consolidation runs as a batch, accountant-owned process. A multi-entity organisation cannot get one live, defensible group view across differing charts of accounts, currencies and fiscal calendars without a governed model over F&O, and that governed model is what turns it into one live, reconciled group view.

Most finance teams that come to us are not short of reports. They have outgrown them.

Finance and Operations runs a complex, multi-entity business well. But its reporting is shaped around one legal entity at a time, and the group picture is assembled by hand or run as a batch. As you grow, acquire, or simply face harder scrutiny from auditors and the board, the seams show. Finance rebuilds the group month-end in Excel because the standard reports will not give one live consolidated view. Two entities report the same measure two ways. The consolidated figure the board sees exists in a spreadsheet one person maintains, and would stall if they left.

If you migrated from AX onto Finance and Operations, you may have felt this sharply. The reporting that worked on the old system did not come across, and the analytics path underneath it has moved on more than once since.

And there is a second, quieter worry the data owner carries: “we were on Export to Data Lake, or BYOD, or the Entity store. Are we sitting on a dead pipe?” Often the honest answer is that the plumbing has moved on and the reporting has not.

None of this means Finance and Operations is the wrong system. It means the reporting layer on top of it has to be built deliberately, so the numbers reconcile and consolidate across every legal entity every time, not just in the month you last checked them.

For the plain-English version, talk to us about why Finance and Operations numbers do not reconcile across legal entities.

Yes, you still do. Financial Reporting is a financial-statement designer built over your chart of accounts and financial dimensions, and the embedded F&O Power BI workspaces are Entity-store-based operational analytics scoped to Microsoft’s standard content, so you still need a governed build the moment you want a live, self-service, reconciled group model across legal entities. F&O’s native reporting gets you accurate statements per entity; it does not get you to a live, defensible group number.

Let us be fair to F&O’s native reporting first, because it is genuinely strong, and naming it correctly is the honest place to start.

What F&O’s native reporting gives you. Financial Reporting, the feature that was Management Reporter, is a proper financial-statement engine. You build your balance sheet, income statement and trial balance in the Report Designer, over the chart of accounts and financial dimensions, using row, column and reporting-tree definitions, with dimension filters, budget-versus-actual columns, comparison formulas, interactive date and currency changes, and drill-down to voucher detail. Alongside it, F&O ships embedded Power BI analytical workspaces, the Analytics tab on workspaces such as Financial performance, Cost accounting analysis and Vendor payments, delivered through Power BI Embedded with the service licence bundled with the app. And Electronic reporting handles your statutory and regulatory output. Together that is a real, credible reporting stack, and where it fits your question, we will tell you to use it.

Where it stops. Financial Reporting is a statement designer, not a live, dimension-rich, self-service model. The embedded workspaces are aggregate models built on the Entity store, standard content Microsoft defined, not reconciled to how your group defines and defends its metrics. And Electronic reporting is for formatted statutory output, not management analytics. Each is bounded to its own job. The moment your real question becomes “what does the consolidated group look like across our legal entities, live, and can I defend it”, the native stack runs out of road.

A governed build starts where the native stack stops. It extends both into a live, self-service model on your definitions, reconciles it to the figure finance signs off, and consolidates your legal entities into one live view. Same F&O data, a very different level of trust. There is more on exactly where F&O’s native reporting stops below.

Finance and Operations’ native reporting is real and deep, but it runs out of road for a multi-entity group in four ways: it is bounded to the financial-statement designer, its embedded Power BI is Entity-store standard content rather than your figures, it is shaped one legal entity at a time, and it rides legacy analytics plumbing. Those four seams are where a governed Power BI model earns its place, giving a multi-entity F&O group one live, governed, reconciled group view on a modern data path.

Finance and Operations is not short of reporting, and any honest page has to say so, which the section above does. Having named the native stack, here is where it runs out of road for a group that spans legal entities.

It stops at four seams.

• Statement-designer-bounded. Financial Reporting is a powerful financial-statement engine, but it is a statement designer, not a live, dimension-rich, self-service model. It produces the statements finance needs; it does not give the board a live, explorable group view they can question in the room.
• Entity-store standard content. The embedded Power BI workspaces are aggregate-measurement models built on the Entity store. They report Microsoft’s standard, aggregate-measurement content, which by design is not your group’s own definitions and is not tied back to the figure finance actually signs off.
• Per-legal-entity shape. F&O reporting is legal-entity-shaped by default. A live group view across legal entities is not a setting you switch on; it is a separate, deliberate mechanism, covered next. Until you build for it, “the whole group” lives in a batch run or a spreadsheet.
• Riding legacy plumbing. The analytics path underneath, the Entity store and, for anyone who built on them, Export to Data Lake or BYOD, is retiring or superseded, covered shortly. Building more on it is building on sand.

Each seam is the same underlying point: the native tools were shaped to report one legal entity against standard content on an ageing analytics path, and a multi-entity group’s real questions have grown past that. For the governed model applied to Finance and Operations, see the Power BI build for Dynamics 365.

Finance and Operations consolidates through a dedicated consolidated legal entity that collects each subsidiary’s balances, mapping each subsidiary’s chart of accounts, financial dimensions and currency into the group and eliminating intercompany entries, run either as Consolidate online (a batch) or as Financial Reporting consolidation (report-time via reporting trees). A governed Power BI model encodes that mapping, currency translation and elimination once, so finance gets a live, reconciled group view instead of re-running a batch or a report every month.

This is the strongest single reason a multi-entity Finance and Operations group builds a governed model, and it is materially bigger than the per-company consolidation a Business Central SMB faces, so it is worth being precise about how F&O actually does it.

To combine entities, Finance and Operations uses a consolidated legal entity: a dedicated container, flagged for the consolidation process, that collects the balances of the subsidiary legal entities. Two mechanisms exist, and groups often use both. Consolidate online is a batch process that transfers subsidiary balances into the consolidated legal entity, re-run every time the source data changes. Financial Reporting consolidation combines the entities at report-generation time using reporting trees, so you can drill to every entity and dimension and re-run any time. (Microsoft uses “legal entity” in Finance and “company” in Financial Reporting for the same thing, useful nuance for anyone comparing this to Business Central.)

That mechanism is correct, and it is a great deal of careful accounting. Each subsidiary’s chart of accounts maps to consolidated main accounts, differing fiscal calendars are period-mapped, currencies are translated into the reporting currency, intercompany entries are eliminated so the group is not overstated, and minority interest and org-hierarchy reporting trees roll the whole thing up by region or function. But notice what it produces: a batch, accountant-run transfer, or a report-time run bounded to the statement designer. It is not a live, dimension-rich group view the board can self-serve, and every account, dimension and currency mapping is a place two numbers can silently drift apart.

A governed Power BI model does that reconciliation once and keeps it. It encodes the account mapping, the currency translation and the intercompany eliminations into the model itself, so the group view is live, dimension-rich, and reconciles the same way every time, not re-derived by hand each month-end. That is the difference between a group figure you produce and a group figure you can defend on the spot.

For the consolidated Finance and Operations model, built, see the Power BI build for Dynamics 365, or talk to us about consolidating your legal entities.

Yes, if your F&O analytics run on the legacy pipes, you are on retiring plumbing: Export to Data Lake for finance and operations is retiring, BYOD is transition-recommended, and the Entity store behind the embedded workspaces is the legacy path, while the modern replacement is Dataverse into Azure Synapse Link for Dataverse or Link to Microsoft Fabric. The modernisation is the moment to put a governed, reconciled model in place, not to lift-and-shift a fragile month-end onto a newer pipe.

Two of the buyers on this page ask the same question from different angles. The data owner asks “are we on a retiring pipe?” The finance leader asks “will month-end still work next year?” They deserve a straight answer.

What is retiring, and what replaces it. Export to Data Lake for finance and operations has been deprecated and its decommissioning has begun; Microsoft’s stated successor is Azure Synapse Link for Dataverse. BYOD, the export of F&O entity data into your own Azure SQL database, has no hard retirement date, but Microsoft recommends transitioning to Synapse Link or Link to Fabric. And the Entity store, the aggregate-measurement path behind the embedded Power BI workspaces, is the old analytics route; the modern direction moves F&O data out through Dataverse to Synapse Link or Fabric.

The modernisation moment. Here is the trap to avoid. When a pipe retires, the reflex is to lift the same fragile, hand-assembled month-end onto the new one and call it modernised. That just moves the problem. The modernisation moment is the right time to do the harder, more valuable thing: put a governed, reconciled model in place, so what lands on the modern pipe is a group view that consolidates your legal entities and reconciles to your numbers, not a copy of the old fragility on newer plumbing.

We build the governed Finance and Operations model so it is ready to run on the modern data path, rather than promising a specific pipeline as a finished, turnkey thing.

To talk through the retiring pipes and the modernisation moment for your estate, get in touch.

Finance and Operations is enterprise, consolidates legal entities, and reaches analytics through Dataverse into Azure Synapse Link for Dataverse or Link to Microsoft Fabric; Business Central is SMB, consolidates companies, and reaches Power BI through its own BC APIs and OData. So a Finance and Operations build is not the Business Central pattern scaled up: it is a different data path, a much larger data model, and a legal-entity consolidation model. That is the single clearest reason to use a builder who knows Finance and Operations, not just Power BI.

If a supplier describes pointing Power BI straight at the F&O SQL database, they are describing a system that is not Finance and Operations. F&O does not allow direct T-SQL connections to the production database; BYOD existed precisely to give a copy for T-SQL tools. Modern F&O reporting takes a different route.

The Finance and Operations data path. F&O tables and entities are surfaced through Dataverse, where F&O entities appear prefixed mserp_. From there the modern, supported analytics path is either Azure Synapse Link for Dataverse, a managed continuous export to your own storage in open Delta and Parquet format, or Link to Microsoft Fabric, a no-copy path where the data stays inside the Dataverse governance boundary and surfaces in OneLake as a Fabric lakehouse with a SQL endpoint and a Power BI dataset. Link to Fabric explicitly covers all Dynamics 365 apps, Finance and Operations included. This is not Business Central’s API and OData path; it is F&O’s own.

The gotchas that prove a real F&O builder. Getting F&O data out cleanly is where a BC-only or generalist builder trips. F&O tables need change tracking enabled; you cannot simply add them to an existing Dataverse-only export profile, a new profile is required; F&O entities must be enabled as virtual tables and pass change-tracking validation, and many older data-migration entities fail it; deleted rows are soft-deleted and must be filtered; staging and temporary tables are excluded; and certain kernel tables refresh only once a day. A build that plans for these ships clean. One that does not produces a model that is subtly, confidently wrong, which at board level is worse than no model at all.

How this differs from Business Central. This is where “we do Power BI on Dynamics” quietly stops being enough. Business Central is per-environment and per-company, is fed primarily through its own BC APIs and OData, and consolidates companies into a consolidated-company container. Finance and Operations reaches analytics through Dataverse into Synapse Link or Fabric, and consolidates legal entities. If you are not sure which Dynamics product you are on, or you run both, see the Business Central counterpart to this page. An F&O build is handled on its own terms, not as the BC pattern scaled up.

To talk through the F&O data path and the Fabric moment for your estate, get in touch.

No. It is right-sized through a three-step ladder scaled to a multi-entity F&O group: a fixed-scope health-check first, then a build of only what the evidence says you need including modernising off the legacy pipes, then a managed run-state so even a data-capable but stretched internal BI team is never left owning the group model alone. You climb one rung at a time, on the evidence, and you never commit further than the value you have already seen.

Two fears stall this conversation for a Finance and Operations buyer. The first is “isn’t a governed Power BI build a huge, enterprise-priced project?” The second, sharper at multi-entity group scale, is “we have a BI team, but who really owns and governs the consolidated group model after it is built?” Both have the same answer: you do not buy a big-bang programme. You climb a ladder sized to your group.

1. Diagnose.

   A fixed-scope reporting health-check for Dynamics 365 tells you exactly where and why your Finance and Operations reporting stops reconciling across legal entities, whether you are on a retiring pipe, and what it would take to fix, before you spend anything on the fix itself.

2. Build.

   If the evidence says fix it, the Power BI build for Dynamics 365 puts the governed, legal-entity-consolidated Finance and Operations model in place, including the move off Export to Data Lake, BYOD or the Entity store onto a modern data path, so the group numbers reconcile and consolidate and keep doing both, built only to the scope the diagnosis justifies.

3. Run.

   Managed BI for Dynamics 365 keeps the group model running and governed, so even a capable internal BI team that is stretched is not left owning it alone. This is the direct answer to who owns it after, at group scale.

It is right-sized, fixed scope, with the cost shown before you commit. You never pay for a rung the evidence has not justified, and where you enter the ladder depends on what the diagnosis finds.

This product sits inside the full Power BI for Dynamics 365 programme.