Building a single source of truth: a practical playbook

Most companies reach the same meeting eventually. Finance says revenue last quarter was $4.2M. Sales says $4.5M. The founder's spreadsheet says $3.9M. Nobody is lying; each number is calculated from a different system with a different rule, and nobody wrote the rules down.

A single source of truth (SSOT) fixes that. It is not one giant database. It is an agreement about where the official version of each metric lives, how it is calculated and who is responsible for it, backed by tools that make the official number the easiest one to find.

This playbook is for a company of roughly 15 to 200 people without a data team. The work is mostly conversation and documentation; the tooling is the smaller part.

What "single source of truth" means in practice

An SSOT has three properties:

• One definition per metric, written down and easy to find.
• A known winner when numbers conflict: everyone knows which system is authoritative and why.
• Fresh enough for the decisions it supports. A weekly review needs data from this week, not last month.

Phase 1: find out what you have

Step 1: list the metrics people actually report

Start a spreadsheet. For every number that appears in a regular meeting, board pack or team update, record:

• the name, plus any aliases ("revenue", "bookings" and "billings" may or may not be the same thing)
• who reports it, and to whom
• where it comes from: which system, which report or export
• how it is calculated, as an actual formula
• how often it is updated
• known problems

Expect 30 to 100 rows at a company of 50 people, with a lot of overlap. That is normal.

Step 2: find the conflicts

The same few disagreements show up almost everywhere:

• Revenue: bookings, invoiced, collected and recognized revenue are four different numbers.
• Customers: total accounts, paying accounts and active accounts get mixed up.
• Periods: calendar or fiscal quarter; "this month" as month to date or last full month.
• Inclusion rules: does churn include paused customers? Does MRR include annual plans divided by 12?

Step 3: name a system of record for each metric

Trace each metric back to where the data is created. Revenue should come from the billing system, such as Stripe, not from a sales spreadsheet copied out of it two weeks late. Pipeline comes from the CRM. Ad spend comes from the ad platforms. Copies are where drift starts.

Phase 2: agree and write it down

Step 4: write a metric dictionary

For each metric that survives the audit, write:

"Revenue" is not a formula. "Sum of paid invoice lines, excluding refunds, credits and setup fees, with annual contracts spread monthly" is.

Step 5: settle it in one meeting

Put Finance, Sales, Marketing and whoever runs product or operations in a room with the draft dictionary. A few ground rules keep it moving:

• One definition per metric. If a team needs a different cut, that is a filter on the same metric, not a new metric with the same name.
• Finance decides ties on financial metrics; the product owner decides ties on usage metrics; the CEO breaks deadlocks.
• Record each decision and the reason. Six months from now someone will ask.

Step 6: publish it where people look

Link the dictionary from your wiki, from the dashboards that show the metrics and from your onboarding checklist. A dictionary that lives in one person's drive does not exist.

Phase 3: build the plumbing

Step 7: connect the systems of record

Connect each system of record to one analytics tool, so everyone reads the same data at the same freshness. In clariBI you add each system as a data source (billing, CRM, ad platforms, a database, spreadsheets) and each one gets its own dashboard automatically. The data sources documentation lists what connects and how.

This step removes a whole category of conflict: two people querying two copies of the data taken on different days.

Step 8: build a small set of official dashboards

Build dashboards that implement the dictionary exactly, and make them easy to tell apart from exploratory work. A plain naming convention works: prefix them with "Official:". A typical set:

• a company scorecard with the 5 to 7 metrics leadership reviews weekly
• finance: revenue, costs, margin, cash
• sales: pipeline, won deals, win rate
• customers: retention, churn, support load

When you build a custom metric in clariBI's dashboard builder, it has a plain-language description field. Paste the dictionary definition there, so the definition travels with the chart.

Step 9: decide who can change what

Everyone should be able to read the official dashboards. Far fewer people should be able to edit them. clariBI has five organization roles (Owner, Administrator, Analyst, Member, Viewer), explained in the roles article. On Professional and Enterprise you can also create custom roles and keep official dashboards in a workspace where most people are viewers.

Phase 4: get people to use it

Step 10: retire the competing versions

Find the spreadsheets and emailed reports that compete with the official numbers. Agree with each owner to replace them with a link to the official dashboard. This is the most political step, so do it one report at a time and start with the ones leadership sees.

Step 11: put the numbers into existing routines

Open the scorecard at the start of the weekly meeting, link dashboards from agendas, and add them to new-hire onboarding. Our guide to running a weekly business review with data shows one way to structure that meeting.

Phase 5: keep it true

• Review the dictionary quarterly. Add metrics through the same process; retire ones nobody uses.
• Watch the connections. A sync that fails quietly is how an SSOT starts to lie. In clariBI, each source shows its status and last successful sync, and the last sync time only moves when data actually arrived. The sync failures article explains what each error means.
• Announce definition changes. Say what changed, why and how it affects comparisons with earlier periods.
• Give it an owner. One person, even part time, who is responsible for the dictionary and the official dashboards.

Mistakes that sink SSOT projects

• Defining everything at once. Start with the 10 to 15 metrics that come up in leadership meetings.
• Treating it as a software purchase. A tool delivers the numbers; the agreement is what makes them the truth.
• No upkeep after launch. Without an owner, definitions drift within a year.
• Waiting for perfect. A published dictionary with a few rough edges beats a perfect one that never ships.

How to tell it is working

• The "which number is right?" argument stops happening in meetings.
• More people open the official dashboards each week.
• Fewer one-off "can you pull this number" requests.
• Decisions stop waiting on someone to reconcile spreadsheets.

For the wider set of habits around ownership, access and quality, see our practical start to data governance.

Where to start this week

Write down the three definitions of revenue your company uses today and which system each comes from. Then connect that system to clariBI and ask: "What was revenue by month for the last 12 months?" If the answer matches Finance's number, you have your first official metric.