Microsoft Business Central is the ERP of choice for a large and growing segment of mid-market organisations — SMEs that have outgrown basic accounting software and need a cloud-native Microsoft ecosystem solution that integrates cleanly with Microsoft 365, Teams, and the broader Power Platform. What Business Central does exceptionally well is transactional processing: purchase orders, sales orders, inventory management, general ledger entries, and project accounting. What it does not do well — and is not designed to do — is enterprise-grade Microsoft Business Central analytics at the scale and flexibility that finance leaders, operations managers, and executive teams actually need. The path to that capability runs through Power BI and, for more complex requirements, Microsoft Fabric.

The Analytics Gap in Business Central's Built-In Reporting

Business Central ships with a set of built-in reports — financial statements, trial balances, aged receivables, inventory valuation — that cover the standard accounting outputs a finance team needs for daily operations. These reports are functional, but they share three structural limitations that become significant as the organisation's analytical requirements mature.

Customisation is constrained by BC's report development model. Built-in BC reports are built on the AL language and require BC developer expertise to modify. A finance manager who wants a P&L with a slightly different dimension structure, a non-standard date grouping, or a comparison to a scenario that is not a BC standard fiscal period cannot make that change in the report — they need a developer or a workaround. This creates a backlog of analytical requirements that the BC environment cannot service at the speed the business needs.

Cross-company and cross-system analysis is not supported natively. Organisations with multiple BC companies — common in multi-entity or multi-geography structures — cannot produce consolidated financial reports natively within BC. Each company's data is in a separate BC environment; consolidation requires manual export, manual combination, or a third-party add-in. And analysis that combines BC financial data with data from other systems — a CRM, a payroll platform, a project management tool — is simply not possible within BC.

Historical depth and performance analytics have real limits. BC's built-in reporting is designed for current-period operational queries. Long-period trend analysis — 36 months of revenue by dimension, rolling 12-month margin by product group — can cause performance issues in BC's report rendering for larger datasets, because the queries are running against the live transactional database rather than an analytical data store optimised for aggregation.

"Business Central is an outstanding transaction system. It is not an analytics platform. Getting executive-grade financial intelligence from BC data requires moving that data to an environment designed for analytics — and Power BI is the natural home for it."

Business Central Storage and What It Means for Analytics

Business Central Online (SaaS) allocates storage per environment based on the number of licensed users, with additional storage purchasable as an add-on. Each environment receives a base allocation, with per-user increments. For analytics purposes, the storage constraint is relevant in two ways.

First, organisations that store analytical data — historical snapshots, aggregated period summaries, calculated fields for reporting purposes — directly in BC custom tables are consuming their BC storage allocation for data that is better housed in an external analytical store. BC storage is priced for transactional data; Power BI Import mode datasets, Fabric Lakehouses, and Azure SQL databases are significantly more cost-effective per gigabyte for the type of aggregated, historical, read-heavy data that analytics workloads require.

Second, as BC environments grow and transaction volumes accumulate, the performance of BC's built-in reports against large ledger tables degrades. Moving analytical workloads to an external platform — Power BI connecting to BC via API or to a data warehouse staging layer — removes that query load from the BC environment entirely and allows both systems to perform well at their respective strengths: BC for transactional processing, Power BI for analytical reporting.

Three Ways to Connect Business Central to Power BI

There are three primary connection patterns for Microsoft Business Central analytics with Power BI, each suited to different organisational scales and analytical complexity levels.

1. Native Power BI Connector (OData)

Microsoft provides a native Business Central connector in Power BI Desktop that uses OData APIs to retrieve data from BC's published API pages. This is the simplest connection method — no custom development required, no data warehouse needed, and Power BI can connect directly to a BC environment using Entra ID credentials in under ten minutes. It is the appropriate choice for organisations with modest data volumes, relatively simple analytical requirements, and a preference for minimising infrastructure complexity.

2. Business Central API with Custom Pipelines

For organisations with larger BC environments or more complex analytical requirements, connecting via Business Central's published API pages through a data pipeline — Azure Data Factory, Microsoft Fabric Data Pipeline, or Power BI Dataflows — provides more control over extraction scheduling, incremental load patterns, and data transformation before the data reaches the semantic model. This approach moves BC data to a staging layer before Power BI reads it, rather than querying BC live on every dataset refresh.

3. Business Central to Microsoft Fabric via OneLake

For enterprise-scale analytics programmes — multi-company consolidations, long-period trend analysis, cross-source joining with SAP, Salesforce, or Workday — the full Fabric architecture is the appropriate choice. Business Central data is extracted via the API pipeline into a Fabric Lakehouse Bronze layer, transformed through Silver-layer Notebooks or Dataflows, and surfaced as a Gold-layer Power BI semantic model. This architecture is designed for the analytical workloads that outgrow both the direct OData connector and intermediate pipeline approaches.

The Power BI Business Central Connector and OData APIs

The Business Central OData API exposes BC data through a set of published API pages — standard entities defined by Microsoft and custom pages defined by the BC developer for each implementation. The standard BC API pages cover the most commonly needed financial and operational entities: general ledger entries, accounts, customers, vendors, items, sales invoices, purchase invoices, jobs, and dimensions. Custom API pages can be created to expose any BC table or query that the standard API pages do not cover.

