Business Central — One Product, Two Ways In

Business Central is the system a large share of growing mid-market companies land on, and it has earned that position. Microsoft has kept it current on a twice-yearly release cadence, opened a substantial API surface, and connected it to a stack most finance teams already own. Of every system in this series, it is the one whose data is most deliberately made available — which makes what remains missing above it a more interesting question than usual.

At a glance

What Business Central is

Business Central is Microsoft’s ERP for companies too substantial for accounting software and not large enough for an enterprise suite: general ledger, receivables and payables, fixed assets, stock and warehousing, projects, and — in the Premium licence — manufacturing and service management. Microsoft’s documentation prefers business management solution; its marketing says ERP. Both are fair.

The lineage matters because a large part of the installed base is still living in it. Business Central descends from Navision, acquired by Microsoft in 2002 and renamed Dynamics NAV, and took over the same application code base in 2018; as of mid-2026 only NAV 2017 and 2018 retain even extended support. The current product ships two major releases a year plus monthly regulatory updates, and on-premises releases continue with no announced end of life — though some features, Copilot among them, will not come to on-premises. For finance in a mid-market group the appeal is coherent: one ERP that speaks natively to Entra ID, Excel, Teams and Power BI, priced per user, with partner coverage in every market we work in.

The two deployments, and the estate still upgrading into them

Business Central is one product with two deployments, and for anyone who has to read the data they are not the same thing. This is the most consequential fact on this page.

Microsoft states the boundary itself, and the sentence is worth reading twice: “For Business Central on-premises, you can just read directly from the environment database. This option isn’t available for Business Central online… For Business Central online, the only supported option for reading data is using APIs.”

That is not a gap. It is the consequence of running a multitenant service — Microsoft cannot hand out SQL logins to a shared fleet and keep its performance commitments to everyone else on it. The same reasoning produces the documented API limits, which Microsoft explains just as plainly: without them, one tenant could consume resources that belong to another.

On-premises and NAV read differently, and the schema is worth knowing before you start. Where a table holds company-specific data, its SQL name is prefixed with the company name — so a five-company database has no company column, it has five physically separate general ledger entry tables, and renaming a company renames its tables.

The NAV estate is the live commercial question. A NAV customer cannot migrate straight to the online service. Microsoft’s supported ladder runs NAV, then version 14 on-premises, then version 25, then current — with the application converted from C/AL to AL along the way. That is a real project with a real budget, usually scheduled against operational priorities rather than reporting ones. Which is precisely why the reporting layer should not wait for it.

Who Business Central fits

Companies outgrowing accounting-led software. Stock across several locations, projects that need costing, an approval chain too important to run on email. Business Central is the most common next step for a company that has outgrown a POHODA, a Money or a Xero, and it is usually the right one.

Groups standardising a mixed estate. A group with six local systems picks one, and Business Central is frequently the choice — familiar stack, partner coverage in every market, per-user pricing that scales down to a small subsidiary. Worth knowing before committing: standardisation takes years, and the group needs a reporting answer in the meantime.

Manufacturers and service businesses on the Premium licence. Production orders, capacity, service contracts and dispatch. Premium is what separates Business Central from most accounting-led systems in this series, and the operational depth is real.

Slovak, Czech and Polish entities inside international groups. This one needs care, because the localisation picture is uneven and it is the picture our market lives in. Microsoft supplies and actively maintains the Czech localisation; Slovakia and Poland are localised by partners on the international base application, so Slovak kontrolný výkaz DPH and eKasa, and Polish JPK and KSeF, come from partner apps rather than from Microsoft. (Microsoft’s own KSeF submission ships in Dynamics 365 Finance, not in Business Central.) None of this makes Business Central the wrong choice here — it does mean the estate is Business Central plus named partner apps, and a reporting layer has to know which.

Groups that grew sideways. Business Central in the parent, POHODA in the Slovak trading company, something else again in the entity acquired last year. Every one of those choices was locally correct. What nobody owns is the view across them, and this is the context in which Business Central most often reaches us.

What Business Central holds — and why it is good material

Before the reporting question, the asset.

Business Central data is well structured, and structured for analysis rather than only for posting. The general ledger entry table carries around ninety fields — source type and number, business unit code, intercompany partner code, the dimension references. Postings are traceable to their register, and the ledgers reconcile because the application makes them.

The dimension framework is the part worth understanding properly, because it is where profitability analysis lives. Business Central supports two global dimensions and eight shortcut dimension slots — the globals occupy slots one and two. Global dimensions filter anywhere in the product; the rest reach ledger entry pages and Excel exports. Companies typically set the globals to something like cost centre and department, and use the remainder for project, customer group, brand or region.

One design decision inside it has to be planned for. Business Central does not repeat dimension values on every entry: it stores each unique combination once as a dimension set and writes only the set ID onto the entry, which is efficient for posting, exactly as intended. For reporting, that means dimensions arrive as a separate many-rows-per-entry table to be joined and flattened before anything can be built on it. Microsoft reached the same conclusion for its own Power BI apps, which read from a purpose-built flattened dimension table maintained by a scheduled job rather than from the transactional one. When the vendor’s own reporting product needs a reshaped copy of the data, that is a fair signal about where reporting belongs.

