The meeting starts. Someone pulls up the revenue number from the CRM. Someone else shares a different figure from the accounting system. A third person has a spreadsheet that shows something different again. Twenty minutes later, the meeting is still going — not discussing what to do about revenue, but arguing about which number is right.
This is the single source of truth problem. It's not a technology problem. It's not a data volume problem. It's a definitions, ownership, and process problem — and it's solvable without an enterprise data platform.
Here's what a single source of truth actually is, why businesses struggle to build one, and the practical steps to get there.
What "Single Source of Truth" Actually Means
A single source of truth (SSOT) means that for any given metric or data point, there is one agreed system that holds the authoritative version — and everyone knows which system that is.
It doesn't mean all your data lives in one place. It doesn't mean you only have one system or one tool. It means that when you want to know what revenue was last month, there's one place you go — and that place is the same for every person in the business who needs that number.
The SSOT for financial data is usually the accounting system (Xero, QuickBooks). The SSOT for customer data is usually the CRM. The SSOT for operational metrics might be a custom dashboard fed from multiple systems. What makes it a single source of truth isn't the location — it's the agreement that this is the authoritative version and everyone is working from it.
Why Businesses End Up With Multiple Versions
The multiple-versions-of-truth problem has a consistent origin story:
Different systems measure the same thing differently. The CRM counts a deal as won when the contract is signed. The accounting system counts revenue when the invoice is raised. Finance counts it when cash arrives. All three are measuring "revenue" — but at different points in the same process. The numbers will never match unless the business has explicitly agreed which definition to use and which system to report from.
People build workarounds. When the reporting system doesn't answer the question fast enough, someone builds a spreadsheet. That spreadsheet gets shared. Other people update it slightly differently. Over time, there are three versions of the spreadsheet in circulation and nobody is sure which is current.
Definitions were never written down. What counts as a customer? Is it anyone who's ever paid, or only active customers, or only customers above a revenue threshold? What's in gross margin — does it include fulfilment costs or not? These definitions live in people's heads, and different people have slightly different versions. A data dictionary that writes these definitions down is often the single most impactful thing a growing business can create.
Most businesses don't have a data problem. They have an agreement problem. The data exists — it's just interpreted differently by different people in different systems.
The Four Components of a Working SSOT
A single source of truth isn't a tool you buy. It's a combination of four things:
1. Agreed definitions. For every metric the business reports, there's a written definition: what it measures, how it's calculated, what's included and excluded, and which system holds it. This is the data dictionary. It doesn't need to be long — a one-line definition per metric is enough. What matters is that it exists, is written down, and is agreed.
2. Named authoritative systems. For each category of data — financial, customer, operational — there's a named system that is the authoritative source. Financial data: the accounting system. Customer data: the CRM. Operational metrics: defined in the dashboard or reporting tool. When two systems disagree, there's a rule for which one wins — not a debate.
3. A data flow map. How does data move from source systems into the reporting layer? Which integrations are live and which are manual? Where are the manual steps — and who owns them? A simple diagram of data flows reveals the points where errors and divergence are most likely to occur.
4. A review process. Definitions and systems drift over time. The SSOT needs a periodic review — quarterly is usually sufficient — to check that the definitions are still accurate, the systems haven't changed in ways that affect the numbers, and no new workarounds have been quietly introduced that bypass the agreed sources.
How to Build It Without an Enterprise Data Team
Most guides to building a single source of truth are written for businesses with data engineers and a multi-year roadmap. For an SME, the practical approach is simpler:
Step 1: List your 10–15 most reported metrics. Revenue, gross margin, cash position, active customers, pipeline value, debtor days — whatever the business reports most often. Start there, not with all the data the business produces.
Step 2: For each metric, identify where it currently comes from. Ask the people who use each number: where does your version of this come from? You'll probably find 2–3 different answers for each metric. That's the problem you're solving.
Step 3: For each metric, choose the authoritative system and write the definition. This is a conversation — finance, sales, and operations may disagree. That disagreement is healthy and needs to happen. The output is one line per metric in a shared document: what it means, how it's calculated, and which system is the source. That document is your data dictionary.
Step 4: Update your reporting to use only authoritative sources. Dashboards, management accounts, board packs — all should pull from the agreed system. Retire the spreadsheets that were workarounds. This is the step that causes the most friction, because people are attached to their versions. Name the process explicitly: "we're standardising our reporting to use one authoritative source per metric."
Step 5: Treat divergence as a process failure, not a data failure. When two numbers disagree in a meeting, the right question isn't "which is right?" but "which system is authoritative for this metric, and why is the other one different?" That question identifies process gaps — an integration that hasn't updated, a definition that's drifted, a workaround that's crept back in.
What a SSOT Is Not
Building a single source of truth doesn't require:
- A data warehouse
- A data lake
- An enterprise BI platform
- A data engineering team
- More than two weeks to implement at SME scale
These tools all support a SSOT at scale. But the foundation — agreed definitions, named authoritative systems, a data flow map, a review process — is a governance problem, not a technology problem. It's achievable with a shared document, a clear conversation, and the discipline to retire the workarounds once the authoritative sources are agreed.
The businesses that struggle most with data reliability are usually not the ones without sophisticated tooling. They're the ones where the definitions conversation was never had — where "revenue" means four different things to four different people and nobody has ever written down which one is right.