The critical consideration for OData-based Power BI connectivity is performance. BC's OData endpoint is the same endpoint used by the BC client application — it is not a dedicated analytical endpoint. Large queries against high-volume ledger tables through OData can take minutes to complete and may impact BC user experience during business hours. For this reason, organisations connecting Power BI to BC via OData should configure their dataset refreshes to run outside business hours, use incremental refresh to reduce the data volume retrieved per refresh cycle, and monitor BC environment performance after enabling Power BI OData connections.

Business Central to Microsoft Fabric: The Enterprise Architecture

The enterprise architecture for Microsoft Business Central analytics follows the same Medallion pattern as other ERP-to-Fabric integrations. Business Central data flows from the API into a Bronze Lakehouse table — preserving the raw extracted record including BC's internal identifiers, dimension codes, and posting date structures. Silver-layer transformations resolve BC's dimension code structure into readable analytical categories, join multi-company environments into a consolidated dataset, and standardise the date and currency fields that BC uses across different modules. The Gold layer presents the analytics-ready fact and dimension tables that Power BI reads — typically a general ledger fact table, a customer dimension, a vendor dimension, an item dimension, a dimension set detail table for BC's flexible dimensions framework, and a shared date dimension.

The multi-company consolidation use case is the clearest justification for the full Fabric architecture over the direct OData connector. When a holding group needs consolidated P&L and balance sheet reporting across four BC companies operating in different currencies, the Fabric Silver layer is where the intercompany eliminations, currency translations, and dimension mappings are applied — producing a consolidated analytical dataset that no single BC environment can generate independently.

Key Business Central Data Entities for Financial Analytics

Effective financial analytics from Business Central depends on correctly extracting and modelling the specific BC entities that carry the analytical data. Four entities are non-negotiable for any BC financial analytics programme.

General Ledger Entries — the primary fact table for all financial analytics. Every posted financial transaction in BC generates a GL entry with a G/L Account number, posting date, amount, document number, and dimension set ID. The GL entry table is the source for P&L, balance sheet, cash flow, and cost centre reporting. It is also the highest-volume table in most BC environments and requires careful incremental extraction design.

Dimension Set Entries — BC's flexible dimension framework stores dimension values (cost centre, department, project, region) in a separate dimension set entry table rather than in the GL entry itself. Every GL entry carries a Dimension Set ID that references its dimension set entries. Joining these two tables correctly — resolving the dimension set ID to its constituent dimension codes and values — is the most technically complex part of the BC data model for analytics and must be handled correctly in the Silver transformation layer.

Customer and Vendor Ledger Entries — the source for accounts receivable and accounts payable analytics, including aged balance calculations, payment terms analysis, and cash collection performance. These entities provide the sub-ledger detail that the GL entries summarise.

Item Ledger Entries — the source for inventory analytics: stock movements, consumption, production output, and purchase receipts by item, location, and period. For organisations with significant inventory — manufacturers, distributors, retailers — this is the primary fact table for supply chain and operations analytics.

Combining Business Central with Other Enterprise Data Sources

The highest analytical value of an external Microsoft Business Central analytics platform is achieved when BC's financial data is combined with data from other operational systems. Three cross-source combinations are consistently the most impactful for mid-market organisations running Business Central.

Business Central + CRM (HubSpot, Salesforce, Dynamics 365 Sales). Joining BC sales invoice and customer payment data with CRM opportunity and account data enables revenue analytics that spans the full commercial cycle — from pipeline through to cash collection. Win rate, average deal size, and time-to-first-invoice analysis are not possible from BC data alone; they require the CRM dimension data.

Business Central + Project Management. Organisations that use BC's Jobs module alongside a project management platform — or use BC purely for financial posting while managing project delivery in a separate tool — can produce project profitability analytics that combine BC's cost and revenue posting with the project tracking data from the delivery system.

Business Central + Payroll. Combining BC's general ledger cost centre allocations with payroll system headcount and salary data enables labour cost analytics at the departmental level — per-headcount cost, payroll as a percentage of revenue, and workforce efficiency metrics that Finance leaders consistently request but that no single system can produce independently.

Connection Method Comparison

Next Steps for Your Business Central Analytics Programme

The starting point for most Business Central analytics programmes is assessing which of the three connection methods matches the organisation's current scale and complexity. A single-company SME with a manageable GL entry volume and straightforward financial reporting requirements can be live with a Power BI dataset connected via the native OData connector within a day. A multi-company holding group that needs consolidated reporting across entities in different currencies and countries needs the Fabric architecture — but can build that incrementally, starting with the primary operating company and adding entities as the programme matures.

For organisations already using other Microsoft data sources — HubSpot, Workday, SAP, ServiceNow — in a Fabric Lakehouse architecture, Business Central is simply another source that lands in the same Bronze layer and joins through the same Silver transformation process. The incremental cost of adding BC to an existing Fabric estate is significantly lower than building a standalone BC analytics programme from scratch.

If your organisation is ready to build a governed Microsoft Business Central analytics programme — whether through the direct Power BI connector or a full Fabric integration — speak with a certified BI and Fabric consultant at Numlytics. We work with finance leaders, IT directors, and analytics teams across the US, UK, Australia, and UAE to design and build BC analytics programmes that deliver reliable, executive-grade financial intelligence. For the broader Fabric integration context, see our guides on SAP to Microsoft Fabric and Microsoft Fabric capacity management.