Find out why your Dynamics 365 numbers don't reconcile

Your Power BI numbers fail to match Dynamics 365 because the report is built on a transactional data model designed to run the business, not to report on it, so figures double-count, drop an intercompany elimination, or roll a financial dimension up in the wrong order. The fix is a governed model beneath the report, not a better-looking dashboard.

The problem is almost never the dashboard. It is what the dashboard is built on.

Dynamics 365 is a transactional system. Its data is shaped to capture operations correctly, not to produce a board-grade figure. The finance logic that turns raw transactions into a number you can defend lives above the transactions, not in them, so point Power BI straight at the tables and a report can look right at row level and quietly fail to reconcile.

On Finance & Operations, a single figure has to survive financial dimensions that must combine in the right order, multiple legal entities with different charts of accounts that have to map to a consolidated one, intercompany eliminations that must be removed before the group total is right, and reporting trees that depend on the correct hierarchy at the report date. Ready-made Power BI content does not include financial dimensions by default. Miss any one of these and the slice is wrong.

On Business Central, the trap is different but has the same effect. Reporting sits across dimensions, multiple companies, and a model never shaped for cross-company analytics. It works until consolidation, then it breaks.

The reliable figure needs a governed semantic model between Dynamics and the report: a layer that defines each metric once, in the language finance uses, and computes it the same way every time. A health-check's job is to find exactly where that layer is missing or wrong.

For the plain-English version of this, talk to us about why your Power BI numbers don't match Dynamics 365.

Your Dynamics 365 reporting cannot be trusted yet if your finance team rebuilds the month-end in Excel, your entities will not roll up cleanly, or nobody is sure which version of a figure is right, and a health-check tells you why before you spend anything on a fix.

You do not need a full diagnosis to recognise the symptoms. Most teams that come to us see themselves in this list:

• Month-end lives in Excel. Finance rebuilds the month-end by hand because the standard reports do not reconcile.
• Entities won't roll up. Intercompany and multi-entity figures will not consolidate cleanly, usually after growth or an acquisition.
• Two numbers for one metric. The same metric shows two different values in two different reports.
• Refreshes are slow or unstable. No one is quite sure how the data even gets in.
• One-person dependency. Reporting depends on a single person, and would stall if they left.
• Unsure about the pipeline. You are not certain whether you are still on the retiring Export to Data Lake route.

If two or more of these are true, the reporting health-check is built for you.

A PrecisionPoint reporting health-check assesses six things: reconciliation gaps, your data model and semantic layer, multi-entity consolidation, your refresh and architecture, governance, and licensing and capacity. The one a generic Power BI audit does not do is reconcile each figure back to the Dynamics finance source, and that is where the answer to "why don't our numbers match" is found.

A generic Power BI audit checks the reporting environment. This checks whether the numbers are true. Six checks, one findings report.

• Reconciliation gaps. Does each key figure reconcile back to the finance-owned source in Dynamics, and where and why does it break? This is the wedge. Most health-checks skip it because they are ERP-agnostic; it is the check that finds the actual cause.
• Data model and semantic layer. Is there a governed semantic model, or is Power BI pointed straight at the transactional model? We check whether metrics are defined once or conflict, and whether financial dimensions and reporting trees are handled correctly.
• Multi-entity and consolidation. Are multiple Dynamics 365, AX or NAV entities rolled up correctly, with intercompany eliminations and dimension mapping intact? This is where we map your current estate, and the most common post-growth, post-acquisition failure.
• Refresh and architecture. Is the pipeline stable and the performance sound, and are you on a supported path? We check whether reporting still depends on the retiring Export to Data Lake route or has moved to the supported successors, Synapse Link for Dataverse and Link to Fabric.
• Governance. Workspace and tenant sprawl, row-level security, version control, and ownership. We check whether trustworthy reporting depends on one fragile individual, and what happens the day they are unavailable.
• Licensing and capacity. Pro versus PPU versus Microsoft Fabric F-SKU, whether the fit is right and the cost is sensible, and whether any part of your estate sits on a retiring SKU. With Power BI Premium P-SKUs retiring in favour of Fabric capacity, this is a live question worth a specialist's read.

You walk away with a decision-grade findings report: your current state, the specific reasons your numbers don't reconcile, prioritised recommendations split into quick wins and a fuller fix, and a clear next step. Not a vague slide deck, and not a sales call dressed up as an assessment.

It is fixed scope with a transparent cost, shown before you commit. No surprises, and no obligation to go further than the evidence justifies.

Both are covered. The reconciliation mechanics differ, so the check adapts to whichever you run: on Finance & Operations the difficulty concentrates in entities, intercompany eliminations and financial dimensions; on Business Central it sits in dimensions, multiple companies, and a model that was never shaped for analytics.

On Finance & Operations, the hard part is scale and structure: financial dimensions that must combine correctly, multiple legal entities mapping to a consolidated chart of accounts, and eliminations that have to be removed before the group total holds. The health-check tests each of these against your finance source.

On Business Central, the shape of the problem is the same at SME scale. Reporting works across dimensions and separate companies until consolidation transfers the entries into one company, and that is where trust usually breaks. The check follows the same logic, tuned to how BC handles it.

Whichever you run, the diagnosis is grounded in how Dynamics actually posts and consolidates, not in a generic Power BI review.

After the health-check you choose the next step on the evidence, with no obligation: it qualifies you into the build, into Managed BI, or into advisory. Because the findings are a neutral read, finance can forward them and IT can bless them before any budget is committed.

The health-check is the top of a three-step offer ladder, not a one-off. It tells you exactly what, if anything, needs doing, and hands you the evidence to decide the next step rather than committing to a big-bang programme.

1. Diagnose.

   The health-check you are reading about: the findings report that tells you where and why your reporting stops reconciling.

2. Build.

   If the evidence says fix it, the Power BI build for Dynamics 365 puts the governed model in place so the numbers reconcile and keep reconciling.

3. Run.

   Once it works, Managed BI keeps it running, and advisory shapes governance and strategy where you need it, so reporting stays trustworthy without depending on one person.

You are never committed further than the value you have already seen. Where you enter depends on what the diagnosis finds, and this diagnostic sits inside the wider Power BI for Dynamics 365 programme.