One Source of Truth, Explained | Cognovat Blog
ERP 8 min read · Jan 2026

One source of truth, explained

C
The Cognovat Team
ERP & Engineering

"We need a single source of truth." It's one of the most common things we hear in early project conversations — said confidently, as an obvious goal, with the implicit assumption that everyone in the room means the same thing by it. They rarely do. The phrase has been used so often and so loosely that it's worth stopping to define it precisely, because the difference between what it actually means and what people typically implement in its name is significant.

What it actually means

A single source of truth is a system design principle: every piece of data in an organisation has one authoritative location where it is written, and all other systems read from that location rather than maintaining their own copy. The inventory count lives in one place. The payroll figure lives in one place. The customer record lives in one place. When any system needs that data, it fetches the authoritative version — it doesn't store a local copy that can drift.

This is different from having all your data in one database, which is what most people picture when they hear the phrase. A single database can still produce multiple conflicting versions of truth if different teams write to different parts of it without coordination. And a distributed system can achieve a genuine single source of truth if the write authority for each data entity is clearly defined and enforced.

Why it's hard: data is created in context

The practical reason single source of truth is so elusive is that data is created in context, and context is messy. The warehouse team counts stock differently from the finance team. Finance reports units shipped; warehouse reports units physically present; procurement tracks units on order. All three numbers are "inventory" but none of them agree, and all of them are technically correct for their own purpose.

The historical solution was reconciliation — the monthly or quarterly process of comparing numbers across systems, finding discrepancies, and manually resolving them. Reconciliation is a symptom, not a solution. Every hour spent reconciling is an hour spent compensating for a system design problem. It also produces truth with a lag: by the time the numbers agree, they're already out of date.

Every hour spent reconciling is an hour spent compensating for a system design problem. The goal is to make reconciliation unnecessary — not faster.

The difference between sync and truth

The most common mistake when implementing a "single source of truth" is confusing synchronisation with truth. Synchronisation means copying data from one system to another on a schedule — the ERP pushes inventory counts to the reporting dashboard every hour, or every night. This is better than manual reconciliation, but it still produces multiple copies of the data, and the copies are only accurate as of the last sync. In a fast-moving operation, an hour-old inventory count isn't truth — it's a recent estimate.

True single source of truth means the reporting dashboard doesn't have its own copy of the inventory count — it reads the live number from the one place where inventory is recorded in real time. The write happens once; every read everywhere returns the same current value. There is no sync job, because there are no copies to sync.

How modern ERP gets there

A well-designed ERP system achieves single source of truth through two mechanisms. First, it establishes write authority: each data entity has exactly one module that is responsible for creating and updating it. Inventory is written by the warehouse module. Payroll is written by the HR module. Customer records are written by the CRM module. No other module writes to these entities — they only read. This eliminates the problem of concurrent, conflicting writes from different sources.

Second, it uses a unified data layer: all modules share the same underlying database and read live from it, rather than maintaining local caches or calling an integration layer that introduces lag. When the warehouse records a shipment, finance sees the updated inventory count immediately — not after a sync, not after a report runs. The same number, at the same time, everywhere.

The practical signs you don't have one

If your team regularly asks "which number do we use?" before a meeting, you don't have a single source of truth. If different departments send different figures for the same metric in the same week, you don't have one. If your month-end process involves reconciling anything — comparing two systems' records and resolving differences — you don't have one. And if any of your critical business numbers exist only in a spreadsheet, you have the opposite of one: you have as many sources of truth as there are people who edit that spreadsheet.

Achieving it requires more than buying software — it requires redesigning the data ownership model of the organisation and then building a system that enforces it. That's harder than most vendors acknowledge in their sales process. But it's the actual work, and it's what makes the difference between an ERP that transforms an operation and one that adds a new layer of complexity on top of the old one.

More from the blog

All articles →
ERP
ERP · 6 min

5 signs you've outgrown spreadsheets

How to tell when manual workflows are quietly costing you.

AI
AI & Automation · 7 min

Where AI automation actually pays off

A practical guide to the automations that return real time and money.

Browse all posts
Browse · All posts

More from the Cognovat blog

Practical writing on AI, ERP and product engineering.

Ready to build your single source of truth?

Explore ERP development