One governed group figure across every Finance and Operations legal entity

You cannot get one trusted, consolidated group figure across your Finance and Operations legal entities because F&O keeps each legal entity's data in the ERP and does not natively reconcile them into a governed group figure. Getting the rows out is one job; consolidating differing charts of accounts, currencies and eliminations into a figure you can defend is a separate modelling job that belongs in a warehouse, not in the pipe. A governed data layer over Finance and Operations is what turns that into one live, reconciled group view.

The CFO does not want a data platform. They want a group number they can defend to the board and the auditors. That is the whole of it, and it is where Finance and Operations, for all its depth, leaves a gap.

You recognise the shape of it. The legacy analytics pipe you set up is retiring and forcing a rebuild. Legal entities that will not consolidate into one group view without a month-end Excel exercise. Querying Finance and Operations directly for reporting does not scale. Growth or an acquisition left you with more than one F&O instance to reconcile. Or the board has started asking about AI and Copilot, and the honest answer is that the data foundation underneath is not clean or governed enough to trust the answers.

There is a version of this that keeps a Head of Data awake too: the worry that the analytics are running on plumbing Microsoft is actively retiring, and that a rebuild is coming whether you plan it or not.

None of this is Finance and Operations failing. It is that the reconciled, consolidated, governed group figure finance defends lives above the ERP, in a data warehouse, not inside it. Getting each legal entity's rows out is the easy part. Making them agree is the work, and it is what this page is about.

Yes. Business performance analytics is Microsoft's fixed Dataverse-to-Fabric star-schema finance model, useful and included with the app, but it is fixed. A governed bespoke warehouse consolidates the multi-legal-entity, multi-currency and non-Dynamics sources that a fixed model does not, and reconciles to the figure your finance team actually defends. The native tools get you accurate content per entity; they do not get you to a defensible group number.

What F&O's native data and analytics give you. Finance and Operations has real reporting. Financial Reporting, the statement designer once called Management Reporter, builds financial statements over your chart of accounts and financial dimensions. Business performance analytics is a fixed Dataverse-to-Fabric star-schema finance model that Microsoft ships as a fast starting point. Each is good at its own job.

Where it stops. The word that matters is fixed. Business performance analytics is a fixed finance model, so the moment you need to consolidate multiple legal entities with differing charts of accounts, translate several currencies into a reporting currency, bring in a non-Dynamics source, or reconcile to a figure your finance team owns rather than the model's default, you are past what a fixed model does. That consolidation and reconciliation is a modelling job at the warehouse layer, not a switch in a packaged product.

So it is not the native analytics or a warehouse. Business performance analytics is often a perfectly good report layer once the governed, consolidated data layer exists beneath it. The question is whether anyone has done the multi-entity reconciliation underneath, and there is more on exactly how Finance and Operations data reaches a warehouse below.

Finance and Operations data surfaces through Dataverse, where its tables and entities appear with the mserp_ prefix, and reaches a warehouse via either Azure Synapse Link for Dataverse, the managed continuous export in open Delta Parquet, or Link to Microsoft Fabric, the no-copy read-replica in OneLake. Both land the raw rows, but landing is not the same as a governed, reconciled, legal-entity-consolidated warehouse. Those four steps are where a builder who knows Finance and Operations earns their place.

Getting Finance and Operations data out is a solved problem on paper, and it is where a generalist stops reading. The depth is in knowing which supported path fits and what each one does not do for you.

• Dataverse is the hub. Finance and Operations data surfaces through Dataverse, where its tables and entities appear with the mserp_ prefix. That is where the supported extraction paths start, and recognising it is the first signal a builder actually knows F&O rather than data warehouses in general.
• Synapse Link, own the pipeline. Azure Synapse Link for Dataverse is the managed, continuous export of F&O tables and entities to your own storage, saved in open Delta Parquet for fast queries. It is the path for a team that wants its own copy and its own downstream integration.
• Link to Fabric, no copy. Link to Microsoft Fabric is the no-copy, no-ETL path: your Finance and Operations data becomes available in OneLake without leaving the Dataverse governance boundary, with a Fabric lakehouse and SQL endpoint generated for you. It is the read-replica answer.
• Landed is not governed. Either path lands the raw rows. Conforming them, reconciling them, consolidating your legal entities and governing the result is the warehouse build at the gold layer. The extraction is the start line, not the finish, and the next section is where the group figure is actually made.

You consolidate Finance and Operations legal entities at the warehouse gold layer: conforming each legal entity's chart of accounts and financial dimensions into one group model, translating currencies into the reporting currency, and eliminating intercompany transactions once, so every consumer downstream draws on one governed, reconciled group figure instead of a batch run or a spreadsheet rebuild.

This is the single strongest reason a multi-entity Finance and Operations group builds a warehouse, and it is materially bigger than the equivalent job on Business Central, so it is worth being precise.