And the data quality is usually good. Against what we more often meet — spreadsheet consolidations, half-configured cloud tools, a decade of manual journals — a properly run Business Central is a strong starting point. The quality of a reporting layer is bounded by what feeds it.

What sits outside Business Central’s scope

Business Central is scoped to running a business well. Three things sit outside that scope, and each boundary is drawn deliberately.

The view across companies, at transaction level. Business Central does consolidate, and more capably than most systems in this series — business units can differ in chart of accounts, fiscal year and currency, and the transfer can run across environments or by file. But the mechanism is a batch transfer of totals: for every combination of selected dimensions and date, entry amounts are summed and exported. Microsoft is direct about the result — “the consolidated company is just a container for the consolidated data, and doesn’t have any live business data” — and eliminations are entered manually. So the group total is available; the drill from that total to the invoice behind it is not. For statutory consolidation with a stable structure that is often enough. For a management group view people interrogate, it is the wrong shape.

The view across systems. Whether e-commerce revenue matches the ledger, or the payroll run matches headcount in the HR system. This is worth saying plainly: no ERP does this. Not Business Central, not SAP, not NetSuite. Cross-system truth is a layer above every transaction system, which is the point we make at more length here .

The management view, held somewhere durable. Financial Reporting is capable — row and column definitions, dimension filters, budget comparison, drill-down to entries. Two limits shape it: report definitions are not versioned, so changing one replaces the previous version; and the account category mapping behind the shipped statements is provided for the United States version only. Analysis mode is scoped to quick fact-checking — views are private to whoever made them, and there is a hundred-thousand-row wall. All of that is reasonable for what it is. None of it is a data model a dashboard or an AI assistant can query across a group.

None of this is a reason to change system. It is a reason to add a layer.

How we elevate it

We connect Business Central in both deployments and alongside the NAV estate, in single entities and in groups running it next to other systems.

Getting the data out depends entirely on which deployment you have, and being precise about that is most of the job. On Business Central on-premises or NAV, our default is a read-only SQL login against the environment database — or better, a read replica, once read scale-out is enabled. On Business Central online, direct SQL does not exist and we do not pretend otherwise: the supported route is a purpose-built read-only API query with read scale-out set, extracting incrementally against the SystemModifiedAt watermark, with a one-time historical load taken from a database export. Microsoft’s own throughput guidance gives the honest planning number — roughly a day to pull a hundred-gigabyte history once, and comfortably inside a nightly window thereafter. One thing we build for from the start: exposing a standard Microsoft page as an OData endpoint, the classic quick route to Power BI, is being removed in version 30 — the 2027 release wave 1. Anything built that way has a known expiry date. Read-only throughout, nothing written back, and users notice no difference in how the system performs.

What happens next is the Business Central-specific work.

The chart of accounts, mapped once for management

The statutory chart keeps doing its job. We map it to a second structure built to answer management questions — revenue by what you actually sell, cost by what you actually control, margin at the level you actually decide. In Business Central this step earns its keep twice over: outside the United States version the account category mapping is yours to construct anyway, and report definitions inside the product are not versioned. Mapped once, versioned, owned by a named person, reviewed at each close so it does not drift. More on the design problem underneath: chart of accounts architecture .

The dimension framework, flattened and put to work

We flatten dimension sets into the model once, so every entry carries its dimensions as columns rather than as a join — the same move Microsoft makes for its own Power BI apps, done for your definitions rather than theirs. Then we audit how consistently the dimensions have been filled across history and agree what gets enforced going forward: in Business Central that means default dimensions with Code Mandatory value posting on the accounts that matter, and priorities set per source code.

One thing to know before relying on retrospective repair. Business Central ships a dimension correction tool for posted general ledger entries, and it works — but Microsoft is explicit about its reach: “Dimension corrections apply only to the G/L entries. They don’t change the dimensions assigned to the entries in other ledgers for the same transaction.” Correct the ledger and the subledgers no longer agree with it. In the governed layer we hold the corrected view as a mapping above both, which keeps the ERP internally consistent and the reporting correct at once.

One view across companies, environments and systems

Each Business Central company becomes one entity in a common model — beside another Business Central environment, a POHODA database, a Helios or SAP Business One installation, an e-commerce platform, a payroll export or a spreadsheet, all producing the same standardised output. Group reporting in any currency with currency translation applied consistently, reconciliation across systems, and drill-down from a consolidated total back to the Business Central entry that produced it — the step the ERP’s consolidated company cannot offer.

This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.

What becomes answerable

• Which customers are actually profitable, after delivery and service cost — not just gross margin on the invoice?
• What is group EBITDA in one currency, when three entities sit in Business Central and two sit on something else?
• What did that project cost against what we quoted, while it is still running?
• Why did overhead move this month, ranked by the cost lines that moved most — against budget and against last year?
• Which entities are carrying dimension gaps, and on which accounts, before the close rather than after it?
• Where does the reported number differ from the booked number, and why?

