Why your reports disagree,
and why the dashboard can’t fix it.

Three reports, three margins, one plant, one month. The instinct is to find the “right” report and trust it. That instinct is wrong. When numbers disagree, none of the reports is broken — they are each faithfully computing a different definition. The disagreement lives below the dashboard, in the model layer, and that is the only place it can be fixed.

Five ways the same number splits

Divergence is not random. In a manufacturing ERP it comes from a small, recurring set of causes — each one ordinary on its own, each one enough to make two honest reports disagree.

Cause	What actually happens
Margin defined three ways	Standard cost, last-actual cost, and blended cost each yield a defensible margin. Pick a different cost basis and you get a different answer — both correct, neither reconciled.
Delivery measured on three dates	On-time can key off promise date, ship date, or invoice date. One report counts the day it left the dock; another counts the day it was billed. The gap is real orders, not rounding.
Costing rules changed in the ERP	A rollup, an overhead rate, or a labor burden was updated in the system. The report was built before the change and never heard about it.
Measures copied across spreadsheets	A useful calculation gets copied into the next analyst’s file, then the next. Each copy drifts a little. A year later there are six versions and no master.
Refresh path owned by a departed vendor	The model that feeds the report was built and scheduled by someone who left. It runs until the day it doesn’t, and nobody inside the building has the keys.

Why the dashboard is the wrong layer to fix it

A dashboard renders a number; it does not define one. Recolor the chart, add a filter, rebuild it in a newer tool — the margin still resolves through whatever cost basis and date logic sit underneath. Fixing divergence at the dashboard means hard-coding one report’s assumptions and hoping the others match. They won’t, because they were never told to.

The disagreement is structural, so the fix has to be structural. The number has to be defined once, in one governed place, and every report has to read that definition instead of carrying its own. That place is the semantic model — the layer between the ERP’s raw transactions and the reports that quote them.

What “define it once” means in practice

• Margin has one cost basis, chosen deliberately and written down — not defaulted per report.
• On-time delivery keys off one date, and every view that says “on-time” means the same thing.
• When a costing rule changes in the ERP, it changes in one model, and every report moves with it.
• Each measure has a single definition and a named owner — no copies, no drift.
• The refresh runs on a path your team controls and can read, not a black box someone else scheduled.

The test is simple: the controller, the COO, and the plant should be able to disagree about what the number means for the decision — and never about which report is correct. That is the whole point of the model layer. The signature demonstration is three sources showing three margins for the same plant and month, resolved to a single number that all three roles read without argument.

This is also an ownership problem

Notice that the last cause — a refresh path owned by a departed vendor — isn’t a definition problem at all. It is an access problem. You cannot define a number once if you cannot reach the data or change the model that produces it. Reconciliation and ownership are the same work seen from two angles, which is why the argument continues in Access is the precondition and, for the board, in the exit math — the same divergent numbers that confuse your Monday meeting are the ones a buyer’s analyst will find in diligence.

Start where the pain is loudest: the numbers that do not agree. Reconciling them is the first thing the audit does, and the graded report tells you which of the five causes is at work in your shop.