There is a conversation that happens in almost every scale-up finance transformation project, usually in the first or second week.

Someone (typically the Head of Finance or a newly appointed CFO) explains that the company needs a Single Source of Truth. They have a tool in mind. Sometimes it's a BI platform they've heard good things about. Sometimes it's a new data warehouse. Sometimes it's an FP&A software that promises to connect everything and produce clean, reliable numbers.

The tool is almost always fine.

The assumption underneath it is where things tend to go wrong.

The Misunderstanding That Derails Most SSOT Projects

A Financial Single Source of Truth is not a system.

It is not a database. It is not a dashboard. It is not a platform, a data warehouse, or a BI tool, no matter how well-configured they are.

As Onetribe Advisory frames it, a Financial SSOT is a governance outcome: the result of agreed definitions, disciplined processes, and systematic reconciliation that produce one answer to any given financial question, regardless of who asks or where they look.

The distinction matters more than it might seem.

When an organisation frames a SSOT as a technology project, it optimises for the wrong things. It selects a platform, migrates data, builds dashboards. Then, three months later, it discovers that the new tool produces three different answers to the same revenue question depending on which filter is applied, because nobody agreed on what revenue means before the build began.

The tool didn't fail. The sequence did.

What a System of Record Is, and Why It's Not the Same Thing

To understand what a SSOT requires, it helps to be precise about what it isn't.

A system of record is the native source of original data. This is the place where a transaction is first captured. Your CRM is a system of record for customer and pipeline data. Your ERP is a system of record for financial transactions. Your HRIS is a system of record for headcount and payroll.

These systems exist to capture and store data accurately. They are not designed to produce a unified financial picture. They are not designed to agree with each other. And when an organisation grows (new markets, products, entities, and tools) each system of record accumulates its own logic, its own definitions, and its own version of shared metrics.

A source of truth, by contrast, is not where data is captured. It's where data is agreed upon. It is the layer at which raw inputs from multiple systems of record are harmonised, reconciled, and given a single, auditable definition.

Most scale-ups have multiple systems of record, but no source of truth. They have the inputs, but not the agreed layer that sits above them.

The result is predictable: the revenue number in the board deck doesn't match what the CRM reports. The margin your CFO presents is calculated differently than the one your BI tool shows. Finance and Operations are both looking at "the same" data and arriving at different conclusions.

Nobody is wrong. Nobody is lying. They're just drawing from different systems of record that were never formally reconciled into a source of truth.

How Many Sources of Truth Does Your Organisation Have?

The honest answer, for most mid-market and scale-up finance functions, is more than one.

Research consistently shows that the average organisation maintains three to five competing "sources of truth" for the same financial data. A 2025 mid-market survey found that 68% of CFOs reported lacking confidence in the consistency of their financial data. This happened not because the data didn't exist, but because different parts of the organisation were working from different versions of it.

This is not a failure of technology. It is a failure of governance, and it's an almost inevitable byproduct of growth, if not addressed properly.

In the early stages, when a company is small and the finance function is one or two people, a single source of truth exists informally. One person knows where every number comes from. One spreadsheet ties everything together. The system works because the context lives in someone's head.

As the company scales (new hires, new tools, new markets, new reporting requirements) that informal coherence breaks. Each new system brings its own logic. Each new team member brings their own definitions. Each new reporting requirement pulls a slightly different cut of the same underlying data.

By the time a scale-up reaches Series B, the organisation doesn't have a data problem. It has a coherence problem. And coherence is not something a new tool can solve on its own.

The Difference Between Data That Looks Right and Data That Is Right

This is the part that makes financial data failures particularly difficult to catch.

Poor data rarely looks broken. Dashboards load on time. Reports go out every Monday. Numbers appear consistent at a surface level. Leadership makes decisions with apparent confidence.

The problem surfaces when someone asks a question the dashboard wasn't designed to answer. Or when two people pull the same report through slightly different paths and arrive at different results.

At that point, the conversation stops being about the business and starts being about the numbers. Who is right? Which system should we trust? Which version of the metric are we using for this presentation?

This is what a functioning Financial SSOT eliminates: not the absence of questions, but the time and trust cost of answering them.

A well-designed SSOT has a property that is worth naming explicitly: report lineage. Any number in any report can be traced back to its source transaction through a documented chain. Not just "this came from the ERP", but specifically which table, which transformation, which calculation rule, applied at which point, approved by whom.

This is the financial equivalent of a supply chain traceability system. You can follow any output back to its origin. And because that chain is documented and audited, a number produced for a board presentation and a number produced for an investor data room will agree because they were drawn from the same agreed foundation.

What a Financial SSOT Actually Requires

If a SSOT is a governance outcome, not a technology, then building one requires three things that technology alone cannot provide:

1. Agreed definitions

Before any data is modelled, every metric that matters to the business needs a written, agreed definition. Not "revenue", but what actually counts as revenue, when it is recognised, whether intercompany transactions are included, how currency conversion is applied, and who is authorised to change the definition if the business model evolves.

This sounds like documentation work. It is, partially. But it is also the moment at which Finance, Operations, and Product discover that they have been calculating the same number differently for months. The conversation that follows is where most SSOT projects get complicated.

2. Disciplined source ownership

Every input to the financial model needs a clearly assigned owner, being it a person or team accountable for the accuracy and completeness of that data before it enters the shared layer. Not IT, whose job is to store and move data, but the business function that understands what the data represents.

When ownership is unclear, data governance defaults to whoever happens to have access. And when something breaks, like a source changes, a calculation drifts, a metric stops making sense, there is no clear path to accountability or resolution.

The same structural gap applies when AI enters the workflow. If nobody is explicitly assigned to question what an automated system produces, the default is nobody. We explored that dynamic in detail in this article on AI governance in FP&A.

3. Systematic reconciliation

Even with agreed definitions and clear ownership, financial data requires ongoing reconciliation: a structured process for catching discrepancies before they reach decision-makers. Not a one-time audit at project launch, but a repeating cadence that treats data quality as an operational responsibility, not a remediation exercise.

This is the layer that most organisations skip when they are moving fast. It is also the layer that, once absent, produces the slow erosion of trust that we explored in our first article: not a dramatic failure, but a quiet accumulation of doubt that eventually makes leadership reluctant to rely on the numbers they are being shown.

Gartner estimates that poor data quality costs the average enterprise between $12.9 million and $15 million annually — a figure that reflects not just remediation effort, but the compounding cost of decisions made on data that was never properly governed.

The Practical Starting Point

If you are a finance leader at a scale-up reading this and wondering where to begin, the answer is not a tool evaluation.

The answer is five numbers.

Identify the five to ten metrics that actually drive board and investor decisions in your organisation. For each one, answer the following:

In most scale-ups, this exercise surfaces more fragmentation than expected. Metrics that appeared simple turn out to have multiple calculation paths. Sources that appeared stable turn out to be owned by nobody. Definitions that appeared shared turn out to vary by team or by report.

That fragmentation is not a failure. It is information. It tells you precisely where the governance work needs to happen, before any technology decision is made.

A SSOT project that begins here — with definitions, ownership, and reconciliation — has a fundamentally different success profile than one that begins with a platform selection. The technology question becomes much simpler once you know what you need the technology to support.

What Comes Next

In the next article in this series, we look at a specific pattern that compounds this problem during hypergrowth: KPI drift. The metrics that guided your company through Seed no longer describe the reality of your post-Series A business. Worse than that, in most cases, nobody has noticed yet.

If you'd like to understand how this plays out in practice, and what the signals look like before it becomes a reporting problem, the next article is here.