Getting each legal entity's data out through Synapse Link or Link to Fabric lands the rows. It does not make them agree. Consolidation across legal entities is its own modelling job, and it is where the CFO's defensible group number is actually produced. At the warehouse gold layer, you conform each legal entity's chart of accounts and financial dimensions into one group model so a single account means the same thing across the group. You translate the currencies into the reporting currency. And you eliminate the intercompany transactions once, in the model, rather than by hand every month. A small credibility note that tells you a builder knows F&O: what Finance calls a legal entity, Financial Reporting calls a company. Same construct, two labels.

Encode that once and every consumer downstream, every report, every spreadsheet, every AI, draws on the same governed, reconciled group figure. Instead of re-running a consolidation batch or rebuilding a reporting tree each period, finance has a live group view they can defend on the spot, with the detail behind it. Same legal entities, a very different level of trust.

Yes, if your Finance and Operations 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 old embedded analytics is the legacy path. The modern replacement is Dataverse into Azure Synapse Link for Dataverse or Link to Microsoft Fabric, and the forced migration is the moment to put a governed, reconciled, legal-entity-consolidated warehouse in place, not to re-plumb the old extract.

What is retiring, and what replaces it. Finance and Operations had a dedicated analytics pipe, Export to Data Lake, and it is being decommissioned. The older BYOD pattern, pushing entity data to your own SQL database, is the path Microsoft now recommends transitioning away from. And the Entity store behind the classic embedded workspaces is the legacy embedded-analytics store you modernise off. The supported modern route is consistent: Dataverse into Azure Synapse Link for Dataverse, or Link to Microsoft Fabric.

The modernisation moment. Here is where most organisations lose the opportunity. The forced migration off the old pipe is treated as a like-for-like plumbing swap, and the same unreliable, unconsolidated extract gets lifted onto a newer route. You do the disruptive work and end up with the same mess on better rails. The migration is instead the natural, and cheapest, moment to put a governed, reconciled, legal-entity-consolidated warehouse in place. You are rebuilding the plumbing anyway. Rebuild it once, properly, on the supported path, so the group figure comes out reconciled at the other end.

Finance and Operations is the enterprise ERP, consolidates legal entities, and reaches a warehouse through Dataverse into Azure Synapse Link for Dataverse or Link to Microsoft Fabric; Business Central is for smaller and mid-sized businesses, consolidates companies, and reaches a warehouse 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 and more complex 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 Fabric.

The gotchas that prove a real F&O builder. The difference between a warehouse that keeps working and one that quietly reports the wrong thing is in the detail of the F&O export. Deletes come across as soft deletes, flagged rather than removed, and purged after a set window, so a build that does not handle them will keep reporting deleted records as live. A defined set of kernel tables refresh on a slower cadence rather than near-real-time, which matters if you assume everything is current. Finance and Operations tables need change tracking and the Delta lake feature enabled, and cannot be added to an existing Dataverse-only setup, so they require their own profile. Staging and temporary tables and certain special fields are excluded by design. And there is a known issue, since fixed in a specific platform update, where deleted markers on derived tables went missing, which is exactly the kind of thing a specialist checks the customer's version for. None of this is obscure to someone who has done F&O data. All of it is invisible to someone who has only done Fabric.

How this differs from Business Central. If you also run, or are moving from, Business Central, the pattern is genuinely different. Business Central is the SMB ERP, consolidates companies rather than legal entities, and reaches a warehouse through its own APIs and OData with no direct SQL on the online version, on a smaller, differently shaped data model. So a Finance and Operations warehouse is not a scaled-up Business Central build, and a Business Central warehouse is not a scaled-down F&O one. If your question is really about the SMB ERP, that is the data warehouse for Business Central; this page is Finance and Operations specifically.

No. It is right-sized through a three-step ladder scaled to a multi-entity group: a fixed-scope assessment first, then a build of only what the evidence says you need, including modernising off the legacy pipe, then a managed data service so even a capable but stretched internal data team is never left owning the group data layer 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 sit behind the "isn't this huge?" question. That a governed Finance and Operations warehouse is an open-ended enterprise programme. And that even a data-capable team, once it has built the thing, does not have the capacity to run and govern the group data layer day to day. Both are fair, and both are answered by not doing it as one big bang. You climb a ladder sized to your group.

1. Diagnose.

   A fixed-scope assessment first. We look at your legal entities, your data path, whether you are on a retiring pipe, and where and why the group figure does not reconcile, and come back with a named picture and a right-sized plan, with the cost shown before you commit.

2. Build.

   Build only what the evidence says you need, including modernising off the legacy pipe onto a supported path. That might be a bespoke governed warehouse, or starting from a pre-built reconciled foundation, or a blend, scoped to your group rather than an enterprise transformation.

3. Run.

   A managed data service runs and governs the group data layer day to day, so a stretched internal data team is never left owning it alone. This is the honest answer to "who owns it after?" at group scale.

You never commit past the value you have already seen. See how the ladder works across the wider practice on the Data Warehouse programme, or talk to us about the first step below.