Dynamics 365 Finance — The Parent System Your Entities Report Into

Dynamics 365 Finance is where a large share of mid-market groups end up once the group itself becomes the unit of management, and it has earned that position. It carries a dimension framework built for analysis rather than only for posting, it consolidates inside the product, and Microsoft maintains statutory reporting market by market. Of every system in this series it is the one whose owners are least likely to be short of data engineering. That makes what is still missing above it a more interesting question than usual, not less.

At a glance

What Dynamics 365 Finance is

Dynamics 365 Finance is the general ledger, receivables, payables, fixed assets, budgeting, cash and bank, tax and close engine of a large business, delivered as a service Microsoft operates. It descends from Dynamics AX, and the depth shows where depth is expensive to build: multi-entity posting, multi-currency with revaluation, accounting distributions on source documents, posting layers, allocation rules and ledger settlement.

The name has moved more than the product. Dynamics AX became Dynamics 365 for Finance and Operations, then split into Dynamics 365 Finance and Dynamics 365 Supply Chain Management. Microsoft’s collective term is finance and operations apps, and that is the phrase to search on, because the integration documentation is written at family level. Business Central is a different code base entirely and has its own article in this series .

The two tiers, and the platform underneath

The licence choice is narrow: Finance for core financials, Premium for the few people who author plans. The consequential fact sits below it. Because Finance and Supply Chain Management are one application on one database, a group licensing both has stock, production, projects and the ledger in the same environment, joinable without an integration — a real advantage for a reporting layer, and one Microsoft’s mid-market product cannot match at the same depth. Every entity that is not on Finance, of course, sits somewhere else entirely.

Who Dynamics 365 Finance fits

Groups where the group is the unit of management. Several legal entities, more than one currency, statutory obligations in more than one country, a finance function closing centrally. Finance handles that natively; few systems in this series do.

Companies that outgrew a mid-market ERP rather than outgrew ERP. The trigger is rarely volume. It is complexity: intercompany trade, accounting distributions that have to hold, allocation rules, a close calendar with real dependencies. Finance is scoped for exactly that, and moving to it is normally the right decision.

Manufacturers and distributors running Supply Chain Management alongside it. One application, operational and financial depth in the same place — where Finance is most clearly worth what it costs.

Czech and Polish entities inside international groups. Poland is the strongest case in the region: Microsoft ships generation and direct submission to the governmental KSeF system in Dynamics 365 Finance, plus import of vendor electronic invoices. That is Microsoft’s own code, and it is not in Business Central — an easy and expensive thing to assume the other way round. Elsewhere in CEE coverage is uneven, and where Microsoft does not supply the localisation, statutory specifics come through Electronic reporting and partner apps. Confirm which applies to each of your markets.

Groups that grew sideways. Dynamics 365 Finance in the parent and the two largest subsidiaries, Business Central in the entity acquired three years ago, POHODA in the small Slovak trading company, a spreadsheet for the joint venture. Every one of those choices was locally correct. Nobody owns the view across them, and this is the most common context in which Finance reaches us.

What Dynamics 365 Finance holds — and why it is good material

Before the reporting question, the asset — and here it is unusually good.

Dynamics 365 Finance holds a full accounting model rather than a set of balances. Every posted amount lands in the general journal account entry with its ledger dimension, posting layer, source document, accounting distributions and transaction currency alongside the reporting currency. Subledgers reconcile because the application makes them, and the data quality in a well-run Finance environment is usually the best we meet anywhere in an estate.

The financial dimensions framework is the part worth understanding properly, because it is where profitability analysis lives and because it differs from the mid-market pattern. Dimension values are not tags hung off an entry; they are segments of the ledger account itself. Custom dimensions are maintained by hand and shared across legal entities; entity-backed dimensions take their values from elsewhere — projects, customers, operating units — and can be suspended per entity through legal entity overrides. A dimension set, an ordered list of up to eleven attributes, defines how the ledger summarises for a trial balance.

Two consequences follow, both structural rather than accidental.

The first is the join. The ledger dimension on a posted entry is a foreign key into a combination table holding the full multi-segment account, and the framework spreads one combination across several tables — Microsoft’s developer documentation describes saving a single segment as requiring a record in each of four, and dimension activation as a schema change that adds a column per dimension. The dimensions are there, they are complete, and they are not columns you can select. Every reporting route has to resolve them, Microsoft’s included.

