A number on the executive dashboard looks wrong, and the meeting stops. Margin is off, or a region is double what anyone expects, and the first sentence out of the room is always the same: the dashboard is wrong. Someone is dispatched to fix the report. It is the natural reflex, and it is usually aimed at the wrong layer.
A report is the last mile, not the source of truth. Most of the time the dashboard is doing its job perfectly — faithfully showing what the data underneath it actually says. The number is wrong because something upstream is wrong, and the report is only the messenger. Shooting the messenger feels like progress and fixes nothing.
Trace it, don't paint over it
Follow a wrong number back and it almost never ends at the visualization. It ends at a decision made upstream. A GL account mapped to the wrong node in the reporting hierarchy, so its balance rolls up under the wrong line. A cost center pointed at the wrong parent, quietly inflating one region and starving another. A sign convention flipped, so a contra account adds where it should subtract. A filter that silently drops a class of transactions nobody remembered to include. Each of these is a mapping or a posting decision, and each produces a number that is wrong in a perfectly consistent, perfectly explainable way — once you look in the right place.
The patch that becomes the problem
The tempting fix, under deadline, is to correct it where you found it: in the reporting layer. Add a calculated column that subtracts the overstatement. Hard-code the region split. Filter out the rows that look off. The dashboard now shows the right number, the meeting moves on, and a second source of truth has just been born. The report no longer agrees with the general ledger, and from here the two drift independently. Next quarter the underlying mapping changes, the patch silently double-corrects, and the number is wrong again — but wrong in a way nobody can trace, because the logic now lives in a visualization nobody audits.
- Reconcile the report to the trial balance first. If it ties to the GL, the report is right and your expectation is what to check. If it doesn't, you've found the layer to fix.
- Look for the mapping, not the formula. Wrong rollups, wrong hierarchies, flipped signs, dropped filters. The defect is almost always structural, not arithmetic.
- Refuse the visualization-layer patch. A correction the GL doesn't know about is a second ledger you'll be reconciling forever.
Fix it where it broke
The discipline is to push the fix back to the layer that caused it — the mapping, the hierarchy, the posting rule. It is slower in the moment, and it is the only version that holds. Correct the mapping once, at the source, and every report that draws on it inherits the fix for free, automatically, with no second copy of the logic to maintain and no divergence to police. One source of truth stays one source of truth.
That is the quiet payoff of doing it the hard way. A dashboard you can fully trust is one you never corrected — you corrected the ledger underneath it, and let the report go on telling the truth.