Reporting on Dynamics 365 that finally reconciles

Power BI numbers usually fail to match Dynamics 365 because the report is built directly on a transactional data model that was designed to run the business, not to report on it, so figures double-count, miss an intercompany elimination, or aggregate a financial dimension in the wrong order. The fix is a governed data model underneath the report, not a better-looking dashboard.

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

On Finance & Operations, a single figure has to survive multiple legal entities, intercompany eliminations, and financial dimensions that must roll up in the right order before a board pack means anything. Point Power BI straight at that data and it will look right and quietly fail to reconcile. This is not a Power BI weakness. It is what happens when a reporting tool is asked to resolve accounting logic that lives in the ERP's own posting rules.

On Business Central, the trap is different but has the same effect. The reporting a growing business needs sits across dimensions, multiple companies, and a data model that was never shaped for analytics. A report built without accounting for that structure works until the month it doesn't, usually at consolidation.

The fix is a governed model between Dynamics and the report: a semantic layer that defines each metric once, in the language finance actually uses, and computes it the same way whoever runs it and whenever they run it. Analysts call this a semantic model, and it is the single element most Power BI shops and most ERP implementers get wrong, because it demands you understand the Dynamics data structure, not just Power BI. It reconciles back to Dynamics every time, and it is where this programme starts.

Microsoft deprecated Export to Data Lake for finance and operations apps and has begun decommissioning it; the supported successors are Synapse Link for Dataverse and Link to Fabric. If your Power BI still refreshes through the old export, your reporting sits on a pipeline Microsoft no longer maintains, and moving it is the right moment to fix the model underneath rather than lift-and-shift the same broken numbers onto a new pipe.

If your Dynamics reporting pipeline was built a few years ago, there is a good chance it runs on Export to Data Lake. That path has been retired. Microsoft deprecated it in October 2023, ended active use from November 2024, and began decommissioning the service in 2025. The supported successors are Synapse Link for Dataverse, which continues to export your data on a managed pipeline, and Link to Fabric, a no-copy, no-ETL option where the data never leaves the Dataverse governance boundary and authorised users query it directly in Microsoft Fabric. Both give you one experience across every Dynamics 365 app and a more efficient data format underneath.

Most organisations treat this as plumbing and lift-and-shift the same unreliable reporting onto the new pipe. That is a repeated mistake. The move is the right moment to put a governed model in place, so you come out of it with reporting that reconciles rather than the same numbers arriving through a newer channel. It is also the foundation any tenant-wide Copilot on Dynamics data has to sit on: an AI assistant reading an ungoverned model will answer confidently and wrongly.

This programme covers the migration and uses it to fix the foundation. If you are not sure which pipeline you are on, that is one of the first things the assessment tells you.

The fix runs in three incremental steps: first one trusted report, then reporting that reconciles across every entity, then a governed capability that runs itself, and each step delivers something you can use before the next begins. Most organisations enter at step one and move along it as trust builds, never committed further than the value they have already seen.

We do not sell a big-bang programme. We build in the sequence a finance leader can actually fund: prove it small, extend it where it earns the right, then make it permanent.

1. Your first trusted report.

   Start where the pain is sharpest, usually one finance or operational report that has to be right. We establish the governed model underneath it, prove the numbers reconcile back to Dynamics, and hand you a single report leadership can rely on. It is deliberately small: the point is to prove the method on something that matters before you commit to more. For most teams this begins with the Reporting Trust Assessment, which tells us, and you, where reporting stands today, and what the fix will cost before you spend anything on it.

2. Reporting that reconciles across the business.

   Extend the governed model out from that first report to the reporting the business actually runs on: finance, operations, sales, across every entity and company that has to roll up. Consolidate multiple Dynamics, AX or NAV instances into one group view where that is the problem. By the end of this step the numbers count the same way everywhere, and no one is rebuilding the month-end in Excel. This is also the step where the model starts to carry a real narrative. The semantic layer defines the metrics finance argues about once, so a figure means the same thing in every report that cites it.

3. A capability that runs as part of the business.

   Move reporting from a project you finished to a capability that keeps running. Governance you keep, security that holds, and Managed BI so the refresh, the monitoring and the incident cover are someone's defined job, not an internal person's spare time. Reporting stays trustworthy and fast as the business grows, without depending on any single individual to keep it alive.

