Most spend dashboards quietly answer one of two different questions. Which one they answer is decided by the engineer who built the dashboard — not the CFO who reads it, not the head of procurement who's accountable for the number.
That's the governance gap nobody names. Once you can see it, you stop blaming your data team for the symptoms and start asking the question that should have been asked before any code got written.
The two questions a spend dashboard answers
A single procurement dataset can be aggregated in two materially different ways:
| Supplier-level view | PO-level view | |
|---|---|---|
| Granularity | One row per vendor | One row per transaction |
| Band assignment | By total annual spend across all transactions | By the value of that single PO |
| Asks | Where is our leverage? | Where are our process controls weak? |
| Owner of the answer | CFO / strategic sourcing | Head of procurement / operations |
Both are mathematically correct. They answer different questions. Most companies don't realize they have to pick one — or that picking both, with the framing made explicit, is often the more sophisticated move.
The engineer ends up picking by default, usually whichever was easier to express in the tool open on their screen that morning, and the framing is silent for the next three years.
Why this matters at board level
A supplier-level view tells the CFO which vendors deserve a strategic relationship: where the leverage is, where consolidation might make sense, where the concentration risk sits if a critical supplier walked away tomorrow.
A PO-level view tells the head of procurement something different — which transactions deserve a process control: where approval thresholds are weak, where maverick buying is leaking through, where the workflow needs hardening before the auditors notice.
The same supplier shows up in different bands across the two views. The same dataset leads to different decisions. Both decisions can be right at the same time. The dashboard, asked to answer one question, cannot tell you which one it picked.
Who pays the cost
When the choice is implicit — when an engineer picked one because it was simpler in DAX or SQL or the BI tool's drag-and-drop builder — the cost shows up as trust drift.
The CFO and the head of procurement reach different conclusions in the same meeting, citing the same dashboard. Each side caveats the other's number. Each side eventually stops trusting the dashboard. The data team gets blamed for bad data that's actually a governance gap nobody named — and the team's response (building a second dashboard to reconcile) usually makes the trust problem worse rather than better.
We've seen this pattern enough times to call it a category. It's almost always a definitions problem dressed up as a tooling problem — and treating it as a tooling problem is the most expensive thing you can do.
What good looks like
Both views, side by side, with explicit labels: strategic-supplier band, transactional band. The dashboard makes its assumptions visible at the top of the page, not buried in a tooltip nobody opens.
Stakeholders see which question is being answered before they read the answer — which means the conversation in the meeting starts at the second-order question ("what should we do about it?") rather than the first-order one ("whose number is right?").
The reconciliation happens in the model — once, properly, and documented — instead of in the meeting, every quarter, forever.
This isn't a sophisticated technical move. It's a small naming move that takes a problem out of the tooling layer and puts it back in the governance layer where it belongs. The technical work is straightforward once the framing is decided.
The work
Building this isn't hard. Naming it isn't hard either.
The hard part is treating which question to answer as a governance decision the CFO actually owns, rather than a technical one the engineer has to make alone, on a Wednesday afternoon, with the tool open and a deadline tomorrow.
That's where most teams fall down — not on the implementation, but on the conversation that should have happened before the implementation. The engineer is rarely the right person to make a definitional call about how the business should be measured. They build what they're asked to build. If they're asked to build a spend dashboard, they will pick a level of aggregation, ship it, and move on. The question that wasn't asked stays unasked.
Where to start
If the reports in your company keep disagreeing — if the CFO's number for top-supplier spend doesn't match the head of procurement's number for the same month, if every quarterly review starts with reconciliation rather than analysis — that's the signal.
It's not that you need a better dashboard, or a different BI tool, or a more expensive consultant. It's that you need to decide, explicitly, which question your spend dashboard is for.
- Sometimes the right answer is one.
- Sometimes the right answer is both, side by side, with each labeled clearly.
- What's not a viable answer is leaving the choice implicit and paying for it in trust drift forever.
The decision is ten minutes of conversation. The cost of not having that conversation compounds quietly for years.
Spend visibility isn't a Power BI problem. It isn't a Snowflake problem or a dbt problem either. It's a definitions problem, and the fix is governance, not tooling.
It starts with naming the question — and once the question is named out loud, the rest is honest work that any competent data team can finish in a scoped window. The naming is the hard part. The naming is the part that doesn't happen unless someone senior insists on it.