Business Central data you can consolidate and defend

You cannot get one trusted, consolidated view across your Business Central companies because BC keeps each company's data on its own and consolidates them only as a separate, batch, accountant-run process, so getting the rows out is one job and reconciling differing charts of accounts, dimensions and eliminations into one group figure is a separate modelling job that belongs in a governed warehouse, not in the ERP. A governed data layer over Business Central is what turns that into one live, reconciled group view.

Most teams that come to us are not short of data. They have outgrown the ways of getting to it. Business Central runs the business well, but the reporting works company by company, and the month-end that stitches the companies together runs on Excel exports that one person owns and nobody else can rebuild.

You recognise it in a few shapes. Business Central is live but the reporting is still broken or unreliable. The Excel that consolidates the group has become unmanageable. Growth or an acquisition left you with several companies to reconcile and no clean way to see the group. Leadership wants Power BI, or Copilot, but the internal team does not have the architecture skills to build the foundation underneath it. For a lean finance-led business with thin IT and no data team, that last one is the whole problem.

There is often a migration underneath it too. Moving from on-premises NAV to Business Central online is the right modernisation, but the old reporting fed off a SQL database you could point a warehouse straight at, and Business Central online does not work that way. The data feed that used to just work has to be rebuilt on new plumbing.

None of this means Business Central is wrong. It means the reconciled, consolidated, governed layer your finance team defends lives above the ERP, in a data warehouse, not inside it. That is what this page is about.

Yes. Microsoft Fabric and Link to Fabric land your raw Business Central data, and the free BC Power BI apps are template reports scoped to standard BC schema and a single company, so you still need a governed warehouse the moment you want to reconcile to your own finance-owned figures or see a consolidated view across companies. They land the data and get you a report; they do not get you to a trusted group number.

What Fabric and the free apps give you. The free Business Central Power BI apps are a genuinely good starting point, nine functional areas of template semantic models that read straight from Business Central. Microsoft Fabric, with OneLake at its core, is Business Central's stated path for richer data engineering and integration, and it lands your BC data in an open, governed format. Both are real, both are useful, and neither is the thing we are describing.

Where they stop. The free apps are single-company reporting templates over standard BC schema, so they run out of road the moment you want your own reconciled figures or a view across companies. And landing the data in Fabric is not the same as governing it. The wedge is not that Business Central cannot move its data, it clearly can. It is that BC's supported paths land raw, single-company-shaped, standard-schema data. They do not reconcile it, conform it, consolidate it across companies, or govern it. Turning that raw landing into a trusted group figure is the warehouse build, and it is the same work whether the data lands via Fabric or any other supported route.

So the question is not Fabric or a warehouse. Fabric is often where the warehouse lands. The question is whether anyone has done the reconciliation and consolidation on top, and that is what you are actually buying. There is more on exactly how Business Central data reaches a warehouse below.

Business Central online has no direct SQL access, so data reaches a warehouse through BC's supported paths: a one-off full historical extract through BC's supported export path for the initial load, and watermarked API queries against the read-only replica for the nightly incremental loads, orchestrated with tools like Azure Data Factory. Both land the raw rows, but landing is not the same as a governed, reconciled, multi-company warehouse. Those four steps are where a builder who knows Business Central earns their place.

On Business Central online you cannot query the SQL database directly. That single fact shapes everything, and it is the clearest reason to use a builder who knows Business Central rather than one who knows only data warehouses.

• No direct SQL on BC online. For Business Central online, the only supported way to read data is through APIs, either the standard built-in ones or custom APIs shipped as extensions. Direct database reads are an on-premises option only, and a design that depends on direct SQL can even block your move to the online version. A generic data-warehouse approach that assumes a SQL connection fails here on the first day.
• The historical load. The one-off history comes across as a full-database export through Business Central's supported export path, restored into Azure SQL. It is a snapshot, not a live feed, so it does the heavy lifting once, at the start, to give you the years of history the ERP does not keep in a reporting-friendly shape.
• The nightly delta. After the history load, the warehouse keeps current with incremental loads through BC's APIs, filtered on the audit field every Business Central table carries so only what changed since last night comes across. Business Central serves this reporting read from a secondary, read-only replica, so the load does not compete with the people using the ERP. Azure Data Factory or Power BI dataflows orchestrate it.
• Landed is not governed. Whichever path lands the data, it arrives raw, single-company and standard-schema. Conforming it into a reconciled, consolidated, governed model, bronze to silver to gold, is the warehouse build. The extraction is the start line, not the finish, and the next section is where the real value sits.