Each step stands on its own. Where you enter depends on how broken your reporting is today, which is exactly what the assessment tells you.

The programme covers the full Power BI lifecycle on Dynamics 365: a reporting health-check, the build, the data model and semantic layer, multi-entity consolidation, migration onto the supported data pipeline, and the governance and Managed BI that keep it running. Each is a genuine capability with a business outcome attached, delivered in-house by a Dynamics-native team or extended through a trusted partner network with PrecisionPoint accountable throughout.

The complete capability, organised by the work you are likely to be looking for on Dynamics.

• Reporting health-check. Find out whether your Dynamics reporting can be trusted before you spend a penny on a build. A fixed-scope review of how your reporting is put together, where the numbers stop reconciling, and what it would cost to fix. The low-commitment way in, and the one that gives finance a transparent number before any budget is committed.
• The build. Design and build the governed reporting model on Dynamics 365, and the finance, operational and sales reports that sit on it. Model-first, because the model is the part that decides whether the numbers reconcile. This is where the Dataverse and Fabric connection, the semantic layer, the DAX and the data engineering under the reporting come together, with rapid-pilot and fixed-scope formats where speed matters.
• The data model and semantic layer. The part that decides whether finance can trust a figure. Semantic model design built around the Dynamics data structure, refactor and certification of a model you already have, DAX that computes the same way every time, and metric definitions agreed once and used everywhere. This is where twenty-plus years of Dynamics-native depth shows up most, and where a report stops being a picture and becomes something a CFO can defend in a board meeting.
• Multi-entity and consolidation. One group view across multiple Dynamics 365, AX or NAV instances, with intercompany and financial dimensions rolling up correctly. The reporting problem that shows up after growth or acquisition, where several instances have to reconcile into a single trusted set of numbers, and where a governed model is the only thing that makes it hold.
• Migration to the supported data path. Move reporting off the retired Export to Data Lake route onto Synapse Link for Dataverse or Link to Fabric, and put a governed model in place while you do it. The migration you have to make anyway, done as the moment to fix the foundation rather than lift-and-shift the same broken reporting onto a new pipe.
• Governance, the run-state, and Managed BI. A governance framework you build once and a run-state you keep: workspace and tenant control, row-level and object-level security so the right people see the right numbers, version control across development, test and production, and Managed BI so trusted numbers keep arriving on a retainer without depending on one internal person. It is also the governed foundation that has to come before any tenant-wide Copilot on Dynamics data. It is where reporting stops being a project and becomes part of how the business operates.

That is the breadth. Where any given engagement starts on it is the question the three-step path answers.

The honest answer is that most organisations should blend: keep ownership of the reporting that differentiates them, and bring in a specialist for the governed Dynamics data model that reconciles, because that is the scarce skill, not Power BI itself. The way to decide without guessing is a short assessment that shows you the gap, so finance and IT decide from the same neutral read before any budget is committed.

It is a fair question, and it splits into two.

First, does your team have the data-architecture skills to build the governed model safely on the Dynamics structure? Not Power BI skills, which many teams have, but Dynamics-native modelling skills, which is precisely where reporting goes wrong. Plenty of teams can build a dashboard. Far fewer can build a model on Finance & Operations or Business Central that reconciles and keeps reconciling as the business changes. This is not a local shortage. More than half of enterprise application leaders report that a lack of skilled staff is one of their top challenges, and reporting reliability is exactly the kind of work that stalls when the skill is not there.

Second, do you have the capacity to own and run it afterwards, month after month, without it becoming one person's fragile side project? If reporting is broken today with the people you already have, adding another dashboard rarely fixes the cause.

The strongest teams do not choose build or buy. They blend: buy the specialist model-building and the run-state where it is scarce, and keep the reporting that is genuinely theirs. The cleanest way to draw that line is not to guess. A short assessment shows you where your reporting actually stands, what the gap is, and whether the right next step is your team, ours, or a bit of both, before you commit any budget either way. And because this is usually a shared decision between the people who own the budget and the people who own the platform, the assessment gives finance and IT the same neutral read to decide from.

If you would rather weigh a productised route, our Reveal data connector for build-versus-buy is the packaged option to compare against a bespoke build.