Does Excel Reporting Need a Data Warehouse? (2026)

Does Business Central Excel reporting need a separate governed data warehouse sitting under it? No. If the reporting tool reads live through Business Central's own permission model instead of copying the data somewhere else, the governance is already there, because Business Central enforces it on every query regardless of which application is asking.

The question is worth asking directly, because Cosmos, one of the newer entrants in Business Central reporting, published a post on 15 September 2026 arguing the opposite. The post, Self-Service Business Central Reporting: Why Excel Still Wins (If You Govern It), makes the case that Excel was never the real problem with reporting, that weak connections between spreadsheets and the underlying data were, and that the fix is to separate self-service Excel access from a governed data layer holding stable, structured definitions. It is a fair argument on its own terms. It is also, transparently, a description of Cosmos's own product.

What Cosmos means by a governed data layer

Cosmos is not being vague about what that layer is. According to Cosmos's own support documentation, its Business Central extension extracts data out of BC into a Cosmos reporting database hosted on Azure, loaded through scheduled incremental pipelines and a staging area (source: support.cosmosdatatech.com, "Overview of the Staging Area"). Each customer gets its own tenant and database, and the Azure storage is bundled into Cosmos's base subscription fee (source: cosmosdatatech.com/features/cloud). That is a real architecture with real benefits. Once your data sits in a warehouse, you can join it to sources outside Business Central and build models for Power BI that go beyond what a live query can do.

It also means the governance Cosmos is describing is governance over a copy. The controller's data now lives in two places: inside Business Central, where it has always lived, and inside a Cosmos-owned Azure database, where a second access model has to be built, maintained, and kept in sync with the first one. Cosmos does not publish which Azure region that data sits in, whether a customer can use their own Azure subscription instead, or what its retention and deletion terms are. Its current compliance statement is a SOC 2 Type 1 examination completed on 24 June 2026, and the same announcement says Cosmos is continuing through the next stage of the SOC 2 process, during which auditors evaluate the operation of its documented controls over time, which is the Type 2 work. None of that makes Cosmos ungoverned. It does mean governed is being defined as governed by us, in our database, rather than governed by the system of record.

Business Central already governs who sees what

Business Central's permission system is not a checkbox feature. It is built from permission sets, which bundle table-level and field-level rights, and security filters, which restrict which records within a table a user can see, for example limiting a user to specific dimensions, locations, or companies. This is the same mechanism Business Central uses to decide what a user sees in the client, in Power Automate, and in every API or OData web services call. It runs on every query, not just the ones a human happens to click through in the browser.

What that looks like on a real table

Say a controller at a multi-entity distribution group has read access to the G/L Entry table for their own operating company but not for the group's holding company, because the permission set for their role excludes it. If that controller opens an Exsion Reporting workbook and pulls G/L Entry data with a live query, Business Central enforces the same permission set it always does, and the holding company's entries do not come back.

Nothing about using Excel as the interface changes what the controller is allowed to see. Exsion reads Business Central through OData web services, and the query runs as the signed-in user, so company rights and security filters set on a table both apply. It is a client of Business Central in the same way the BC web client is, and it inherits whatever permissions the administrator already set up there.

Two ways to govern the same report

The practical difference between the two models comes down to how many places access has to be defined and kept current.

[[TABLE_START]]

Question | Live query through Business Central | Copy into a vendor database

Where the reporting data lives | In the Business Central tenant only | In BC and in a second database owned by the vendor

Whose permissions apply | Business Central permission sets and security filters | The vendor's access layer, rebuilt alongside BC's

What happens when a permission set changes | It applies on the next query | Someone has to keep the second model in sync

What the copy adds | Nothing beyond BC's own data | Joins to non-BC sources and a semantic model for Power BI

What an auditor is shown | One system of record | Two places where financial data sits

[[TABLE_END]]

Reading live through Business Central's own permission model means there is exactly one place access gets defined and exactly one place it needs to be kept current: Business Central itself, which the IT or finance team is already managing. Copying data into a second database means building and maintaining a second access model there too, and every time a permission set changes in BC, someone has to make sure the copy's access rules still match.

What a warehouse buys, and what it costs

To be fair to the underlying point: a warehouse is not the wrong tool for every job. If a company genuinely needs to blend Business Central data with a CRM, a separate payroll system, or external market data, and wants one governed model feeding Power BI dashboards across all of it, a warehouse layer is doing something a live query into BC alone cannot do. That is a real use case, and it is true that ungoverned, ad hoc spreadsheets scattered across a finance team are a real problem worth solving.

