The Single Source of Truth: What It Means and How to Build One

Short answer: A single source of truth is one designated system where each type of business data officially lives, with every other tool reading from it rather than storing its own copy. It doesn't mean one tool for everything — it means one authoritative home per data type, and clear rules about which system wins when they disagree.

Ask a founder how many active clients they have. Watch what happens. If the answer requires cross-referencing a CRM, a spreadsheet and the accounting system — and produces three different numbers — there is no source of truth.

What problem does it actually solve?

Duplicate data isn't a tidiness issue. It's a decision-making issue. When the same fact exists in four places, three of them are silently wrong at any given moment, and nobody knows which three. The downstream effects are familiar: invoices to the wrong address, a client contacted twice about the same thing, reports that don't reconcile, and a team that quietly stops trusting the systems and reverts to asking each other.

It also blocks automation entirely. You cannot build a reliable workflow on top of data whose canonical version is undefined.

Does it mean using one tool for everything?

No — and this is the most common misreading. A single source of truth is defined per data type, not per business. A healthy small-business setup might look like:

• Companies and contacts — the CRM is authoritative.
• Financial transactions — the accounting system is authoritative.
• Project status and deliverables — the project tool is authoritative.
• Documented process — the knowledge base is authoritative.

Everything else reads from those, via integration or reference. Nobody maintains a parallel copy.

How do you decide which system wins?

Three tests, applied per data type:

• Where is it created? The system where a record is first captured is usually the natural owner.
• Where is it most complete? The system holding the richest version of the record has a strong claim.
• What has the best structure? A relational database beats a flat spreadsheet for anything with relationships — clients to projects, projects to invoices.

When two systems tie, pick the one with the better API. You'll be syncing from it for years.

How do you build one without stopping the business?

Sequentially, one data type at a time.

1. Inventory the copies. List every place a given data type currently lives. Most businesses find more than they expected.
2. Nominate the owner. Choose the authoritative system and write the decision down.
3. Reconcile. Merge the versions, resolve conflicts, and clean before you migrate. Migrating dirty data just relocates the problem.
4. Redirect the inputs. Change where new records get created so nothing new enters the wrong system.
5. Demote the copies. Make the old locations read-only, or delete them. This step gets skipped, and skipping it undoes everything above.
6. Connect. Only now build the syncs and automations.

What breaks a source of truth after it's built?

Three things, reliably: someone exports to a spreadsheet to do a one-off analysis and the spreadsheet becomes permanent; a new tool is bought without deciding how it fits the data model; and manual entry paths are left open "just in case". Guard against all three explicitly.

Frequently asked questions

Is a spreadsheet ever an acceptable source of truth?

For a very small dataset with one editor and no relationships, yes. Beyond about 200 records or two editors, it stops being reliable.

What about data that genuinely lives in two places?

It doesn't. One place is authoritative and the other holds a synced copy. The distinction matters when they conflict — and they will.

How long does this take?

For a small business with three or four data types, expect two to six weeks including cleanup. The cleanup is the long part.

We rebuild CRM, intake, finance and reporting into one connected backbone. See the case studies.