Every one of these is answered from data Business Central is already holding. The information was there. What was missing was the structure to ask.

What it takes, and what does not change

Connection in days. First reports in the first week. For a single-entity Business Central client the connection is a read-only login or a service principal, and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.

What we need from you: an NDA, read-only access, and a conversation about what the numbers should mean.

What does not change: Business Central stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back.

Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.

In practice

Business Central runs across our client base, and it is read the way this page describes: read-only, incrementally, with the dimension framework flattened into the governed model before anything is reported on it. Donaufarm and Vega Solutions are both on Business Central and both are connected that way.

A third case is worth naming, because it surprises people. MB Trenčín runs INCADEA — the dealer management system built on the same Microsoft platform Business Central descends from. From the data layer’s point of view it reads like the Dynamics estate it comes from: the same lineage, the same dimension thinking, the same route to the data. A system that looks industry-specific from the front is very often a familiar platform underneath, which is why “ours is a niche system” changes the answer far less often than people expect.

When the system underneath changes

Business Central is usually the destination rather than the departure point — it arrives to replace something a company has outgrown, or to standardise a group that accumulated five systems. Occasionally it is replaced in turn, generally by Dynamics 365 Finance when a group passes the point it is scoped to serve.

In every direction the same thing holds: because the governed layer sits above the ERP, only the connection changes. The data model, the reports, the dashboards and the consolidation logic stay as they are. Clients who built the layer first find the migration measurably easier — they can prove the new system’s numbers against the old from day one, and they keep their reporting history through the change. For a NAV estate facing the upgrade ladder, that is worth more than it sounds.

This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not.

How Business Central compares

Business Central is one of several capable systems in the estates we work in. Each gets its own article in the series .

From a data-layer perspective the choice matters less than it appears. Each of these becomes an entity in the same governed model, which means the ERP decision can be made on operational fit rather than on reporting fear. The full matrix — including the Polish stack — is on the series hub .

Frequently asked questions

Do we need to replace Business Central to get proper management reporting? No, and we would usually advise against it. Keep Business Central for what it does well — transaction capture, operational control, statutory correctness, an approval chain people follow — and build the reporting layer above it. Replacing a working ERP to solve a reporting problem is an expensive way to solve the wrong problem.

Is Onetribe a replacement for Business Central? No. Business Central remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change ERP later, the reporting layer stays.

What database does Business Central use, and can we read it directly? Business Central online runs on Azure SQL Database, one isolated database per tenant, with no customer-facing SQL connection — Microsoft’s documented position is that APIs are the only supported way to read it. Business Central on-premises and Dynamics NAV run on SQL Server and can be read directly, read-only, which is our default where the deployment allows.

Can Business Central connect to Power BI? Yes, several ways — nine shipped Power BI apps, which work per company and online only; the Power BI Desktop connector; or reports embedded back into Business Central pages. Reading straight from the product lands every user’s refresh on your live environment, which Microsoft notes can affect performance — and the quickest route, publishing a standard page as an OData endpoint, is being removed in version 30. The durable pattern is Power BI on a governed model, with definitions somewhere that survives the next release wave.

Can Business Central consolidate several companies? Yes, by batch — differing charts of accounts, fiscal years and currencies are handled, with cross-environment transfer. But it transfers totals rather than transactions — there is no drill from a group figure to the invoice behind it, and eliminations are entered manually. For a stable statutory group that is often sufficient; wanting to interrogate the group number is the most common reason multi-entity Business Central users come to us.

Does Business Central have an API? Yes, and it is a real strength — a REST API v2.0, OData v4, and custom API pages and queries built in AL, the supported design for analytical extraction. The standard general ledger entry endpoint exposes thirteen properties of the ninety on the underlying table, with no dimension columns, and standard APIs cannot be extended with extra fields — a custom API is the answer, not a workaround. Throughput is governed: six thousand requests per five-minute window per user, five concurrent, twenty thousand records per page.

What about payroll? Payroll sits outside base Business Central in most countries, including Slovakia, Czechia and Poland, and is typically handled by a partner application or a separate payroll system. The layer reads both, so people cost lands next to the P&L it belongs to.

Is Microsoft’s own reporting enough? For a single company, often yes — and worth using before adding anything. Financial Reporting, Analysis mode and the Power BI apps each do credible work, and each runs out in the same place: across companies, across systems, and anywhere a definition needs to be shared and governed rather than held privately. If Business Central is your only system and one company is your whole business, start there.

Official Business Central resources

• Business Central product overview — Microsoft
• Business Central documentation — Microsoft Learn
• Extracting data from Business Central
• Operational limits for Business Central online
• Country and regional availability, and which countries Microsoft localises
• Consolidating financial data from multiple companies
• Upgrade paths from Dynamics NAV

Onetribe is not a Microsoft partner or reseller. We build the governed data layer above your ERP, whichever ERP that is.

Next steps

• Every source system we connect — the series hub, with the full matrix
• How we consolidate any combination of ERPs — group reporting
• Why your ERP doesn’t govern your data — the cross-system layer, in detail
• Discuss your Business Central estate — free assessment