Skip to content

Designing a single source of truth across operations

Why disagreeing numbers across teams are usually a design problem, not a discipline problem, and how to design a genuine single source of truth.

·10 min read

In a quarterly review, the sales director reported forty-two open deals. The finance director, working from a different export, reported thirty-eight. Both were right, in the narrow sense that both numbers accurately reflected the spreadsheet each of them had open. Neither was right in the sense that mattered, because the business does not have two pipelines — it has one pipeline and two disconnected descriptions of it, updated on different days by different people.

This is the single most common failure we see in growing operations, and it is almost never a discipline problem. Teams are not careless; they are working from data that was never designed to stay consistent in the first place. A single source of truth is not a phrase you achieve by asking people to be more careful with spreadsheets. It is an architectural property of how data is entered, stored, and read, and it either exists by design or it does not exist at all.

Why 'just communicate better' does not fix this

The instinctive response to disagreeing numbers is a process fix: a weekly reconciliation meeting, a shared master spreadsheet, a rule that exports must be dated. These reduce the symptom temporarily and reappear within a quarter, because the underlying cause — the same piece of information being entered or copied in more than one place — has not changed. Every additional copy of a number is another opportunity for it to drift from the original, and no amount of meeting cadence eliminates that opportunity. It only slows down how quickly the drift gets noticed.

The design principle that actually works

  • Enter each piece of information exactly once, at its natural source, by the person closest to it.
  • Let every other system, report, or dashboard read that same record rather than a copy of it.
  • Make the record update status automatically as the underlying workflow progresses, rather than relying on someone to update a separate tracker.
  • Give every team the view of the data relevant to them, drawn from the same underlying record, rather than a separate export.

Applied to the pipeline example above, this means the deal record lives in one place — inside [Sales & CRM](/solutions/sales-crm) — and both the sales director's pipeline view and the finance director's revenue forecast read directly from that same record, filtered differently for their purposes. Neither team maintains a separate copy. When a deal closes, both views update because they were never two views to begin with — they were the same data, presented twice.

Where this breaks down across the business

The same pattern repeats in procurement, where a purchase order approved in one system but tracked in a separate spreadsheet for budget purposes inevitably shows a different total than the finance ledger — a mismatch [Procurement & vendor management](/solutions/procurement-vendor-management) avoids by tying budget tracking to the same order record used for approval, not a parallel copy of it. It repeats in project delivery, where site progress reported to a client and site progress used for internal billing should be the exact same number, sourced the exact same way, which is the design premise behind [Project & workflow management](/solutions/project-workflow-management).

The role of dashboards, and their limits

A common but flawed fix is to build a dashboard that pulls from multiple sources and presents them side by side, hoping visualisation will paper over the inconsistency. It will not — a well-designed dashboard makes disagreement more visible, not less, because now it is on one screen instead of two spreadsheets nobody compares directly. [Management dashboards](/solutions/management-dashboards) are only as trustworthy as the records feeding them; the dashboard is the last step in the design, not the fix for a fragmented one underneath it.

Where AI fits into this, and where it does not

A single source of truth also determines whether AI can be useful at all. An AI system asked to summarise collections status, flag at-risk projects, or draft a procurement escalation is only as reliable as the record it reads from. Fragmented data does not just produce disagreeing dashboards — it produces confidently wrong AI outputs, because the AI has no way to know which of two conflicting numbers is current. This is one of the underappreciated reasons [what an AI-native business system actually means](/insights/what-ai-native-business-system-means) starts with data architecture rather than the AI feature itself; the intelligence layer cannot fix a structural gap underneath it.

Getting there without a disruptive rebuild

Designing a genuine single source of truth does not require replacing every system in the business simultaneously. It requires identifying, process by process, where the same piece of information currently exists in more than one place, and deliberately choosing one system as the record of truth for each — with everything else reading from it rather than duplicating it. This is a design decision as much as a technology one, and it is the first architectural question we work through with any client, outlined further in [how we work](/how-we-work).

The forty-two versus thirty-eight problem never gets solved by a better meeting. It gets solved by making sure there was only ever one number to begin with.

Next step

Reading about the pattern is useful. Seeing it in your own process is decisive.

Map your data sources with us