# Business Central reporting: built-in, Power BI or lakehouse

> Three ways to report on Dynamics 365 Business Central, what each one is good for, the limits Microsoft documents, and how to tell which one you need.

Published: 2026-09-30
Author: Preetham Reddy
Tags: Knowledge Share, Azure, Databricks
Canonical: https://www.techfabric.com/blog/business-central-reporting-built-in-power-bi-or-a-lakehouse

---

Most Business Central reporting projects start with the same file. Somebody in finance exports a list to Excel every Monday, adds two columns by hand, deletes the rows that don't belong and emails it round. It's been that way since go-live, and now somebody wants it in Power BI.

Sometimes that's the right call. Often the report already exists inside Business Central and nobody turned it on. And every so often the question can't be answered from the ERP at all, because half the data never lived there.

So there are three answers, and they cost very different amounts. This is how we tell them apart, with the limits Microsoft documents for each, checked against Microsoft Learn on 30 September 2026.

## What's already in the box

Business Central ships more reporting than most estates use.

**Report layouts.** Every report can carry Word, Excel and RDLC layouts, and users add or replace them on the [Report Layouts page](https://learn.microsoft.com/en-us/dynamics365/business-central/ui-get-started-layouts) without a developer. Excel layouts arrived in the 2022 release wave 1, and they're the quiet fix for the Monday export: the report hands Excel its data and a workbook you designed does the rest. The one catch is that layouts shipped inside an extension can't be edited, only copied.

**Analysis mode.** Generally available since October 2023, [analysis mode](https://learn.microsoft.com/en-us/dynamics365/business-central/analysis-mode) turns a list page into a pivot you can group, filter and total in the browser. It's very good for the question somebody asks once. Know its edges before you promise it to anyone. It doesn't work on hierarchical lists such as the chart of accounts, dates group by calendar year rather than fiscal period, calculated fields disappear past 100,000 rows, and each person's views are their own unless shared by link.

**Financial Reporting.** What used to be account schedules was renamed in the 2022 release wave 2, with row and column definitions in place of the old names. It's where the income statement, balance sheet and cash flow views live, and it's what finance should sign.

**Microsoft's Power BI apps.** There are nine of them: Finance, Sales, Purchasing, Inventory, Inventory Valuation, Manufacturing, Projects, Subscription Billing and Sustainability. They went generally available in November 2024 and their source was opened in 2025. They aren't free to run, though. Microsoft's [FAQ](https://learn.microsoft.com/en-us/dynamics365/business-central/across-powerbi-apps-faq) says installing, refreshing and viewing them needs Power BI Pro or Premium capacity, and that a free Power BI licence won't do.

If the request is a better version of a report finance already runs, start here. An Excel layout is an afternoon's work, and it retires the Monday export for good.

## Power BI on the ledger

The built-in options run out in a recognisable way. Three departments want the same margin figure, each wants it cut differently, and each has started maintaining its own copy. That's the moment for one semantic model on the ERP, with the measures agreed once and every report reading it.

Power BI reads Business Central through the [Business Central connector](https://learn.microsoft.com/en-us/dynamics365/business-central/admin-powerbi-setup), which can use API pages and API queries or older OData web services published from pages. Use the APIs. Microsoft recommends against the web service route, and most API entities carry `lastModifiedDateTime`, which is what makes incremental refresh possible. A filtered read looks like this:

```
GET https://api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/api/v2.0/companies({companyId})/salesInvoices?$filter=lastModifiedDateTime gt 2026-09-01T00:00:00Z
```

Since February 2022 those reads land on a [read-only replica](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/database-read-scale-out-overview) in Business Central online, so a heavy refresh doesn't slow the people posting invoices. Sandboxes always read the primary database, which matters if you load-test there and wonder why it behaves differently.

The limits are where Power BI on Business Central usually breaks, and they're per user. Microsoft's [operational limits](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/operational-limits-online) allow 5 concurrent OData requests and 6,000 requests in any five-minute window before Business Central answers with HTTP 429. A single request times out at eight minutes, and a page holds at most 20,000 entities. A full nightly reload of every ledger table, running under the account of whoever built the report, will find those numbers before you do.

What holds up:

- A dedicated account for refresh, so the reports don't stop the week their author leaves.
- Incremental refresh on `lastModifiedDateTime` for the big tables, and a full reload only for small dimensions.
- Measures for margin, aged debt and inventory turns reconciled to the trial balance before anybody sees a chart.
- Refresh scheduled against the posting cycle rather than midnight, so Monday's number is Friday's close.

## When other systems hold half the answer

Power BI on the ERP is enough as long as every number lives in the ERP. It stops being enough the day somebody asks a question that crosses systems. Which supplier's material is costing us yield? That needs the lab. Why did throughput drop in August? That needs the line historian and the downtime log. Do our receipts match what the weighbridge saw? That needs the scale house.

None of those were ever going to be Business Central tables, and joining them inside a Power BI model works until the model holds four sources with four ideas of what a supplier is. That's when a lakehouse earns its cost. Each source lands as it is, gets cleaned and reconciled once, and the gold tables carry one definition per metric for every dashboard to read.

There's no managed connector to do the Business Central half. The [Lakeflow Connect Dynamics 365 connector](https://learn.microsoft.com/en-us/azure/databricks/ingestion/lakeflow-connect/d365-faq) reads the Dataverse applications and Finance & Operations through Azure Synapse Link, and Business Central isn't on its list. That leaves two routes:

- **The API, incrementally.** The same `lastModifiedDateTime` filter as above, run from a Databricks job, with the 6,000-per-five-minutes budget in mind and a separate account so the reporting load doesn't eat a person's quota.
- **bc2adls.** It exports Business Central tables incrementally to Azure Data Lake Storage or Microsoft Fabric, where Databricks can pick them up. Microsoft [archived its own repository](https://github.com/microsoft/bc2adls) in September 2023. The [community fork](https://github.com/Bertverbeek4PS/bc2adls) is the one still being released, and it's the one to install.

Microsoft did announce deeper Business Central integration with Fabric at FabCon in Barcelona this month. It isn't on the documented list of [Fabric mirroring sources](https://learn.microsoft.com/en-us/fabric/mirroring/overview) yet, so we wouldn't plan a project around it until it is.

We built one of these for a manufacturer bringing a new plant up to capacity: Business Central, the scale house, the line historian, the downtime log, the lab and market prices, landing in 37 tables behind nine dashboards and a Genie space. The write-up and the report screenshots are in the [plant leadership case study](/case-studies/plant-leadership-reporting-databricks). The part worth copying is that it was built on sample data first, so leadership argued with the reports before anyone asked IT for access.

## How to choose

Three questions settle most of it.

**Is every number already in Business Central?** If yes, you probably don't need a lakehouse. Try layouts, analysis mode and Financial Reporting first, then Microsoft's Power BI apps.

**Do several teams need the same measure cut different ways?** That's a semantic model in Power BI on the ERP, and the work is agreeing the measures rather than drawing the charts.

**Does the question need a system that isn't the ERP?** Then it's a lakehouse, with Business Central as one source among several and still the system of record. Nothing in the lakehouse writes back to the ledger.

It's tempting to skip straight to the third answer because it's the most interesting one to build. Don't. A lakehouse for a business whose numbers all live in the ERP is an expensive way to rebuild Financial Reporting.

If you're not sure which of the three you're looking at, send us the report finance exports and fixes by hand every week. The way people repair it usually tells you. Our [ERP reporting](/expertise/erp-reporting) and [Power BI consulting](/expertise/power-bi-consulting) pages go further into how we build each one.
