What a single source of truth actually requires

"We need a single source of truth" is one of the few phrases that survives every reorganization. It is almost always said in response to a real problem: two screens show two numbers for the same thing, and nobody in the room can say which one to act on. The trouble is what the phrase is taken to mean. In most organizations it is heard as "we should get everything into one system", which turns a data ownership problem into a consolidation program that costs seven figures and does not fix it.

The achievable version is narrower and considerably more useful. For each entity the business cares about, one system is authoritative, that decision is written down, and every other copy is derived from it and visibly marked as a copy. You can run forty systems and have a single source of truth. You can run one ERP and not have one, because three departments maintain their own customer lists inside it in fields nobody agreed on.

One system is not the goal, and usually not the fix

Consolidation is attractive because it sounds like it removes the disagreement by removing the second system. In practice it moves the disagreement inside one application. The same people still need different definitions of an active customer, and they still get them. Now they arrive through custom fields, saved views, and a spreadsheet exported every Monday. The reporting mismatch reappears within a year, and it is harder to see because everything is nominally in one place.

Consolidation also fails on fit. The systems in a typical operation exist because each is genuinely better at its job than a general-purpose platform would be. Replacing a good field service tool with an ERP module so that the data lives in one database trades a data governance problem for an adoption problem, and adoption problems are worse. People route around software they dislike, and the workaround is always a spreadsheet you cannot see.

• Consolidation costs are dominated by migration and retraining, neither of which produces agreement about definitions.
• The number of systems is not what causes conflicting numbers. Unassigned ownership is.
• One platform still needs a rule for who may change a credit limit, and that rule is the actual work.
• Best-of-breed tools usually earn their place; the integration between them is what was never designed.
• A consolidation program takes two years, during which the original reporting complaint goes unanswered.
• Ownership decisions can be made in a week and start paying immediately, with or without consolidation.

System of record, system of entry, system of reference

Most arguments about who owns a piece of data are really three separate questions collapsed into one. Separating them dissolves a surprising number of disputes, because the parties usually want different things and have been told they are competing for the same thing.

• System of record: the system whose value is authoritative. If two systems disagree, this one is right by definition, and correcting the data means correcting it here.
• System of entry: where a human or process first types or captures the value. There can be several, and they can all be somewhere other than the system of record.
• System of reference: any system that displays or uses the value without owning it. It holds a derived copy, refreshed on a defined cadence, and it may not change it.

A customer address can be captured by a salesperson in the CRM, by a dispatcher on a job ticket, and by a clerk in the accounting system, and still have one owner. The mechanism is that entry anywhere writes through to the system of record, which validates and normalizes the value and then publishes it back out. Three entry points, one owner, no ambiguity. What breaks the model is not multiple entry points; it is entry points that keep their own version.

Assign ownership one entity at a time

Ownership is decided per entity, and the answers differ because the consequences differ. Finance should own anything with an audit trail attached. Operations should own anything that describes work in the field. The exercise takes a couple of workshops and produces a document that outlives every system currently in the estate.

Write the answers down in a document that names the entity, the owning system, the human owner, and the fields in dispute. If a table cell genuinely cannot be filled, split ownership by field rather than by record (operations owns the service address, finance owns the billing address) and enforce that split in the integration. Do not resolve the gap with last-write-wins. Last-write-wins means a stale cache can overwrite a corrected tax registration and nobody will find out until an audit.

Ownership only counts if the owning system wins

A published ownership matrix that no system enforces is a diagram. Ownership becomes real at the point where two values disagree and the resolution is not a conversation. The owning system's value replaces the other one, automatically, and the override is logged. If the answer to a conflict is that someone in operations emails someone in finance, the entity does not have an owner.

• Every derived field carries its source system and the timestamp of its last refresh, visible to the user.
• Conflicts resolve toward the owner without human arbitration, and the discarded value is retained in a log rather than deleted.
• Any system holding a copy can be fully rebuilt from the owner, which is the practical test of whether the copy is derived.
• Reports state which system each figure came from, so a mismatch becomes a traceable question rather than an argument.

You cannot agree about a customer you cannot both identify

Ownership rules assume the two systems are talking about the same record. Usually they cannot prove it. The systems were populated independently for years, so the same customer exists as three variations of a name, two of which are marked do not use. Until identity is solved, every ownership rule is applied to the wrong record some percentage of the time, and a few percent is enough to make a customer master untrustworthy.

• Email is not an identifier. People change jobs, share inboxes, and use one shared address across several legal entities.
• Company name is not an identifier. Legal suffixes, punctuation, and trading names differ between the system sales use and the one finance use.
• Address is not an identifier. Two subsidiaries can share a headquarters and require separate invoices and separate tax treatment.
• The workable answer is a dedicated external identifier, written back into both systems at creation and used as the only thing matching relies on.

For records that already exist, reconciling identity is a project with a budget and human review of anything below a high confidence threshold. It is not a script someone runs on a Friday. Budget for it explicitly, because it is the work that determines whether everything downstream holds.

The write-path rule

The operating rule that makes all of this enforceable is simple to state and unpopular to implement: for any given field, exactly one system may originate a change. Everything else either proposes a change to that system or displays the result. Bidirectional sync on the same field is not a feature, it is a decision to build a conflict engine, and every rule in that engine is a rule someone will be surprised by during a month-end close.

1. 1

   List the fields that actually matter, not every field. Usually it is between twenty and sixty across the whole estate.

2. 2

   Name the single originating system for each one, and check it against the entity ownership table for contradictions.

3. 3

   Make the field read-only everywhere else, showing the source and refresh time.

4. 4

   Where another team must be able to change the value, build a request path into the owning system rather than a second write path.

5. 5

   Add a reconciliation job that compares copies against the owner on a schedule and reports drift as a defect with an assignee.

Governance is a person, not a tool

The last requirement is the one no product can supply. Every entity needs a named individual who decides what the entity means and settles definition disputes. Not a committee, not a platform, not a data catalogue. When two departments disagree about whether a customer who has not ordered in fourteen months is active, someone has to choose, and the choice has to be recorded somewhere both departments can read.

This is why single-source-of-truth programs sold as tooling purchases underdeliver. A warehouse, an integration platform, and an MDM product are all reasonable ways to implement decisions that have already been made. None of them makes the decisions. Buy the tool after the ownership table exists and has survived an argument, not before.