What "Single Source of Truth" Actually Means (And Why Most ERPs Don't Have One)

Every ERP vendor claims to be your single source of truth. Most of them mean: “our system is the one you should trust most.” That’s authority by convention, not by architecture. There’s a meaningful difference between a system that claims to be authoritative and one that is structurally incapable of being wrong — and the difference matters every time the books need to close.

“Single source of truth” has become one of the most overused phrases in enterprise software marketing. Type it into any ERP vendor’s homepage and you’ll find it within two scrolls. The implication is that adopting the vendor’s platform will produce a unified, reliable, canonical record of your business data — eliminating the confusion and errors that come from managing information across disconnected systems.

What the phrase almost never means, in practice, is what it says.

What vendors mean vs. what they should mean

When most ERP vendors describe themselves as a single source of truth, they’re making a claim about scope: their system covers enough of your business operations that you could, theoretically, treat it as the authoritative record for most purposes. The GL is in there. The AR is in there. The AP is in there. If you want to know your AR balance, you look in the system. That’s the single source.

The problem is that this model of authority depends entirely on the system having received accurate inputs from all the places that generate financial data. If the billing system sends an invoice to the ERP, the ERP records it. If the sync fails, the ERP doesn’t know it missed something. The ERP is the single source of truth about what was reported to it. It has no way to be the single source of truth about what actually happened, because it didn’t witness what actually happened — it received a report.

Authoritative by convention vs. authoritative by architecture

There are two fundamentally different ways a system can be the single source of truth.

The first is authority by convention: the organization has agreed that this system is what everyone uses to look up financial data, and there are processes in place to ensure the data gets there accurately. This is the model most ERPs represent. It works when the processes work. It fails when they don’t, and the failure may be invisible.

The second is authority by architecture: the system is structurally positioned so that financial events must pass through it to exist. No external system can create a financial reality that isn’t recorded here, because there’s no path to create that reality that bypasses this system. The authority isn’t a convention that can be broken; it’s a constraint that can’t be.

The distinction is not academic. A system that is authoritative by convention has a surface area of failure proportional to the reliability of all the processes that feed it. A system that is authoritative by architecture has a surface area limited to what can be created within it — which means the failure modes are bounded and knowable.

The data quality dimension

Beyond the architectural question is a data quality question: even when a record makes it to the GL correctly, does it carry the information needed to be truly authoritative?

A journal entry that records $10,000 in software subscription expense is a fact. But is it the right account? The right cost center? The right project code? The right period? In many ERP systems, these attributes are optional or enforced only by the UI — meaning a record can make it into the GL missing the dimensional data that makes it useful for reporting. The number is right; the context is absent.

A genuine single source of truth enforces completeness at the same layer it enforces accuracy. Not “the amount must be present” but “the amount, the account, the segment, the period, and the entity must all be present and valid before this record can exist.” The authority extends to the quality of the data, not just its existence.¹

The practical test

Here’s a practical test for whether a system is actually a single source of truth: can you produce the same number two different ways and be certain they’ll agree?

Pull the AR balance from the GL. Pull the AR balance from the AR module. If those two numbers will always be equal — not because you’ve recently reconciled them, but because they’re definitionally the same data — then you have a single source of truth. If they could theoretically differ, even if they rarely do, then you have a system that aspires to be the single source of truth and a process that tries to keep it accurate. Those are meaningfully different things.

Sources