A management meeting where two departments present different figures for the same month is rarely a data problem. The data is usually fine. What differs is what each of them counted.
This is why buying a reporting tool so often fails to fix reporting. The tool will happily render both numbers.
The definitions that cause the arguments
They are always the same handful, and they are always resolvable in a meeting nobody schedules.
Does revenue include sales tax? Is a sale recognised at dispatch or at delivery? Does a return reduce the month it was sold in or the month it came back? Is headcount at month end or average across the month? Does cost per unit include overhead, and which overhead?
None of these has a universally right answer. Each has a right answer for your business, and the value is in writing it down once rather than in the choice itself.
Define once, render anywhere
The pattern that works is a defined measure layer sitting between the source systems and whatever renders the chart. Revenue is computed in one place, to one definition, and every dashboard and report reads it from there.
The alternative — each report computing its own version — guarantees divergence. Not immediately, but as soon as somebody copies a report and adjusts it slightly for a new purpose, which happens within weeks.
Drill-through is what makes people trust it
A headline figure nobody can decompose does not get believed, and rightly so. The first time it looks wrong, someone will rebuild it in a spreadsheet, and from then on there are two versions again.
Being able to click from the number to the documents behind it ends that cycle. It also makes the dashboard useful for investigation rather than only for reporting, which is what gets it opened on a Tuesday rather than once a month.
Scheduled delivery beats a portal
Dashboards that require someone to log in get looked at by the people who were already paying attention. A pack that arrives by email on a schedule reaches the people who were not, which is the point.
Build for both: a pack that lands on a cadence, with a link through to the live view for anyone who wants to dig.
Where this fails
Two failure modes account for most abandoned BI projects.
The first is modelling before agreeing — building against definitions nobody has signed off, so the first review turns into a definitions meeting and the work gets redone.
The second is treating data quality as a reporting problem. If the source is wrong, the dashboard faithfully renders wrong, and the dashboard gets blamed. Flagging gaps and anomalies visibly, rather than averaging them away, keeps the conversation pointed at the source where it belongs.
Common questions
Why do our departments report different numbers?
Almost always because they are counting different things — revenue with or without tax, sales recognised at dispatch or delivery, returns against the original month or the current one. The fix is agreeing definitions, not changing tools.
Do we need a data warehouse for this?
Not necessarily, but you do need a defined measure layer between the sources and the charts. Without one, each report computes its own version and they diverge as soon as somebody copies and adjusts a report.
Why do BI projects get abandoned?
Usually because modelling started before definitions were agreed, so the first review becomes a definitions meeting; or because source data quality was treated as a reporting problem and the dashboard got blamed for rendering it accurately.