Business Central consolidates by mapping each subsidiary company's accounts and dimensions into a separate consolidated company and eliminating intercompany entries, but that is a batch, accountant-run, trial-balance-level process, not a live group view. A governed data warehouse encodes that same mapping, currency translation and elimination once, so finance draws on one live, reconciled group view instead of re-running the batch every month.

This is the single strongest reason a multi-company Business Central business builds a warehouse, so it is worth being precise about how BC does it today and where that leaves you.

Business Central reporting is per company. To see the group, BC uses a consolidation mechanism: a separate consolidated company, a container with no live trading of its own, that receives the general-ledger entries from each subsidiary. Each subsidiary is set up as a business unit, its balances brought in through a batch export job or a Microsoft consolidation API across environments. For every subsidiary, someone has to map each posting account into the consolidated chart of accounts, set the exchange rates where currencies differ, and eliminate the intercompany transactions by hand. The output is the Consolidated Trial Balance.

It works, and for a statutory trial balance it is often enough. But look at what it is: batch, trial-balance-level, and accountant-run. Every account mapping and every manual elimination is a place where the group number can quietly diverge from what the subsidiaries actually posted, and you find out at the worst possible moment. It is a monthly event, not a live figure, and it stops at the trial balance rather than giving you a dimension-rich, self-service view of the group.

A governed data warehouse encodes that mapping, currency translation and elimination once, in the model, and then refreshes from the nightly delta loads. Finance gets a live, reconciled group view they can defend on the spot, with the detail behind it, instead of re-running a batch and rebuilding a spreadsheet every month. Same companies, a very different level of trust.

Business Central is for smaller and mid-sized businesses, consolidates companies, and reaches a warehouse through its own BC APIs and OData with no direct SQL on the online version; Finance and Operations is the enterprise ERP, consolidates legal entities, and reaches a warehouse through Dataverse into Azure Synapse Link or Link to Microsoft Fabric. So a Business Central warehouse is not the Finance and Operations pattern scaled down: it is a smaller, differently shaped data model on a different data path. That is the single clearest reason to use a builder who knows Business Central, not just Fabric.

The Business Central data path. The specifics matter, because they are where a generalist gets it wrong. Business Central online has no direct SQL, serves its reporting read from a secondary replica, and stamps every table with the audit fields that make watermarked, incremental loads possible. The big historical load comes through BC's supported export path; the ongoing loads come through the APIs. Microsoft has also been retiring older change mechanisms, so a build that leans on a deprecated route ages badly. Knowing which of these is current, and building on the supported one, is the difference between a warehouse that keeps working and one that breaks at the next release wave.

How this differs from Finance and Operations. If you also run, or are moving to, Finance and Operations, the pattern is genuinely different. Finance and Operations surfaces its data through Dataverse and lands it in a warehouse through Azure Synapse Link or Link to Microsoft Fabric, and it consolidates legal entities rather than BC's companies, on a much larger and more complex data model. So a Business Central warehouse is not the Finance and Operations build shrunk down, and vice versa. If your question is really about Finance and Operations, that is the data warehouse for Finance and Operations; this page is about Business Central specifically.

The NAV lineage. The reason we get the Business Central data path right is that we have been on this Dynamics family since before Business Central shipped, back through NAV. The move from on-premises NAV, where a warehouse could read the SQL database, to Business Central online, where it cannot, is exactly the moment the warehouse plumbing has to be rebuilt on the supported route. That is a migration we have done, not read about.

No. It is right-sized for a smaller business through a three-step ladder: a fixed-scope assessment first, then a build of only what the evidence says you need, then a managed data service so a lean team with no data staff is never left owning it 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 "is this overkill?" question. That a data warehouse is an enterprise-priced project a business your size cannot justify. And that even if you build it, you have no data team to run it, so you will end up owning something you cannot maintain. Both are fair, and both are answered by not doing it as one big commitment. You climb a ladder scaled to a lean organisation.

1. Diagnose.

   A fixed-scope assessment first. We look at how many companies you are consolidating and where and why the numbers stop reconciling, 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. That might be a bespoke governed warehouse on your Business Central data, or starting from a pre-built reconciled foundation, or a blend of the two. It is scoped to a business your size, not an enterprise programme.

3. Run.

   A managed data service runs and governs the data layer day to day, so a lean Business Central team is never left owning it alone. This is the honest answer to who owns it after, and it is a deliberate choice, not an afterthought.

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.