The second is that a posted dimension is part of the account. Microsoft says so in the clearest possible way: financial tags — twenty user-defined fields offered as an alternative to dimensions — can be corrected after posting, because tags “aren’t part of the ledger account and don’t affect financial statements.” Dimensions are. Nor can a dimension be deleted once used, which Microsoft explains “is by design and preserves reporting accuracy and audit integrity.” Correct behaviour for a ledger. It also means the dimension design chosen at implementation is the design you have, so the place to reinterpret it is above the ledger.

What sits outside Dynamics 365 Finance’s scope

Dynamics 365 Finance is scoped to running the accounting of a large business correctly, at scale, in several countries at once. Three things sit outside it, each boundary drawn deliberately.

The view across systems. Whether the parent’s revenue reconciles to a subsidiary’s on a different ERP, whether the e-commerce platform agrees with the ledger, whether payroll agrees with headcount. Finance consolidates legal entities inside itself ably; for entities outside it, there is Consolidate with import, which is a file. This is worth saying plainly: no ERP does this. Not Dynamics 365 Finance, not SAP S/4HANA, not NetSuite. Cross-system truth is a layer above every transaction system — the point we make at more length here .

Definitions that live in the report layer rather than in a governed model. Financial reporting is capable and long-proven — 22 default reports, reporting trees, drill-back to the originating transaction. Three documented behaviours shape it: uninstalling the add-in “permanently deletes any previously created reports, report designs, and configurations”; generated reports expire after 90 days by default; and since release 10.0.45 a drill-down recalculates against current data rather than a stored version, so a final report has to be exported for an immutable audit copy. That is a report writer behaving like a report writer — not a data model a dashboard or an AI assistant can query across a group.

The analytical model above the export. This is where the enterprise tier gets misread. Microsoft ships a genuinely good first-party analytics story, and more than one route in.

Any of them will put Finance data where a BI team can reach it. None decides what the numbers mean. A lake gives you tables at a known cost and latency — not a management chart of accounts, resolved dimensions, agreed definitions, or the entities that are not on Finance.

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

How we elevate it

We connect Dynamics 365 Finance in single-tenant groups and in mixed estates, most often as the parent above subsidiaries running something else.

Getting the data out starts from the fact that direct SQL is not on the table, and being straight about that is most of the job. Our default is Azure Synapse Link for Dataverse into storage the client or we control: a conventional incremental extract, holding history independently of what any reporting product will serve today, and leaving the model somewhere we can govern. Depending on what the group already runs we take one of the other routes above instead — Link to Fabric where the group is already on Fabric, business performance analytics as a source where its window is enough, or data entities and OData for narrow reads. Read-only throughout, nothing written back, and users notice no difference in how the system performs.

What happens next is the Dynamics 365 Finance-specific work.

The management chart of accounts, mapped once and held above the ledger

The statutory chart keeps doing its job, and in a Finance estate it usually does it well across several jurisdictions at once. 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. Consolidation account groups give you a mapping mechanism inside the ERP, but it resolves into a consolidation legal entity where daily journals cannot be posted, and a main account cannot be reinterpreted retrospectively without touching the ledger. Held above it, the mapping is versioned, owned by a named person, and reviewed at each close: chart of accounts architecture .

The financial dimensions, resolved and put to work

We resolve the dimension framework once, so every posted entry carries its dimensions as plain columns — the combination table joined out, entity-backed values matched to their source records, legal entity overrides and suspended values accounted for. Doing it once, in a governed model, is the difference between a group that can ask questions by cost centre and a group that re-derives the same join in every report.

Then we audit the framework rather than assume it: which dimensions are filled, on which accounts and entities, and how consistently across history. Where a group has used financial tags we bring those in too — tags can be corrected in place after posting, dimensions cannot. Where dimension history is wrong and cannot be repaired in the ERP, the corrected view lives as a mapping above it: the ledger stays internally consistent and the reporting still comes out right.

One view across the group, including the entities that are not on Dynamics 365 Finance

Each Finance legal entity becomes one entity in a common model, next to another Finance environment, a Business Central company, a SAP Business One or Helios installation, a payroll export or a spreadsheet — all producing the same standardised output. Group reporting in any currency with currency translation applied consistently, intercompany elimination that does not depend on every entity sitting inside one ERP, reconciliation across systems as a daily control, and drill-down from a consolidated figure to the voucher behind it. Where a group already consolidates inside Finance for statutory consolidation , we reconcile to it rather than replace it.

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 .

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 sharpen the longer it runs.

What becomes answerable

• What is group EBITDA in one currency this morning, when three entities are on Dynamics 365 Finance and four are not?
• Which customers are actually profitable after delivery and service cost, against budget and last year — not just gross margin on the invoice?
• Which dimension combinations are carrying gaps, and in which entities, before the close rather than after it?
• Does the consolidated figure agree with the sum of the entities that produced it, and where does it not?

