Single Source of Truth

There was a stretch when one meeting could receive three numbers carrying the same name. Grace asked for last month's revenue, and Sofia gave $92,000 from the sales tool, Mia gave $88,000 from the analytics tool, and the payment processor's settlement statement said $91,000.

None of the three was wrong, and nobody had fabricated anything — each number came out of a system built to be trusted. The counting rules simply differed. The sales tool books an amount in the month the contract closes; the analytics tool books it in the month the charge is authorized. Whether refunds come out of the month they were processed or the month of the original charge, whether tax is included, whether a year paid up front gets spread across twelve months — every one of those had been decided differently.

So the meeting turned into reconciliation instead of a decision. Half an hour went into arguing which number was right and ended with an agreement to compare everyone's sources next time, and the judgment they had gathered to make slipped a week.

Single source of truth solves this by arrangement rather than by verification. Instead of relitigating which value is correct, one place is designated as authoritative for that value and everything else reads from there. Revenue arrives in the meeting as one number, and when that one is wrong there is one place to fix it.

Two rules make it hold. The formula is written in exactly one place, and every view that displays the value reads that result rather than recounting from raw records.

Three positions need separating: the source systems where values originate, the middle layer where formulas live and results are stored, and the screens people look at. What gets reduced to one is the middle. Sources will always be plural and screens should be plural, but the formula for revenue has to be singular. The usual home for that middle layer is a data warehouse — a store holding analytical data in an organized structure.

Standing it up takes four steps.

1. Give each metric one owner. The authority to change its definition and the responsibility to announce changes both attach to that person. With no named owner, definitions drift by accretion and nobody notices.
2. Write the formula once as a query or as code and give it a name. Which charges land in which month lives inside that name. Written out in prose, the same content is the metric definition.
3. Have every view read that name. Nobody sums raw payment records while building a report. The moment this rule breaks, a second number exists.
4. Announce the blast radius before changing anything. There has to be a list of which screens and reports consume the value.

Skip step 4 and the old confusion returns even with a single source in place, because changing a definition changes past values too. Decide to exclude internal staff accounts from active users and last month drops from 40,000 to 38,000. Leave that unannounced and somebody reports at the next meeting that growth has stalled. So a definition change gets recorded with its date, its reason, and the before and after values in the same document.

This isn't a principle about numbers only. It attaches anywhere a company refers to the same value repeatedly, and the places split into four.

The first is metrics. Revenue, active users, retention — values several teams call by the same name.

The second is customer information. When one company's employee count is recorded differently in the sales tool, the billing system, and the support tool, and no one has declared which is authoritative, analysis by customer size gives a different answer in each tool.

The third is documents: price lists, refund policy, product decisions. When decisions are scattered across chat threads, nobody can tell two months later which version is final. One document is designated, and decisions made in conversation get copied into it.

The fourth is configuration values. If the document limit on the free plan is hard-coded in the server, in the front end, and in the help article, raising the limit will miss one of them. The number belongs in one place with the other three reading it from there.

"Where do I look for that?" is the practical test. If the answer names two places, that value has no source. Copies can't be eliminated entirely, though — some exist for speed, precomputed ahead of time, and some exist because of access restrictions. What matters isn't removing the copies but nailing down which one is authoritative.

"Where did this number come from? Is it the revenue model in the warehouse?"

Several values can share a name, so the question establishes which source produced this one.

"The document is authoritative for pricing. The number on that slide is last month's."

Where the same information lives in two places, one of them has already been declared the one to follow.

"Changing the active user definition changes last quarter's numbers too. Please record the date and the before and after values."

A definition change reaches back into historical data, so a written record is what prevents confusion.

At Pagedeck the principle took hold after the meeting with three revenue numbers in it. Mia wrote the formulas for twelve metrics into the warehouse exactly once and pointed the dashboards and the investor reporting deck at those values. The contract amounts Sofia watches in the sales tool stayed where they were, with a note in the document saying that number tracks deal progress and is not company revenue. The revenue Grace asks for is now one number.

The most common misreading is that this means consolidating data into one place to store it. The word source suggests a storage migration. But what actually becomes singular is the authority, not the location. Payment records sitting in the processor, the warehouse, and a backup is not a problem; having no declared authority for revenue among them is. The question worth settling is which record wins when two of them disagree. Understood as storage consolidation, the work becomes a six-month migration that ends with every team still running its own formula.

The other frequent belief is that adopting a tool solves it. Bringing in an analytics platform or a data catalog looks like it will create an authority inside itself. But a tool doesn't decide who owns a definition or who may change it. Install one without agreeing on how revenue is computed and three models named revenue appear inside that same tool. The order runs the other way: settle the owner and the definition first, and use the tool as the container for them.