Single source of truth is a phrase that survives contact with a boardroom and dies on contact with a database. Everybody agrees the company should have one. Nobody agrees which system holds it, who is allowed to change it, or what happens when the CRM says a customer is in Leeds and the finance ledger says Bradford. So the meeting ends with a nod, a project name, and eighteen months later three teams are still exporting to spreadsheets and reconciling by hand.
This guide is the working rather than the slogan. It covers what the term actually means once you have to implement it, how to choose which data domains go first, the four architecture patterns you can realistically build, the golden record rules that decide arguments, the integration layer that keeps the thing fed, a costed ninety-day plan, and the specific mistakes that quietly undo the work in year two. It sits alongside our data management and analytics and data warehousing practice.
It is written for mid-sized organisations, because the approach that works at 20,000 staff with a dedicated data office does not survive at 400 people with one analyst and a busy IT manager. A single source of truth in that setting is a governance decision wearing a technology costume, and the technology is the cheap half. If you have not measured the state of your records yet, our data governance framework guide is the right place to start, because you cannot declare an authoritative record until you know how far apart the existing ones are.
Table of contents
- What a single source of truth actually means
- Signs your business needs a single source of truth
- Choose the domains your single source of truth will cover
- Pick the architecture pattern for your single source of truth
- Write the golden record rules behind a single source of truth
- Assign ownership before you build a single source of truth
- Build the integration layer that feeds the single source of truth
- Measure whether your single source of truth is actually true
- A ninety-day plan to create a single source of truth
- What a single source of truth costs to build and run
- Tooling options for a single source of truth
- Single source of truth mistakes that undo the work
- Keeping the single source of truth true after go-live
- Frequently asked questions about the single source of truth
- References
What a single source of truth actually means
A single source of truth means that for each business entity — a customer, a supplier, a product, a site, an employee — exactly one system holds the authoritative value of each attribute, and every other system either reads it or is knowingly out of date. That is the whole definition. It is narrower and more demanding than most people expect.
One authority per attribute, not one system for everything
The common misreading is that a single source of truth means one giant system holding all data. It does not, and that ambition is what kills the project. Authority is granted per attribute. The HR system owns employee start dates; the CRM owns the account manager; the finance ledger owns the credit limit. Each attribute has exactly one owner, and the rest subscribe.
It is a decision, not a database
Nothing in a schema tells you which of two conflicting addresses is correct. Somebody decides, in advance, that the address on the signed contract wins over the one typed into a support ticket. A single source of truth is the written record of hundreds of decisions like that, plus the plumbing to enforce them. Buying a platform first and deciding afterwards is the standard failure.
What it is not
It is not a data warehouse, though a warehouse often reads from it. It is not a reporting layer, because reporting can be reconciled after the fact while operations cannot. And it is not the same as having good data quality — quality is a measurement, whereas a single source of truth is a structure that makes quality maintainable rather than a one-off cleanup that decays.
The single version of the truth distinction
Some teams use “single version of the truth” for the reporting sense — one agreed set of figures for the board — and reserve single source of truth for the operational sense, where systems read live values from one authority. The distinction is worth keeping, because the reporting version can be built in a quarter and the operational version cannot. Our data warehouse comparison guide covers the reporting half in detail.
Signs your business needs a single source of truth
Nobody funds this project on principle. It gets funded when the symptoms become expensive enough to name. If you recognise four or more of the following, the case for a single source of truth is already written in your operations; you just have not costed it yet.
The reconciliation spreadsheet nobody can rebuild
There is a workbook, it is owned by one person, it joins two exports on a fuzzy match, and the month-end close depends on it. When that person is on leave the close slips. This is the clearest signal, because the spreadsheet is a hand-built single source of truth with no owner, no audit trail and no successor.
Two teams quoting different numbers in the same meeting
Sales says 412 active accounts, finance says 388, and both are correct under their own definition. The disagreement is never really about the number; it is about the definition of “active”, which nobody has written down. A single source of truth forces the definition into the open, which is why it is politically harder than it is technically hard.
Customers telling you what you should already know
A customer updates their address with one team and receives the next invoice at the old one. Support has to ask which contract a caller is on because the CRM and the billing system disagree. Every one of these is a small trust withdrawal, and they compound faster than any internal efficiency loss.
Automation projects stalling at the data step
This is the modern trigger. Workflow automation and AI assistants both need a dependable record to act on, and they surface disagreement immediately rather than absorbing it the way a human does. Teams reach for our business process automation work and discover the blocker is upstream. Our guide on how to prepare business data for AI covers that dependency in depth.
Choose the domains your single source of truth will cover
You do not build a single source of truth for the whole business. You build one for one domain, prove it, then take the next. Choosing the wrong first domain is the most common reason a promising programme stalls before it produces anything visible.
Rank domains by dispute cost, not by size
The right first domain is the one where disagreement costs the most per week, not the one with the most records. Customer data usually wins on this measure, but in a manufacturer it is often product data, and in a services firm it is frequently the employee and skills record. Measure the cost before choosing, using a two-week time study rather than an opinion.
Start where one owner already exists
A domain with a natural owner — a credit controller for customers, a category manager for products — is dramatically easier than one where ownership is genuinely contested. The first delivery in a single source of truth programme should prove the mechanism, not settle the hardest political argument in the company. Save that fight for delivery three.
Keep the first domain to one entity and a dozen attributes
Scope the first domain to a single entity type and the ten to fifteen attributes that actually cause disputes. Legal name, registered number, primary address, billing contact, payment terms, credit limit, account owner, status. Everything else stays where it is. A narrow first pass reaches production in a quarter; a complete one reaches a steering committee in a year.
Write the entity definition before the schema
One page per entity: what counts as an instance, what does not, when it comes into existence, when it ends, and which attributes are mandatory. If two people in the room define “customer” differently — a legal entity, a billing account, a site — no amount of matching logic will save you. This document is the real deliverable of the first month.
Pick the architecture pattern for your single source of truth
There are four established patterns, and the choice determines cost, timeline and how much change the source systems must absorb. Most mid-sized organisations should be choosing between the first two and growing into the third; the fourth is rarely the right answer below several thousand staff.
Registry: match and point, change nothing
A registry holds identifiers and match keys only. It knows that customer 4471 in the CRM and account C-8823 in the ledger are the same organisation, and it publishes that mapping. Source systems keep their own data and change very little. It is the fastest route to a working single source of truth and the right first step for most companies.
Consolidation: build the golden record for reporting
Data flows into a central store where matching, merging and survivorship rules produce a golden record used for analytics and reporting. Operational systems still hold their own values and are not corrected. This is where a single source of truth for reporting lives, and it pairs naturally with a warehouse project you may already be funding.
Coexistence: publish the golden record back
The golden record is built centrally and then pushed back into source systems, so operational users see corrected values in the tools they already use. This is the pattern most organisations actually want, and it is where the real work is — every subscribing system needs a feed, a mapping and a reconciliation report.
Centralised: author it once, at the source
Records are created and edited directly in the master system, and everything else subscribes read-only. It produces the cleanest single source of truth and demands the most change management, because you are asking users to leave the application they know. Reserve it for domains with few authors, such as product or chart of accounts.
| Pattern | What it does | Time to first value | Change asked of source systems | Main risk |
|---|---|---|---|---|
| Registry | Matches records, publishes identifier mapping | 6–12 weeks | Almost none | Nothing is actually corrected |
| Consolidation | Builds a golden record centrally for reporting | 3–5 months | Read feeds only | Operations keep the bad data |
| Coexistence | Pushes the golden record back to source systems | 6–9 months | Write-back per system | Reconciliation and dual running cost |
| Centralised | Authoring happens once, in the master | 9–15 months | Users change tools | Adoption failure, shadow records return |
Write the golden record rules behind a single source of truth
The rules are the intellectual property of the programme. A platform can be replaced in a weekend; the rules took months of argument to agree. Write them as a document owned by the business, not as configuration buried in a tool nobody outside IT can read.
Matching: how you decide two records are the same
Deterministic matching uses exact keys — company number, VAT number, email. Probabilistic matching scores similarity across several fields and accepts above a threshold. Use deterministic rules wherever an authoritative identifier exists, and reserve probabilistic scoring for the long tail. Publish the threshold, because everyone will want to argue with it eventually.
Survivorship: which value wins a conflict
For every attribute, name the winning source and the tie-break. Registered address comes from Companies House, then the signed contract, then the CRM. Most recent update wins only where recency genuinely implies correctness, which is less often than people assume. A survivorship table with forty rows is worth more to a single source of truth than any amount of platform capability.
Confidence, not certainty
Not every merge is safe. Score each match and route anything between the auto-merge and auto-reject thresholds to a human queue. A single source of truth that silently merges two genuinely different companies with similar names does more damage in one afternoon than months of duplicate records ever did, and it is very hard to unpick afterwards.
Keep the history and the unmerge path
Store the contributing source records and the rule that produced each surviving value. When somebody challenges a value in six months — and they will — you need to show the derivation, not assert the answer. Being able to unmerge cleanly is what lets stewards accept a slightly more aggressive matching threshold, which is what makes coverage move.
Assign ownership before you build a single source of truth
Every failed programme in this space has the same post-mortem: the technology worked and nobody owned the outcome. Ownership is not a RACI chart produced in week two and never opened again. It is a small number of named people with the authority to overrule a business unit.
The data owner decides, the steward operates
The data owner is a business leader accountable for one domain — the finance director for customer credit data, the operations director for sites. They arbitrate disputes and approve rule changes. The steward is the person who works the queue daily, chases missing values and spots patterns. Conflating the two roles is why so many single source of truth programmes stall at 60% coverage.
Budget the stewardship team as a standing cost
A master record is a product, not a project, and products have running costs. Below 250 staff, part-time stewardship attached to existing roles is honest. Between 250 and 1,000, one to two dedicated people per major domain is the usual shape. Leaving this out of years two and three is the single most common costing error, as our master data management business case guide sets out.
Give the owner a real veto
If a business unit can opt out of the single source of truth because their process is special, the whole structure collapses to advisory. Exceptions must be approved by the owner, documented, time-boxed and reviewed. Two permanent exceptions are enough to teach everybody else that the rules are negotiable.
Put it on an existing governance agenda
Do not create a new committee. Attach the single source of truth decisions to a forum that already meets and already has authority — the operations board, the change advisory board, whatever exists. A new committee gets diarised, then rescheduled, then quietly abandoned by month five.
Build the integration layer that feeds the single source of truth
The rules decide what is true. The integration layer decides how quickly everyone finds out. Getting this wrong is what produces the worst possible outcome: an authoritative record that is authoritatively stale.
Match the latency to the decision, not to the technology
Ask what decision the data supports and how wrong it can afford to be. A credit limit checked at order entry needs to be current within minutes. A marketing segment can be a day old. Do not pay event-streaming prices for a nightly reporting need, and do not run a nightly batch behind a real-time approval gate.
Change data capture beats full extracts
Reading an entire table every night to find fifty changed rows loads the source system, delays the window and hides the change history. Change data capture, where the source database publishes its own change log, is almost always the better mechanism once volumes pass a few hundred thousand records. Our data migration checklist covers the mechanics of moving history the first time.
Every subscriber needs a reconciliation report
A feed that runs successfully is not a feed that is correct. Each subscribing system needs a daily count and checksum comparison against the master, published where someone actually looks. Silent divergence is the failure mode that takes a single source of truth from trusted to ignored, and it usually takes about four months of nobody checking.
Plan for the dual-running period
The old local record stays authoritative until the last consumer moves, so you fund both for a period. That overlap is real money and real confusion, and it belongs in the plan rather than in a footnote. Name the date each system stops being authoritative, and make somebody accountable for hitting it.
| Method | Typical latency | Load on source | Use it for | Watch out for |
|---|---|---|---|---|
| Nightly full extract | 12–24 hours | High | Small reference tables | Window overruns as volume grows |
| Incremental extract | 1–12 hours | Moderate | Reporting and analytics feeds | Deletes are easy to miss |
| Change data capture | Seconds to minutes | Low | High-volume operational domains | Schema changes break the reader |
| Event publication | Sub-second | Low | Cross-system workflow triggers | Ordering and replay complexity |
| Synchronous API read | Immediate | Varies with traffic | Approval gates and checkout | Master becomes a availability dependency |
Measure whether your single source of truth is actually true
A programme without measurement becomes a belief system. Four measures, published monthly on the same page, will tell you more than any platform dashboard, and they are the numbers to put in front of the sponsor who funded the work.
Coverage: how much of the estate subscribes
The percentage of in-scope systems and records that read from the master rather than holding their own. This is the number that determines whether the investment pays back, and it is the one that slips silently. A single source of truth at 40% coverage is an expensive second opinion.
Agreement rate: do the systems still disagree
Sample records across subscribing systems and count how many attributes match the master exactly. Falling agreement is the early warning that a feed has broken or a team has resumed local editing. Run it weekly and automatically; a manual quarterly check finds the problem a quarter late.
Steward queue age, not queue size
Queue size fluctuates with business activity and tells you little. The age of the oldest unresolved item tells you whether stewardship is actually resourced. Anything older than ten working days means either the rules are too aggressive or the team is too small, and both are fixable once visible.
Time to answer a definitional question
How long does it take somebody to find out what “active customer” officially means and who decided? If the answer is a Teams message to a colleague, the single source of truth exists in one person’s head. If it is a catalogue entry with an owner and a date, the governance is real.
A ninety-day plan to create a single source of truth
Ninety days is enough to produce a registry for one domain with real matching, a published survivorship table, an owner and a measured baseline. It is not enough to correct every system, and promising otherwise is how credibility is lost in month four.
Weeks 1 to 3: define and measure
Write the entity definition, agree the attribute list, and measure the current disagreement rate across a sample of 2,000 records. The baseline is the most valuable artefact of the whole quarter, because every later claim about improvement is measured against it and there is no way to reconstruct it later.
Weeks 4 to 6: agree the rules
Draft the survivorship table and the matching thresholds, then walk them through with the people who will be overruled by them. Expect this to be the slowest part, and expect at least one attribute where the argument is genuinely unresolved. Escalate that one to the owner rather than letting it hold the other thirty-nine.
Weeks 7 to 10: build the registry and the queue
Stand up matching, produce the identifier mapping, and put the ambiguous cases into a queue with a named steward working it. At this point the single source of truth is real but read-only: it tells you what is the same, and it exposes disagreement without yet correcting anything.
Weeks 11 to 13: publish, measure, decide
Publish the golden record to one subscribing system, produce the first reconciliation report, and re-measure the agreement rate against the week-3 baseline. Then take a genuine decision about whether to fund coexistence for this domain or move the registry to the next one. Both are legitimate outcomes.
| Weeks | Focus | Deliverable | Who leads | Done when |
|---|---|---|---|---|
| 1–3 | Define and measure | Entity definition, attribute list, baseline | Data owner | Disagreement rate is a number, not a feeling |
| 4–6 | Agree the rules | Survivorship table, match thresholds | Data owner | Every attribute has a named winning source |
| 7–10 | Build the registry | Identifier mapping, steward queue | Integration lead | Ambiguous matches route to a human |
| 11–13 | Publish and re-measure | First subscriber feed, reconciliation report | Integration lead | Agreement rate compared to the baseline |
| 14+ | Decide and extend | Funding decision for coexistence or domain two | Sponsor | A written decision exists either way |
What a single source of truth costs to build and run
Costs are dominated by people and integration, not by the platform. Anyone presenting a single source of truth proposal where licensing is the largest line has not yet counted the work, and a reviewer will find that within about two minutes.
The first-year shape for a 400-person company
A realistic first-year figure for one domain reaching coexistence in a 400-person organisation is £310,000 to £460,000. Integration is the biggest slice, remediation next, then the stewardship team from the month they are hired rather than from January. Platform and licences are usually under a fifth of the total.
Remediation is the line everyone halves
Deduplicating 200,000 customer records is not a weekend of scripting. Somebody defines survivorship, reviews the matches a machine will not decide, chases owners for missing registration numbers and re-keys what cannot be salvaged. Price those hours at the same rate you use on the benefit side, or the arithmetic values a saved hour differently from a spent one.
Running costs do not decay
Year two is not year one divided by three. Integration maintenance, steward salaries, reference data subscriptions and rule changes continue indefinitely, typically at 45% to 60% of first-year cost. A single source of truth that is funded as a project and then starved as a service degrades to its previous state within about two years, and the second attempt is harder to fund.
Tooling options for a single source of truth
The tooling question arrives too early in most conversations, usually because it is the easiest part to have an opinion about. Answer it after the domain, the pattern and the owner are settled, and answer it at the smallest tier that meets the requirement.
Do not buy a hub to solve a definition problem
If two teams disagree about what “active customer” means, a matching engine will not help. Buy tooling when the volume of records or the number of subscribing systems has genuinely outgrown what your existing warehouse and a disciplined process can carry. That threshold is usually higher than vendors suggest.
The warehouse you already have is a legitimate first home
For consolidation-pattern reporting, a modelled layer in an existing warehouse with tested transformations is a perfectly respectable single source of truth. It costs a fraction of a hub, uses skills you already have, and can be pointed at a real platform later without wasting the rules work. Our Power BI implementation guide covers the reporting layer that sits on top.
A catalogue is what makes it findable
Whatever holds the data, something must record what each attribute means, who owns it and where it came from. A data catalogue is cheap relative to a hub and delivers most of the governance value in the first quarter, which is why it is often the better first purchase.
| Option | Indicative annual cost | Domains it carries | Governance included | Right when |
|---|---|---|---|---|
| Modelled layer in your warehouse | £0–£15,000 | 1–2, reporting only | None — you write it | Consolidation pattern, reporting need |
| Data catalogue and quality tool | £12,000–£45,000 | All, descriptively | Ownership, lineage, glossary | Definitions are the bottleneck |
| Cloud-native MDM service | £35,000–£90,000 | 2–4 operational | Matching, stewardship queue | Coexistence across several systems |
| Full enterprise MDM hub | £90,000–£250,000 | Many, with workflow | Full authoring and approval | Multi-entity, regulated, 1,000+ staff |
Single source of truth mistakes that undo the work
Failures in this area are unusually predictable. Five errors account for most of them, and every one is visible in the plan before a line of integration code is written.
Declaring a system authoritative without moving the authors
Announcing that the CRM is now the single source of truth for customer data, while three teams continue to create records elsewhere, produces a system that is authoritative in the slide deck and wrong in practice. Authority follows the authoring path. If people still create records somewhere else, that somewhere else is your real master.
Building a beautiful master nobody subscribes to
The technically satisfying half is matching and merging. The valuable half is getting eleven systems to read the result. Programmes that spend 80% of effort on the master and 20% on subscribers end up with a very accurate record that changes nothing. Invert that ratio deliberately.
Letting exceptions become permanent
Every exception is granted temporarily and reviewed never. Attach an expiry date to each one at the moment it is approved, and put the list on the same page as the coverage number so it cannot be quietly forgotten. Two permanent exceptions are enough to make the rules optional for everybody.
Treating go-live as the finish
The launch is when the maintenance starts. New systems arrive, an acquisition brings 40,000 records with different conventions, a supplier changes its identifier format. Without a standing team the agreement rate decays quietly, and nobody notices until somebody quotes a wrong figure in a board meeting.
Ignoring the legal dimension
Accuracy is a statutory obligation under UK data protection law, not an internal quality preference, and a single source of truth is one of the strongest ways to satisfy it. It also concentrates personal data, which means access controls, retention rules and a lawful basis need to be settled before the first merge, not retrofitted after an access request arrives.
Keeping the single source of truth true after go-live
Everything above gets you to a working state. Staying there is a different discipline, and it is the half that determines whether the money was well spent or merely spent.
Put the agreement rate in an operational report
Not a data team dashboard — the report the operations board already reads. A number that appears in front of executives monthly gets defended. A number that lives in a tool only the data team opens becomes a curiosity, then a memory, then a surprise.
Make new systems subscribe as a condition of purchase
Add a line to the procurement checklist: any new system holding customer, supplier or product data must consume the master record and must not create its own. Enforcing this at purchase costs an hour; enforcing it eighteen months after go-live costs an integration project and an argument with a supplier.
Review the rules quarterly, not never
Businesses change what they mean by their own entities. A quarterly review of the survivorship table with the data owner takes ninety minutes and prevents the slow drift where the documented single source of truth rules and the actual behaviour diverge until nobody trusts either.
Rehearse the recovery path
Know how to unmerge, how to replay a feed, and how to restore the master to a point in time. The first bad merge will happen, and the difference between an afternoon and a fortnight is entirely whether someone has done it before in a test environment. Treat it exactly like a restore rehearsal.
Frequently asked questions about the single source of truth
How long does it take to create a single source of truth?
A registry for one domain takes roughly a quarter. Coexistence for that same domain takes six to nine months from funding. A whole business across four or five domains is a two to three year programme, and anyone quoting less is describing a reporting layer rather than an operational master.
Do we need a dedicated MDM platform?
Usually not at first. Most mid-sized organisations get a long way with a modelled layer in the warehouse they already run, a catalogue for definitions and ownership, and a disciplined process. Buy a hub when the number of subscribing systems, not the number of records, has outgrown what you can maintain by hand.
Can a spreadsheet be a single source of truth?
Technically yes, practically no. A workbook can hold the authoritative value, but it cannot enforce access, record derivation, publish to subscribers or survive its author leaving. If a spreadsheet is genuinely your master today, treat that as the strongest possible evidence for funding the work rather than as a solution.
What is the difference between this and a data warehouse?
A warehouse is optimised for analysis and can be reconciled after the fact. A single source of truth is about which value is authoritative right now, including for operational decisions such as approving an order. They complement each other, and the warehouse very often reads from the master rather than the other way round.
Who should own it — IT or the business?
The business owns the decisions; IT owns the plumbing. A programme owned entirely by IT cannot arbitrate a dispute between two departments, which is the actual job. A programme owned entirely by the business stalls on integration. Name both, and be explicit that the tie-break sits with the data owner.
How do we prove it worked?
Compare the agreement rate against the week-3 baseline, publish the coverage percentage, and track the hours no longer spent reconciling. Those three numbers, measured the same way each month, are more persuasive than any qualitative account of improved confidence. Our data governance framework guide covers the reporting cadence.
References
DAMA International Data Management Body of Knowledge
EDM Council Data Management Capability Assessment Model
Dublin Core Metadata Initiative
ICO Guide to the Accuracy Principle
ICO Guide to Data Minimisation
ICO Accountability and Governance
Microsoft Purview Documentation
AWS Glue Data Catalog and Crawlers
Google Cloud Dataplex Introduction
Microsoft Guidance on Star Schema Modelling
Martin Fowler on the Strangler Fig Application
GOV.UK Technology Code of Practice