Every one of these is answered from data Dynamics 365 Finance 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 Dynamics 365 Finance client the connection is a read-only service principal against a supported export route, 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: Dynamics 365 Finance 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.

When the system underneath changes

Dynamics 365 Finance is usually the destination rather than the departure point. It arrives to replace a mid-market ERP a group has outgrown, or to standardise an estate that accumulated six systems — a programme that runs for years, entity by entity, with the reporting question outliving every phase of it. Sometimes the change is internal instead: an AX 2012 upgrade, or an implementation that resets the dimension design.

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, because they can prove the new system’s numbers against the old from day one and keep their history through the change. For a group midway through rolling Finance out across its entities, that is the only way it reports consistently while the estate is half-migrated.

Not a theoretical claim: when JING Tea replaced its operational stack, the reporting layer carried through unaltered — the systems underneath moved, the numbers and the reports did not.

How Dynamics 365 Finance compares

In a group, Dynamics 365 Finance usually sits above two or three of the others. Each gets its own article in the series .

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

Frequently asked questions

Do we need to replace Dynamics 365 Finance to get proper management reporting? No, and we would usually advise against it. Keep Dynamics 365 Finance for statutory correctness across several countries, multi-entity posting, intercompany and a close that holds together, and build the reporting layer above it. Replacing a working ERP to solve a reporting problem costs years as well as money, and solves the wrong problem.

Is Onetribe a replacement for Dynamics 365 Finance? No. Dynamics 365 Finance 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 layer stays.

What database does Dynamics 365 Finance use, and can we read it directly? There is no customer SQL connection to production — Microsoft’s documented position is that the application does not allow T-SQL connections to the production database. Sandboxes differ: just-in-time access grants an account behind a firewall entry that expires after eight hours, useful for profiling and reconciliation, and not a reporting pipeline. The supported production read paths are the four in the table above.

Can Dynamics 365 Finance consolidate several companies? Yes, and better than most systems in this series. Consolidate online works at account and dimension level across legal entities with differing charts of accounts and fiscal calendars; Financial reporting consolidates again at report generation, with drill-back to the original transaction. Its edges: single-level consolidation re-run whenever a source entity changes, operating balances only, minority interest by hand. And no ERP consolidates an entity that is not in it — the most common reason multi-entity Finance groups come to us.

Is Business performance analytics enough? For a group entirely on Dynamics 365 Finance, often yes for a first year — and worth using before adding anything, because it is included in the licence and installs in about an hour. It builds a real dimensional model, covers finance, supply chain, project and commerce, and reaches Fabric without an export. Where it runs out is in the route table above. Neither it nor Financial reporting is a place to keep definitions a group has to defend for years, and neither reads a system that is not Finance.

Can Dynamics 365 Finance connect to Power BI? Yes, several ways. Embedded analytical workspaces put Power BI content inside the client, business performance analytics is a Power BI application in all but name, and Synapse Link and Link to Fabric put the tables where Power BI can query them directly, including in Direct Lake mode. The durable pattern is the same in every case — report on a governed model rather than on raw entities, so definitions survive the next service update and the next dimension change: BI reporting .

We already have a Synapse export, a Fabric workspace and a BI team. What would you actually add? Not pipes. You have those, and if they work you should keep them. What we add is what pipes do not contain: a management chart of accounts held above the statutory one and versioned; dimensions resolved once rather than re-joined in every report; definitions of margin, overhead and contribution that are the same in the board pack, the entity report and the AI answer, owned by a named person; daily reconciliation across systems, not only within Finance; and the entities that are not on Finance, in the same model as the ones that are. In most enterprise estates we meet, the engineering is done and the governance is nobody’s job — that is the gap, and another export does not close it.

We are a Dynamics 365 Finance parent with subsidiaries on other systems. Where do we start? With the smallest thing that produces a group number you trust — Finance plus the one or two subsidiaries that cause the most argument at close, mapped to a common chart, reconciled daily, in one currency. That is weeks rather than a programme. The rest of the estate joins afterwards, one system at a time, so standardisation runs on its own timetable instead of gating group reporting.

Official Dynamics 365 Finance resources

• Dynamics 365 Finance product overview — Microsoft
• Dynamics 365 Finance documentation — Microsoft Learn
• What is Business performance analytics?
• Choose finance and operations data in Azure Synapse Link for Dataverse
• Financial dimensions
• Financial consolidations and currency translation

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 Dynamics 365 Finance estate — free assessment