Executive Summary
Finance Directors often ask how to benchmark their data spend as a percentage of revenue. It seems a sensible question, but in my experience, it can lead to wasted effort.
This approach doesn't account for the state of your data architecture. Money often goes to visible things like dashboards, while the underlying data becomes less reliable, making important decisions riskier.
A better way is to budget for improving your data's reliability. This usually means investing in stages: first, creating a single source of truth; second, adding some light governance; and third, training people to find their own answers. The focus shifts from cost to the value of making sound decisions.
Why benchmarking data spend against revenue doesn't work
When a Finance Director asks me, "What percentage of revenue should we budget for data?", it's a natural question, but my experience suggests it's not the most helpful one. It's an attempt to find a simple rule for a complicated problem, which can be a bit of a trap.
I see this quite often in scale-ups. They’ve invested in the modern data stack: Snowflake, dbt, Looker or Power BI. They have a team of smart, expensive engineers. The risk is that they've just moved an existing mess to a faster system. If the underlying process is flawed, you're just producing unreliable data more quickly. Your budget ends up funding activity, rather than useful outcomes.
Comparing your spend to another company is rarely helpful. Is their business based on high-volume transactions, or are they a low-volume B2B software company? Do they have a clean, organised set of data or a tangle of thousands of reports that nobody trusts? The simple benchmark people hope for just doesn't seem to exist.
The real cost is in slow, low-confidence decisions
The issue usually isn't the business intelligence tool, and it's rarely the people. It's that the budget is often spent on the symptoms of a shaky data architecture, not on fixing the foundations.
When an analyst spends a day trying to make two spreadsheets agree just to answer a simple question, that's a hidden cost of architectural debt. When the board meeting gets sidetracked by a twenty-minute debate over the definition of an "Active User," that's another part of the cost. The true cost isn't just the data team's salaries. It's in the slow, hesitant decisions made every day because people don't quite trust the numbers.
I've seen companies hire several analysts to solve what is, at its heart, a data architecture problem. This is a bit like hiring more people to carry buckets of water from a leaking pipe instead of just fixing the pipe. A good CFO Data Strategy isn't about the cost of the buckets; it's about fixing the plumbing.
A different approach: budgeting for architectural maturity
Instead of a broad percentage, it's more effective to think of the data budget as a series of specific investments to make your data architecture more mature. It's less of an operational cost to be squeezed, and more of an investment in a valuable asset: trustworthy information.
This is an approach I've found works well:
#### Phase 1: Consolidate reports and create a single source of truth The first investment, perhaps counter-intuitively, should be in having fewer dashboards, not more. Budget for a thorough audit and consolidation project. I worked with a growing e-commerce company where we did this, reducing their collection of dashboards from over 200 down to about 30 core reports. The result wasn't just a saving in engineering time. It was creating a Single Source of Truth that put an end to the weekly arguments about whose numbers were correct. This is a defined project with a clear return: people can make decisions faster.
#### Phase 2: Introduce light governance to de-risk decisions The next step is to budget for some light governance. This doesn't mean creating a mountain of documents that no one reads. It's about agreeing on business logic, recording it in a Semantic Layer, and setting up automated checks. It can be helpful to think of Data Governance as a form of insurance. You pay a small, predictable premium to protect the business from the significant risk of making a poor strategic decision based on a faulty number in your Financial Reporting.
#### Phase 3: Train people to reduce reliance on the central team Finally, it's worth setting aside funds for specific training in different departments. The aim is to develop local experts and a culture where people can find their own answers. This directly reduces one of the most inefficient parts of many data operations: the long queue of ad-hoc requests on Slack. A good Data Team Strategy should aim for the central team to become smaller and more focused over time, not bigger.
This is a change in how people work, not just a budget shift
It's worth saying, this approach takes more work than just signing off on a new tool. It might mean telling a department head that a dashboard they like is being retired. It means getting Operations and Finance in a room to agree on a single, written-down definition of churn. It often feels more like a negotiation between departments than a technical data project.
You might have to accept moving a bit slower for one quarter to be able to move much faster for the next few years. The budget isn't just for technology. It's for the focused time needed to sort out your own operational complexities.
The reward for this work is a change in the conversations people have. The board can stop questioning the data and start debating the strategy. The finance team can stop spending weeks reconciling numbers and start focusing on forecasting. That's the real return, and it's something a simple percentage-of-revenue benchmark will always miss.