Single source of truth: what it really means in a mid-market business

Single source of truth is one of the most frequently cited ambitions in mid-market data strategy and one of the most commonly misunderstood. This article explains why most projects that pursue it fail, what good actually looks like, and how to restore reporting confidence without embarking on a multi-year data transformation.

Why the phrase causes problems before the project starts

The term single source of truth implies that there is currently one source of truth and it is wrong, or that there are many sources and only one of them is right. Neither framing is usually accurate.

In most mid-market businesses, there are multiple systems, each of which holds data that is authoritative for a specific purpose. The finance system holds the authoritative view of cash and accruals. The CRM holds the authoritative view of customer activity. The operations system holds the authoritative view of delivery. The problem is not that any one of these is wrong. The problem is that when data from two or more of them is combined to answer a management question, the combination produces a figure that nobody fully trusts and that different teams calculate differently.

Calling this a single-source-of-truth problem is technically correct but practically unhelpful. It suggests that the solution is to consolidate everything into one place, which is usually expensive, slow, and not actually required to fix the reporting problem.

Why most single-source-of-truth projects fail

Projects framed as single-source-of-truth initiatives tend to fail for three predictable reasons.

Scope that grows beyond what is needed. Once a project is described as creating a single source of truth, every team with a reporting problem sees it as an opportunity to solve theirs. The scope expands to cover everything, the timescale extends, the cost increases, and the original reporting problem that triggered the initiative is still not fixed two years later.

Technology treated as the primary solution. The standard response to a single-source-of-truth requirement is to procure a data warehouse or a master data management platform. These tools can be part of the solution. They are not the whole solution, and they cannot substitute for the data ownership, process discipline, and business rules that make reporting reliable. A data warehouse fed by inconsistent, unowned data produces consistent, well-formatted nonsense.

No agreement on business rules before the build starts. The reason different teams produce different numbers is usually that they are applying different business rules, different date filters, or different definitions to the same underlying data. Until those business rules are agreed, documented, and enforced, no platform will produce a number that everyone accepts. This agreement work is unglamorous, takes longer than expected, and is frequently deferred in favour of technical build activity.

What good actually looks like

Reliable reporting in a mid-market business does not require a single unified data platform. It requires four things.

Named ownership of each data domain. Someone in the business is accountable for the quality of customer data. Someone else is accountable for the quality of financial data. Someone is accountable for operational data. These owners have the authority to set standards, resolve disputes, and escalate when data quality deteriorates. Without named ownership, data quality is everyone's problem and therefore nobody's.

Agreed business rules, written down. The definition of revenue, the point at which an order becomes a confirmed sale, the rule for allocating costs to a business unit: these are business decisions, not technical ones. They need to be made by the right people, written down in language that is not ambiguous, and used consistently by every system and every report that references them.

A defined integration layer. The place where data from different source systems is combined needs to be clearly defined, maintained, and documented. This does not need to be a complex data warehouse. For many mid-market businesses, a well-structured set of views or a modest integration layer is sufficient. What matters is that it is the agreed place where combination happens, not one of several competing versions.

A reporting process with a known cadence. Management information that is produced by a defined process, at a defined frequency, from a defined source, is more trustworthy than information produced ad hoc. The process does not need to be automated. It needs to be consistent and followed.

How to restore reporting confidence without boiling the ocean

The fastest route to reliable reporting in a mid-market business is almost never a large platform implementation. It is a focused piece of work that identifies the three to five reports that the board and leadership team use most frequently, traces the data lineage of each one, resolves the definition disputes that are causing the discrepancies, and documents the agreed process for producing them.

This work is typically measured in weeks, not years. It does not require a new platform. It requires people with the right knowledge, the authority to make decisions, and the time to do it properly.

Once the critical reports are reliable and the process for producing them is documented, the business has a foundation from which broader data investment makes sense. Trying to build that foundation through a large-scale platform project is possible, but it is a much slower and more expensive route to the same outcome.

The board conversation worth having

If your board is regularly qualifying the management accounts, asking which version of a figure is correct, or relying on finance to reconcile numbers that should reconcile themselves, the problem is solvable. It does not require a multi-year programme. It requires an honest assessment of where the definitions are unclear, who owns the data, and what process is producing the reports.

That assessment, done properly, usually takes two to three weeks and produces a prioritised action plan rather than a technology procurement recommendation.