“We need a single source of truth.”

It’s one of the most common requests in data projects. And it’s based on a misunderstanding of what’s actually achievable, and what actually matters.

The appeal is obvious. Different systems show different numbers. Reports conflict. Meetings get derailed by debates about whose data is right. A single source of truth promises to end all that: one number, one version, one answer that everyone agrees on.

But “single source of truth” is often the wrong goal. The real goal is trusted, consistent answers to business questions. That’s achievable. A literal single source for all data usually isn’t, and pursuing it can waste enormous resources chasing an impossible standard.

Why Single Source of Truth Is Complicated

The concept sounds simple until you examine it:

Different questions need different data. The “truth” about revenue depends on what you’re asking. Booked revenue? Recognized revenue? Cash received? Each is valid for different purposes. There isn’t one true revenue number; there are several, each correct for its context.

Timing creates multiple truths. What was the customer count on January 1st? The answer depends on when you asked. The number in yesterday’s report reflects data as of yesterday’s snapshot. Today’s number reflects updates that have since occurred. Both are “true” at their respective points in time.

Source systems are the actual truth. The CRM is the source of truth for customer relationships. The ERP is the source of truth for financial transactions. The warehouse system is the source of truth for inventory. Pretending a data warehouse supersedes these systems misunderstands where truth actually lives.

Aggregation obscures detail. A single aggregated view loses the nuance that different users need. Sales wants to see pipeline by rep. Finance wants to see revenue by product line. Operations wants to see orders by fulfillment status. One view can’t serve all needs without becoming so complex it serves none.

Perfect consistency is impossible. Systems update at different times. Data has latency. Transformations have edge cases. The quest for perfect consistency across all views consumes enormous effort and never quite succeeds.

What Organizations Actually Need

Instead of “single source of truth,” focus on what actually solves the problem:

Authoritative sources by domain. For each type of data, which system is the authority? Customer master data lives in the CRM. Product data lives in the PIM. Financial transactions live in the ERP. Clear authority prevents conflicting updates.

Consistent definitions. When people say “revenue,” they mean the same thing. When reports show “active customers,” they use the same definition. Definitions are documented, governed, and applied consistently. This is more valuable than a single database.

Reconciled views. Different systems will have different numbers due to timing, scope, and aggregation differences. Reconciliation explains those differences rather than pretending they don’t exist. “The CRM shows 10,500 customers; the billing system shows 10,200; the difference is these 300 accounts that are...” is more useful than forcing false consistency.

Clear lineage. For any number in any report, users can trace where it came from. What system? What transformation? What filters? Lineage creates trust even when numbers differ, because differences can be explained.

Appropriate latency. Different uses need different freshness. Real-time for operational decisions. Daily for management reporting. Monthly for financial close. Trying to make everything real-time is expensive and often unnecessary.

The Data Architecture Reality

Practical data architecture acknowledges multiple sources rather than forcing artificial unity:

Operational systems remain authoritative. The systems where data is created and managed remain the source of truth for their domains. Data flows from these systems to analytical environments, not the reverse.

Integration layer reconciles. A data warehouse or lakehouse integrates data from multiple sources, applying transformations and business rules. This layer doesn’t replace source systems; it synthesizes their data for analysis.

Semantic layer defines meaning. On top of integrated data, a semantic layer defines business metrics consistently. This is where “revenue” gets its single definition, applied to integrated data that may come from multiple sources.

Multiple consumption patterns. Different users access data in different ways: dashboards, ad-hoc queries, embedded analytics, data exports. The architecture supports multiple patterns, not a single monolithic view.

Practical Steps

Moving from “single source of truth” fantasy to useful data architecture:

Define domain ownership. For each major data domain, which system owns it? Document this. Communicate it. Enforce it. This is more important than consolidating everything into one place.

Create a business glossary. Define key terms. What is a “customer”? What is “revenue”? What is an “active user”? Get agreement on definitions. Apply them consistently in all reporting. The glossary is your actual single source of truth: for meaning, not data.

Build reconciliation into process. When numbers differ across systems or reports, explain why. Make reconciliation part of regular data operations, not a crisis response when someone notices discrepancies.

Invest in lineage. Know where every number comes from. Automated lineage tools help, but even manual documentation is valuable. When someone asks “why does this report show X?”, you should be able to answer.

Accept appropriate inconsistency. Some differences are acceptable. The real-time dashboard won’t match the monthly close. Yesterday’s export won’t match today’s query. Explain the expected differences; don’t pretend they can be eliminated.

The Right Conversation

When stakeholders ask for a “single source of truth,” translate the request:

“I’m tired of conflicting numbers” → Address definition consistency and reconciliation.

“I don’t trust the data” → Address data quality and lineage.

“I can’t find the data I need” → Address discoverability and access.

“Different reports show different things” → Address whether they should show the same thing, and if so, align definitions; if not, explain why they differ.

The underlying needs are real and valid. “Single source of truth” is just an imprecise way of expressing them. Meeting the actual needs is achievable; building a literal single source of all truth is not.