But for the specific job most Business Central controllers are doing with Excel today, building the monthly P&L, checking the trial balance, reconciling intercompany balances across companies, refreshing a management report before a board meeting, none of that requires blending in outside data sources. It requires accurate, current numbers out of Business Central, respecting who is allowed to see what, refreshed in the time it takes to click a button. A live connection through BC's own permission model does that without asking anyone to stand up Azure infrastructure, pay for a second database, or explain to an auditor why financial data now lives in two systems instead of one.

Where Exsion stands on this, plainly

Exsion should be held to the same standard as any vendor making this argument, so here is our own position without the sales gloss.

Exsion stores no reporting data of its own. The data stays in the Business Central tenant, and the only copy that exists is the workbook the user chooses to save. Retention and deletion of a vendor-held copy therefore do not apply to us, because there is no vendor-held copy.

Exsion holds neither a SOC 2 Type 1 nor a Type 2 report, and we would rather say that than leave the subject alone. A SOC 2 report is an assurance about how a service organisation handles data it holds. We hold none, which is an argument, not a certificate, and a buyer is entitled to weigh it as such. We do have a data processing agreement and will send it before signature. If your procurement process requires a SOC 2 report from every vendor regardless of architecture, that is a legitimate requirement and we will not pretend otherwise.

Three questions to ask before you buy

Any Business Central reporting vendor claiming to solve governance should be able to answer these plainly, in writing, not just in a sales call.

1. Where does my data live once it leaves Business Central, and in whose Azure subscription or database? If the answer is a database we manage on your behalf, ask for the region, the retention period, and what happens to the copy if you cancel.

2. Whose permission model applies when I open a report? If the tool has its own access layer separate from Business Central's, ask how the two stay synchronised when a permission set changes in BC, and who is responsible for catching drift.

3. What covers the copy, not just the vendor's own infrastructure? A compliance report on a vendor's platform is not the same as a data processing agreement covering your specific data.

None of these questions has a wrong answer by default. A warehouse-based tool can answer all three honestly and still be the right fit for a company that needs cross-system reporting. The point is that governed should mean something specific and checkable, not just a word attached to whichever architecture a vendor happens to sell. If you are still drawing up the shortlist, our comparison of the leading Business Central Excel reporting tools sets out where each one sits.

By Thomas Werkhoven, CEO of Exsion365, registered accountant, previously group controller and CFO.

Frequently asked questions

[[FAQ_START]]

Does Excel reporting for Business Central need a separate data warehouse to be governed? | No. If the reporting tool queries Business Central live and applies BC's own permission sets and security filters, governance already exists in the system of record. A warehouse adds value for blending outside data sources, not for governing access to BC data itself.

How does Exsion Reporting handle user permissions? | Exsion reads Business Central through OData web services and the query runs as the signed-in user, so company rights and security filters on a table both apply. A user sees the same data in an Exsion workbook that they would see in the Business Central client, and there is no second security model to maintain.

Does Exsion Reporting store a copy of my Business Central data? | No. Exsion stores no data of its own. The reporting data stays in the Business Central tenant, and the only copy is the workbook the user saves, so retention and deletion of a vendor-held copy do not apply.

What does the Cosmos governed data layer actually consist of? | Per Cosmos's own support documentation, it is a copy of Business Central data extracted into a Cosmos-owned Azure database per customer, loaded through scheduled pipelines and a staging area. Cosmos bundles the Azure storage into its base fee but does not publish the Azure region, a customer-subscription option, or retention and deletion terms.

Is a data warehouse ever the right choice for Business Central reporting? | Yes, when a company needs to blend Business Central data with other systems, such as a CRM or a separate payroll platform, and wants one governed model feeding Power BI across all of it. For reporting that stays inside Business Central's own numbers, a live connection avoids building and maintaining a second copy.

Does Exsion have a SOC 2 report? | No, neither Type 1 nor Type 2. A SOC 2 report is an assurance about data a service organisation holds, and Exsion holds no customer reporting data. That is an argument rather than a certificate, and buyers whose procurement requires SOC 2 regardless of architecture should weigh it accordingly. Exsion does have a data processing agreement and provides it before signature.

[[FAQ_END]]