Source of Truth: How to Eliminate Conflicting Data Across Teams

Every organization reaches a point where different teams report different numbers for the same metric. Sales says revenue is $4.2M. Finance says $3.8M. The data warehouse says $4.0M. Nobody is lying. They are all correct, just using different definitions, timeframes, or data sources.

A source of truth eliminates this confusion by establishing one authoritative answer for each business question.

Why Teams End Up with Different Numbers

The root causes of conflicting data are predictable:

1. Definition Differences

"Active users" means something different to every team:

• Product: logged in at least once in 30 days
• Marketing: visited the website in 30 days (includes non-logged-in)
• Finance: paying subscription that has not churned
• Support: contacted us in 90 days

Same label, four different numbers. All valid for their context.

2. Timing Differences

Revenue reported at different points:

• Sales: books revenue when deal closes
• Finance: recognizes revenue when service is delivered
• Data team: reports when payment is received

A deal closed on March 30, delivered in April, paid in May shows up in three different months depending on who you ask.

3. Source System Differences

The same data modified in different systems diverges over time:

• CRM contact edited by sales rep
• Marketing database updated by email bounces
• Product database updated by user profile changes
• Support system updated by agents

Without synchronization, these copies drift apart.

4. Scope Differences

What counts as a "customer" varies:

• Do free trial users count?
• Do partner-referred accounts count?
• Do internal test accounts count?
• Do accounts that signed but have not yet onboarded count?

The Practical Framework for Establishing a Source of Truth

Step 1: List Your Contested Metrics

Start with the metrics that cause the most confusion. Common offenders:

• Revenue (always multiple versions)
• Customer count (definition varies)
• Churn rate (denominator debates)
• Conversion rate (which funnel?)
• Pipeline value (weighted vs. unweighted)
• Headcount (FTE vs. contractors vs. vacant positions)

Step 2: Bring Stakeholders Together

For each contested metric, get the key consumers in a room (or document):

• Who uses this metric?
• What decisions does it inform?
• What definition do they currently use?
• Why do they prefer their version?

Often the "wrong" definition is correct for that team's use case. The solution is not one definition. It is clearly labeled definitions with an agreed canonical version.

Step 3: Establish Canonical Definitions

For each metric, document:

Revenue Example:

Step 4: Build the Technical Infrastructure

Once definitions are agreed, implement them:

For analytical queries:

• Define metrics in your data warehouse's transformation layer (dbt models, LookML, or equivalent)
• All dashboards and reports pull from these defined metrics
• Direct database queries are discouraged for reporting

For operational use:

• Designate which system each metric lives in
• Build synchronization pipelines to keep copies aligned
• Flag non-authoritative copies clearly ("Marketing Customer Count, for reference only, see Finance for canonical")

Step 5: Communicate and Enforce

The most technically perfect SSOT fails without adoption:

• Add definitions to every dashboard and report
• When someone quotes a number, they must cite the source
• When numbers conflict in a meeting, resolve it immediately (do not defer)
• Onboard new employees with a "where to find data" guide
• Review definitions quarterly (business changes)

Patterns That Work

The Metric Dictionary

A living document (wiki page, Notion database, or purpose-built tool) that lists every important metric with:

• Name and aliases
• Exact definition (including edge cases)
• Source system
• Owner
• How to access (dashboard link, query, or API)
• Update frequency
• Known limitations

The Certified Dashboard

Mark specific dashboards as "certified" (the official version). Other dashboards exist for exploration but are clearly labeled as unofficial. When numbers disagree, the certified version wins.

The Semantic Layer

A technical layer that translates metric definitions into queries automatically. Users select "Revenue" and the system generates the correct SQL regardless of which tool they use. dbt Metrics, Looker's LookML, and Cube are common implementations.

The AI Analytics Approach

Platforms like Skopx solve this problem at the interface level. Instead of building multiple dashboards that might use different definitions, teams ask questions in natural language. The platform is configured with canonical metric definitions and always returns the authoritative answer, regardless of who asks or how they phrase the question.

Patterns That Fail

"Just put everything in one database"

Consolidating data does not resolve definition conflicts. You still need to decide which definition of "customer" is canonical.

"The data team will handle it"

Without executive sponsorship and cross-functional agreement, the data team has no authority to declare one team's number wrong.

"We will document everything later"

Documentation that happens after the fact is never complete. Define before you build.

"Our BI tool solves this"

Tools do not solve organizational problems. They enable solutions that have already been agreed upon.

Measuring Progress

Track these indicators to know if your source of truth effort is working:

Leading indicators:

• Number of metrics with documented definitions (vs. total metrics used)
• Percentage of dashboards pulling from certified models
• New metric requests going through the definition process

Lagging indicators:

• Fewer "whose number is right?" debates in meetings
• Faster time to answer business questions
• Higher scores on internal data trust surveys
• Less time spent reconciling reports

The Role of Data Culture

Technical solutions enable a source of truth. Culture sustains it.

Healthy data culture looks like:

• People cite their data source when sharing numbers
• Teams ask "is this the canonical definition?" before using a metric
• Disagreements about data are resolved with investigation, not authority
• New metrics go through a definition process before being tracked

Unhealthy data culture looks like:

• Executives pick whichever number supports their narrative
• Teams hoard data as competitive advantage over other departments
• "My spreadsheet" is accepted as a valid source for decisions
• Nobody questions numbers that seem suspicious

Getting Started This Week

If this feels overwhelming, start small:

1. Pick your top 3 most contested metrics
2. Schedule a 30-minute meeting with the stakeholders of each
3. Agree on one canonical definition per metric
4. Write it down somewhere everyone can find it
5. Update one dashboard to use the canonical definition
6. Repeat for the next 3 metrics

You do not need a multi-month project to start. You need one agreement, documented clearly, and consistently enforced. Build from there.