Data Trust: Your dbt Models Are Perfect. Why Doesn't Finance Care?

Executive Summary

---

The problem: Finance prefers spreadsheets to your data stack

It’s the Monday morning management meeting. Your Head of Data presents a dashboard showing customer growth is up 12%. Then, you present your forecast, built in Excel, which shows it at 9%. A quiet moment follows. The CEO looks between the two of you and asks the question that brings the conversation to a halt: "So, which number is right?"

This sort of thing happens quite a lot. I’ve seen it in many Series B and C companies. You’ve likely spent a good deal on the modern data stack. You have Snowflake, Fivetran, and a capable team writing clean dbt models. And yet, when it comes to the most important numbers, the ones that go into the board pack, your finance team quietly clicks 'Export to CSV'.

That export is a clear sign of a lack of confidence in your data setup. Every time someone goes back to a spreadsheet, it suggests your expensive, powerful data stack hasn't quite met the needs of one of its most important users. This isn't usually a training issue. It's more often a problem of trust.

The root cause: Scattered business logic

In my experience, you can move to the cloud and hire very smart engineers, but still end up recreating the same problems, just more quickly. If a process is flawed, automating it just means you get unreliable data, but much faster. The problem isn't that your warehouse is slow; it's that the definition of 'revenue' hasn't yet been agreed between departments.

Your data engineers can build perfectly tested, well-documented dbt models, but they may be building on unstable foundations. The core issue is that business logic is spread out. Some of it is in a dbt model, some is in the BI tool's calculations, and the really important details are often tucked away in a VLOOKUP formula on your Finance Director's laptop. This is why a solid CFO Data Strategy is so important, one that puts data integrity first.

This isn't the fault of your engineers. It’s a problem with the overall structure. There is no clear link between the raw data and the final, board-ready number. Without that link, relying on Excel isn't a bad habit, it's a perfectly sensible choice for them to make.

The solution: Centralising your business rules

The answer isn't usually to hire more engineers or buy another visualisation tool. The way forward is to bring some order to this by building a governed layer that sits between the data warehouse and the people using it. This is the less glamorous, but necessary, work of building real Data Trust.

This involves three main shifts:

Centralise your logic: The first step is to establish a Semantic Layer. You can think of this as the one place for all your business metrics. The definition of 'Active User' or 'Net Revenue' should be defined once, in code, and be visible to everyone. The definition becomes an agreed standard, not a point of debate. When Finance and Marketing can see the same definition, they start trusting the same number.

Treat reporting as a product: My background is in Product Management, and I've learned that if a dashboard isn't trusted, it's not a useful product. It's important to focus on that 'last mile'. This means sitting with the finance team to understand their month-end process. The goal isn't just to build a dashboard, but to build a system that means they no longer need their manual reconciliation process.

Implement light governance: This doesn't mean writing a huge document that no one will read. It's about having simple checks and balances in the code itself. We make sure that when a metric definition is changed, a clear process is followed. This is how you create a Single Source of Truth that holds up if it's looked at closely during an audit or a due diligence process.

The human side of the problem: Getting people to agree

To be honest, making this change can be difficult. It means getting your Head of Sales, Head of Product, and CFO in a room to agree on a single, universal churn definition. This is more about getting people to agree than it is about writing code.

You're asking people to give up the familiar spreadsheets they're used to. You're asking teams to have conversations about the metrics that define their success, which can be uncomfortable. It's natural to expect some resistance. The idea is to accept a slower pace for one quarter, in order to move much faster for the years that follow.

The result is fewer debates on a Monday morning about whose number is right. It leads to a faster, cleaner month-end close. It's a board pack you can feel confident in. It's the point where your CFO stops asking for a CSV export and starts using the platform you've invested in.