Executive Summary
The late-night scramble before a board meeting
It’s ten o’clock the night before the board meeting. As the CFO, you’re looking at two spreadsheets. One is from your business intelligence tool, showing customer revenue. The other is from your accounting system, showing the P&L. The totals don't match. Again.
That familiar sinking feeling arrives. Your team begins a manual reconciliation, a rather stressful process that takes up hours that nobody has. You go into the boardroom the next day with a number you can't quite stand behind. The board’s questions are polite, but the point is made: they don't fully trust the data.
This sort of thing isn't just a nuisance. For a growing fintech company, it can be a real problem. Inconsistent financial reporting can affect investor confidence and create complications during due diligence.
Why a modern data stack doesn't always solve the issue
In my experience, the problem isn't usually the team. It's often the way the systems have been put together over time. It's common to invest in a "Modern Data Stack" like Snowflake, dbt, and Looker or Power BI, and hire very capable engineers, only to find you're producing the same inconsistent numbers, just more quickly. If the underlying process is flawed, automating it just means you get the wrong answer faster.
This is a pattern I've seen in quite a few fintech companies I've worked with, typically around Series B to D. In the rush to grow, it's easy to accumulate what you might call 'growth debt'. Early shortcuts, inconsistent definitions for metrics, and a lack of proper data governance mean the foundations have become a bit unstable.
The problem is usually in the business logic, not the tools
The problem is rarely the BI tool itself. What's usually happening is that the logic defining 'revenue' exists in several different places at once. Marketing might have one definition in their SQL, Sales has another in their CRM, and Finance has the correct one in the ledger. This means there's no single source of truth, just several competing versions.
Your data team, who are often very skilled, end up spending their time trying to make the numbers match up, rather than finding useful insights in them.
How early shortcuts can cause problems during an audit
In the early days, moving fast is completely sensible. But later on, those ad-hoc data models, built without much governance, can become a problem. Every time a number is questioned, it requires a lot of effort to trace it back because there's no clear, auditable trail from the original transaction to the final figure in the board pack. This lack of a governed semantic layer is what can cause anxiety around audits and make due diligence more difficult than it needs to be.
The solution: rebuilding the data foundation
Hiring another analyst is unlikely to solve what is, at its heart, an architectural problem. The foundation itself needs to be fixed. This means treating your data with the same care and attention you give to your customer-facing technology.
The approach I take is quite direct. We don't build more dashboards; we usually end up with fewer. We don't just write new queries; we put a proper system of governance in place.
Step 1: Creating a single source of truth
The first step is to get the immediate problem under control. I work with the finance, data, and commercial teams to agree on and write down a single, clear definition for each core financial metric. We trace the entire data lineage, from the payment processor API call to the final P&L entry. This work results in a single, consolidated data model that serves as the reliable source of truth for all revenue reporting.
Step 2: Putting a semantic layer in place
Once the logic is agreed, the next step is to put a semantic layer in place. This is a layer of business-friendly definitions that sits between your data warehouse and your reporting tools. It ensures that whether someone is using Tableau, Power BI, or a spreadsheet, they are all working from the exact same, pre-approved calculations. This helps to eliminate discrepancies and makes reporting consistent and auditable by design.
The result: reliable figures and a more confident board
Imagine the next board meeting. A question comes up about a revenue figure. Instead of having to take it away as an action, you can show, with a few clicks, the exact logic, the source data, and the full audit trail. The conversation can then move on from questioning the data to making decisions based on it.
This is the difference between spending time fixing data and using it to help the business. By rebuilding the data engine, you can remove the need for manual reconciliation, make audits more straightforward, and restore trust in the numbers that matter most. Your data starts to feel more like something that helps the business grow, rather than a problem that holds it back.