A single source of truth (SSOT) is a data architecture practice in which every data element, such as a customer’s credit limit or a product’s list price, is created and changed in exactly one authoritative system, and every other system reads a copy of it. SSOT is about who is allowed to write a value, not about storing all data in one database.
That distinction matters because almost no company can put everything in one place. MuleSoft’s 2026 Connectivity Benchmark Report, a survey of 1,050 IT leaders published in February 2026, found that the average organization runs 957 applications and only 27% of them are connected. A single source of truth is how those systems stop disagreeing about the same customer, product or invoice.
What is a single source of truth?
A data element has a single source of truth when there is one place where it can be created or changed, and every other copy is derived from that place. The idea comes from software design, where Andrew Hunt and David Thomas stated it as the DRY principle (Don’t Repeat Yourself) in The Pragmatic Programmer:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Andrew Hunt and David Thomas, The Pragmatic Programmer, Tip 15 (publisher’s tip list)
Applied to business data, the system is the whole company: the ERP, the CRM, the HR system, the product catalog and the spreadsheets that feed them. An SSOT does not require one database. It requires that, for each field, everyone knows which system owns it.
Many vendor definitions describe an SSOT as a central repository that collects data from every system. That repository is useful, but it is a copy. If a customer’s billing address can still be edited in both the CRM and the ERP, a data warehouse that collects both addresses does not create a single source of truth; it records the disagreement.
To check whether a data element really has a single source of truth, ask four questions about it. If any answer is “more than one” or “nobody knows”, it does not.
- Where can this value be created? The answer should be exactly one system, for example new customers are created only in the ERP, not in the ERP and the CRM.
- Where can it be changed? The same system. A second screen that lets users overwrite the value breaks the SSOT even if the systems sync afterward.
- Who reads it, and how stale can their copy be? Every other system is a reader. Write down how each one receives changes (a live API call, a nightly batch, an event stream) and how old its copy can get.
- Who settles a conflict? Name the business owner, often called a data steward, who decides when two systems disagree, and the rule they apply.
Example: who owns which field of a customer record
A customer is rarely one record in one system. The table shows a typical split for a manufacturer that runs an ERP, a CRM, an HR system and an online store. It is an illustration, not a rule: your split will differ, but every row needs exactly one owner.
| Field | System of record (where it is edited) | Systems that read a copy | Why it lives there |
|---|---|---|---|
| Legal name and tax ID | ERP | CRM, online store, data warehouse | Invoices and tax filings are issued from the ERP |
| Credit limit and payment terms | ERP | CRM (read-only), store checkout | Set by credit control; sales should not be able to raise it |
| Billing address | ERP | CRM, online store | Printed on every invoice |
| Contacts, phone numbers and email | CRM | ERP (for invoice emails), marketing tools | Kept current by the sales team that talks to the customer |
| Marketing consent | The system where consent was captured, usually the CRM or marketing platform | Every system that sends marketing | You need one record of when and how consent was given |
| Account manager | CRM, pointing to an employee record owned by the HR system | ERP, reporting | People data belongs to HR; the CRM only references it |
| Lifetime revenue | Nobody edits it: calculated in the data warehouse from ERP invoices | BI dashboards | A derived figure needs an owner for its definition, not an editor |
The last row is the one most SSOT projects miss. Derived figures such as lifetime revenue or active customers have no editor; what needs a single owner is the definition. That is the difference between a single source of truth and a single version of truth, covered next.
SSOT vs system of record vs single version of truth vs golden record
These terms are often used as synonyms. They are not, and the differences decide how you build the thing.
| Term | What it is | Scope | Example |
|---|---|---|---|
| Single source of truth (SSOT) | A design principle: each data element is authored in one place and copied everywhere else | The whole data landscape | Customer credit limit edited only in the ERP |
| System of record (SoR) | The system that is authoritative for a particular data element or domain | One domain or field | The ERP general ledger for posted journal entries |
| Single version of truth (SVOT) | One agreed definition and calculation for a metric | Reporting and analytics | One definition of an active customer used in every dashboard |
| Golden record | The best merged version of an entity, assembled from several sources by matching and survivorship rules | One entity, such as a customer | An MDM hub’s merged customer built from CRM and ERP records |
| Master data management (MDM) | The discipline and software for governing shared master data | Customers, suppliers, products, locations | An MDM hub that publishes the golden record |
| Data warehouse | A read-optimized copy of data for analysis | Reporting | Nightly loads from the ERP and CRM |
An SSOT is built out of systems of record. A company has many of them, one per domain or field, and the SSOT is the agreement about which is which. That makes it as much a governance job as a technical one, which is how Gartner defines MDM:
MDM is a technology-enabled discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, semantic consistency and accountability of the enterprise’s official, shared master data assets.
Gartner, The Seven Building Blocks of MDM (2012), also in the Gartner IT Glossary
A note on “system of records”, with an s
In US government, system of records is a legal term with a different meaning. The Privacy Act of 1974 (5 U.S.C. 552a) defines it as “a group of any records under the control of any agency from which information is retrieved by the name of the individual or by some identifying number, symbol, or other identifying particular assigned to the individual.” It governs privacy notices for federal agencies, not data architecture.
How to build a single source of truth: 6 patterns
There are six common ways to give each data element one owner. They differ on one question: where is a record edited, and how do the other systems get the change?
| Pattern | Where records are edited | How other systems get changes | Best for | Watch out for |
|---|---|---|---|---|
| 1. One integrated suite | In the suite, for example an ERP with built-in CRM and HR modules | They share the suite’s database | Companies that can standardize on one vendor | Specialist systems usually survive outside the suite |
| 2. MDM, registry style | In the source systems | The hub keeps a cross-reference index and a read-only combined view | Many systems you cannot change | The sources still disagree; the hub only shows it |
| 3. MDM, consolidation style | In the source systems | A golden record in the hub, used mainly for reporting | A fast route to trusted reporting | Fixes still have to be made in the source systems |
| 4. MDM, coexistence style | In the hub and in the source systems | Synchronization in both directions | Gradual migration | Needs explicit conflict and survivorship rules |
| 5. MDM, centralized style | In the hub, which becomes the system of record | Source systems subscribe to published changes | Strict control of customer, supplier or product data | The hub becomes critical infrastructure |
| 6. Event log as source of truth | Changes are recorded as an ordered log of events | Systems build or update their state from the log | Audit-heavy domains and engineering teams | Needs event-driven design from the start |
The four MDM styles are Gartner’s taxonomy; the descriptions above follow Stibo Systems’ June 2026 guide. Only the centralized style turns the hub itself into the system of record; in the registry style, changes keep being made in the source systems. Martin Fowler describes the sixth pattern, event sourcing, this way:
The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself.
Martin Fowler, Event Sourcing
Integration tools such as an enterprise service bus, an iPaaS or change data capture move data between systems; they do not decide who owns it. They carry the copies an SSOT needs, which is why the ownership decisions in the write-authority test have to come first. Our guide to enterprise application integration covers the transport side.
Is ERP a single source of truth?
Partly. An ERP is usually the system of record for financial transactions, and often for supplier, customer billing and item data, because its modules share one database: posting an invoice in accounts receivable produces the matching general ledger entry inside the same system, not in a separately maintained copy. That makes the ERP the natural owner of anything that ends up in the financial statements.
It is rarely the source of truth for everything. CRM, HR, product lifecycle and e-commerce systems usually own fields of their own, and with 957 applications in the average organization (MuleSoft, 2026), no single suite covers the whole landscape. After an acquisition, a company can also run two ERPs that each claim to own the same customer, which is a common reason to introduce MDM. See how an ERP system works for how the modules fit together.
Benefits of a single source of truth
The benefits all follow from removing conflicting copies of the same value.
- No contradictory values in daily work. Sales, finance and the warehouse see the same credit limit, address and price.
- Less reconciliation. When values cannot diverge, nobody spends month-end matching them.
- Simpler integration. Data flows one way, from owner to readers, instead of every system syncing with every other. In MuleSoft’s 2026 survey, IT teams spent 36% of their time designing, building and testing custom integrations, and 82% of IT leaders named data integration as one of their biggest challenges.
- A clear audit trail. There is one place to ask who changed a value, when and why.
- Steadier input for AI. Agents and models are only as consistent as the data they read. The same survey found 64% of IT leaders concerned about meeting their near-term AI goals, in a sample where only 27% of applications were connected on average.
What a single source of truth does not fix
An SSOT removes contradictions between systems. It does not make the data right, and it adds a dependency.
- Wrong data. An SSOT makes a value consistent, not correct. A wrong tax ID entered in the system of record is now wrong everywhere, so data quality checks still matter at the point of entry.
- Disagreements about meaning. Two departments can read the same invoices and still report different revenue if they define it differently. That needs a single version of truth: governed metric definitions.
- Dependency. Every reader depends on the owner being available and correct. In the 2026 MuleSoft survey, 71% of IT leaders said their infrastructure makes systems overly dependent on one another.
- Stale copies. A reader that receives a nightly batch can be a day behind. Decide per field how fresh each copy must be.
Barriers to a single source of truth
Most obstacles are organizational rather than technical:
- Data silos. Departments that keep their own version of customers or products, often in spreadsheets kept just in case, which quietly become a second source.
- No named owners. Without a data steward for each domain, nobody can settle a conflict, so both values survive.
- Systems you cannot change. Legacy or vendor-hosted applications that insist on their own customer table. Registry and coexistence MDM exist for exactly this case.
- Mergers and acquisitions. Two ERPs and two customer masters, each correct by its own rules.
- Privacy rules. Some personal data may not be copied freely, which limits how widely it can be replicated to readers.
Examples of a single source of truth
Each example below has one place where the data is edited and many places that read it.
- Finance. The general ledger in the ERP is the system of record for posted transactions; reporting and consolidation tools read from it and never post to it.
- Product data. A product information management (PIM) system owns descriptions, attributes and images; the online store, marketplaces and print catalogs receive copies.
- Software development. The version-control repository is the source of truth for code; build and deployment tools read from it instead of anyone editing servers directly.
- Customer master. In a centralized MDM setup, new customers are created only in the hub and published to the ERP and the CRM.
FAQs
What does SSOT stand for?
SSOT stands for single source of truth: the practice of creating and changing each data element in exactly one authoritative system, so that every other system works from a copy of it. It is also called single point of truth. It is unrelated to SSO, which means single sign-on, a login method.
What is the difference between a system of record and a single source of truth?
A system of record is the system that is authoritative for a particular data element, such as the ERP for posted invoices. A single source of truth is the overall arrangement in which every data element has exactly one system of record and every other system reads from it. A company has many systems of record but aims for one single source of truth.
What is the difference between a single source of truth and a single version of truth?
A single source of truth governs where data is created and changed. A single version of truth governs what a number means, for example one agreed definition of revenue or active customers used in every report. You can have one without the other: identical data still produces different figures if teams calculate them differently.
Is a data warehouse a single source of truth?
Not for operational data. A data warehouse is a read-optimized copy loaded from operational systems, so it cannot be the place where a customer address or credit limit is changed. It can, however, be the agreed home of a single version of truth for reporting, where governed metric definitions live.
Is an ERP system a single source of truth?
Usually for financial transactions, and often for supplier, billing and item data, because ERP modules share one database. It is rarely the source for everything: CRM, HR, product lifecycle and e-commerce systems normally own some fields, so an ERP is one system of record among several.
Is SSOT the same as SSO?
No. SSOT, single source of truth, is about where data is authored. SSO, single sign-on, is an authentication method that lets a user log in once to reach several applications. Single sign-on controls who can open a system; it does nothing to stop two systems holding different versions of the same record.
How this page was checked
Checked 7 October 2026 against primary sources: MuleSoft’s 2026 Connectivity Benchmark Report (published 5 February 2026) for the statistics, Gartner for the MDM definition, the publisher’s tip list for The Pragmatic Programmer, Martin Fowler’s own article on event sourcing, and the US Code for the Privacy Act. We left out the widely repeated cost-of-bad-data figures because the original sources give different numbers from different years.
Corrections in this revision: earlier versions listed single sign-on (SSO) as a way to achieve an SSOT, gave a search engine as an example of one, and described an SSOT as a database that combines many copies of data. None of those is accurate, and the How to Achieve SSOT graphic has been relabeled.
Sources
- Agentic Transformation Reaches New Heights: 2026 Connectivity Benchmark Report Insights, MuleSoft, 5 February 2026
- The Seven Building Blocks of MDM: A Framework for Success, Gartner, 12 March 2012, and the Gartner IT Glossary entry for master data management
- The Pragmatic Programmer tips, Andrew Hunt and David Thomas (Tip 15)
- Event Sourcing, Martin Fowler
- 4 common master data management implementation styles, Stibo Systems, June 2026
- 5 U.S. Code 552a, Records maintained on individuals, via Cornell Law School’s Legal Information Institute
Using Google Search? Add erp-information.com as a preferred source.