A single source of truth people actually use

The phrase names a project, not an outcome

When someone says they want a single source of truth, they are describing a feeling: they want the argument to stop. When a vendor says they will build one, they are describing a system: a warehouse, a modeling layer, a set of dashboards. Those two things are not the same, and the gap between them is where the money goes. You can finish the system perfectly and still have the argument every month, because the argument was never about where the data was stored.

We get called into this at two moments. The first is before anything is built, when a founder or an operations lead has three quotes and cannot tell what separates them. The second is eighteen months later, when the platform exists, the bill arrives monthly, and the leadership deck is still assembled by hand from a workbook on somebody's laptop. The second call is more common, and the diagnosis is nearly always the same. The technology worked. Nobody moved.

This piece is about the part that decides adoption. It is deliberately not about which warehouse to buy. That choice matters far less than sales conversations suggest, and we say so in what a data warehouse costs at your size.

The private spreadsheet is the scoreboard

There is one measurement that tells you whether the project worked, and it costs nothing to take. Ask each leader to show you the file they open before a meeting that matters. If it is the platform, you have a source of truth. If it is a spreadsheet they maintain themselves, you have an expensive second opinion.

People are not being difficult when they keep the private copy. They are managing risk. A leader who has to defend a number in front of a board will use the version she can explain line by line, and she will keep using it until the new one is at least as defensible. That is a rational trade, and no amount of change management argues someone out of it. You have to make the shared number more defensible than the private one. Everything below is a way of doing that.

Four reasons the private copy survives

The definition does not match how the business thinks. The platform reports bookings on signature date. The sales leader has run her plan on the date the first invoice goes out for eleven years. Neither is wrong. But if nobody wrote down which one the company uses, the platform quietly picked one and she noticed within a day.

Nobody can say how old the number is. A figure with no timestamp cannot be trusted for a decision, so people re-derive it. A dashboard that says nothing about its own freshness invites everyone to check, and checking means opening the source system, and once you are in the source system you may as well build the number yourself.

There is no way to handle the exception. Real businesses have a customer that was invoiced twice by mistake in March, a contract that was signed but should not count until the option is exercised, and a refund that has to be attributed to the original month. Spreadsheets absorb exceptions in seconds. Systems that cannot absorb them at all lose to spreadsheets that can.

No one owns the number. When a figure looks wrong, there has to be a person to ask, and that person has to be able to answer within a day. When the answer is "we will put in a ticket," the private copy comes back immediately and permanently.

Notice that the last row is the smallest. Tool quality is real and it is rarely the binding constraint. Most companies replace the tool when the problem was the definition, then discover the argument survived the migration.

Start with the arguments, not the architecture

Before anyone chooses a technology, write down the numbers that get argued about. Not every number the business could report — the ones that have caused a disagreement in the last six months. In a company between twenty and three hundred people, that list is almost always somewhere between eight and twenty items, and it is startlingly consistent: revenue by month, pipeline, headcount, churn, gross margin, utilization, a delivery or fulfillment metric, and whatever the industry-specific number is that everybody quotes and nobody defines.

That list is the scope. It is the whole scope for the first release. A platform that answers twelve contested numbers exactly, and nothing else, will be used. A platform that answers four hundred numbers approximately will be checked against a spreadsheet forever.

The definition is the deliverable

For each number on that list, one page. Not a data dictionary generated from column names — a page a new hire could read and then reproduce the figure by hand from the source system. It takes about forty minutes per metric to write and it is the single highest-return hour in the whole project.

What the page states	Why it is there	What it looks like when skipped
Plain-English meaning One sentence, no jargon	Everyone is arguing about the same thing before anyone touches SQL	Two teams both correct, both different
The date that governs Booked, invoiced, paid, recognized	Date choice moves monthly figures by double digits at quarter edges	Numbers that agree annually and never monthly
Inclusions and exclusions Internal accounts, test records, taxes, refunds	This is where most of the difference actually lives	An unexplained gap someone attributes to "the system"
Source of record Which system wins when two disagree	Ends the standoff before it starts	A meeting that stops while two people compare screens
Named owner A person, not a department	Somebody can answer "is this right?" today	A ticket queue, and the private copy returns
Refresh promise How often and by what time	Turns freshness into a commitment that can be measured	People check the source system anyway

Write these before the build, and expect the writing itself to change your answer. In practice, working through eight to twelve definitions surfaces two or three genuine disagreements that had been quietly costing the company real money — a commission plan paying on a basis nobody in finance agreed to, or a renewal counted in a month that made a cohort look healthier than it was. That is not a side effect of the project. Frequently it is the largest thing the project produces.

Publish the freshness on the page

Every view carries the time the underlying data was last updated and the time it was expected. Two timestamps, not one. "Updated 6:12 a.m., expected by 6:30 a.m." tells a reader the number is trustworthy. "Updated 6:12 a.m." on its own tells them nothing, because they do not know whether that is normal.

Then commit to a number and let people hold you to it. A daily refresh that lands before the first meeting of the day is worth more than an hourly refresh that silently skips a run twice a month. Freshness is a promise about the worst case, not a boast about the best one.

Give the exceptions a home

Every business has adjustments, and pretending otherwise is what pushes people back to spreadsheets. Build a small, boring, deliberately visible place for them: a table where an authorized person can record an adjustment with an amount, a reason, a date and their name, and where every adjustment appears in the report as its own line rather than being blended in.

This is the feature most often argued out of scope on cost grounds, and the one that most often decides adoption. It is usually a few days of work. The alternative is that adjustments happen anyway, in a workbook, invisibly, and the platform is wrong the first time an exception occurs. Keep them auditable and keep them few — if a category of adjustment happens every month, it is not an exception, it is a definition you have not written yet.

One name per number

Ownership here means something narrower than governance, which is a word that produces committees. It means one named person per number who answers three questions: is this figure right, what changed when it moved, and who may change the definition. In a company under a few hundred people, that is a line in a shared document, not a data council, and it works better than the council does.

The owner is a business person, not an engineer. Finance owns revenue. The head of sales owns pipeline. Engineering owns the pipe, and is accountable for the pipe running on time, which is a different job. When engineers own definitions, definitions get chosen for convenience of implementation, and the business quietly stops recognizing its own numbers.

What it costs and how long it takes

For a company between twenty and three hundred people with three to six source systems — a CRM, a finance system, an operational database, maybe a support tool and a payroll system — a first release covering ten to fifteen defined metrics is typically six to twelve weeks of one senior engineer, plus roughly two to four hours a week of a business owner's time per metric area. At the rates senior engineers on this work generally command, which run $150 to $250 an hour however they are billed, that lands somewhere around $45,000 to $110,000 for the build.

Running costs are usually the smaller surprise. Cloud storage and query for a business of that size is often $200 to $2,000 a month; the reporting tool is typically $20 to $80 per user per month; the pipeline tooling varies wildly with volume. The larger and less discussed cost is maintenance: budget fifteen to twenty-five percent of the build each year, because source systems change, fields get added, and a vendor will alter an export format without telling you. A platform with no maintenance budget degrades quietly for about nine months and is then declared a failure.

Two things reliably blow up the schedule, and neither is engineering. Access to source systems takes longer than anyone plans — someone has to approve an API key, and that person is busy. And the definitions surface disagreements that need an executive decision, which takes as long as getting the executives in a room. Both are worth naming in the plan so they are not mistaken for the engineer running late.

How you know it worked

Adoption is measurable, and the measures are unglamorous. Six weeks after launch, count how many of the leadership team open the platform before their own file. Count how many of the twelve numbers have a written definition an outsider could follow. Count the days in the last month where the refresh landed on time. Count the questions the owners answered within one business day.

• The board deck is assembled from the platform, not rebuilt beside it
• Every contested number has a one-page definition with a named owner
• Each view shows when it last updated and when it was due
• A failed load produces a visible banner, not a silently stale figure
• Adjustments are recorded in the system, with a reason and a name
• Anyone can get from a headline number to the underlying rows in two clicks
• A definition change has a written trail and a date it took effect

The two-clicks item deserves a note. The fastest way to earn trust in a number is to let a skeptical person see the rows behind it without asking anyone. It converts a doubt into a five-second check. Where a platform hides the rows, every doubt becomes an email, and every email is a small argument for keeping the private copy.

What does not work

• Buying the tool first and discovering the definitional disagreements during user testing
• Publishing four hundred metrics, none of which anyone has agreed to
• A governance committee in a company of eighty people, meeting monthly, deciding nothing
• Naming a department as the owner instead of a person who can be asked today
• Banning spreadsheets, which relocates the private copy rather than removing the reason for it
• Treating export to a spreadsheet as failure — it is how people check you, and checking builds trust
• Shipping without a maintenance budget and calling the resulting decay a platform problem

The last two are worth dwelling on. A source of truth is not a place people are forbidden to leave. It is the place they start. If a controller pulls the detail into a workbook to do a one-off analysis, that is the system working. The failure mode is when she starts producing the headline number there instead of reading it.

A ninety-day sequence that works

Step five is the one that converts skeptics, and it is the one most often skipped for schedule. Do not aim for the two numbers to match. Aim to explain every difference — this one is timing, that one is because your workbook excludes intercompany, this third one is a genuine error in the workbook that has been there since March. When a finance lead watches her own number get taken apart and put back together, she stops maintaining the copy. Nothing else has that effect.

When the honest answer is not to build one

Sometimes the right recommendation is no platform. If the arguments are confined to two numbers, writing the two definitions and agreeing them may be the entire fix, and it costs a week. If the company is about to replace its finance system or its CRM, building on top of the outgoing one buys work you will throw away; wait, and spend the interval writing definitions, which transfer. And if the underlying source data is genuinely bad — duplicate customers, unreliable dates entered by hand — a warehouse will report the mess faster and in higher resolution. That is a data quality project first, and pretending otherwise wastes a year.

Bottom line

A single source of truth is a social artifact with a technical implementation, and almost everyone buys it in the opposite order. Pick the dozen numbers people fight about. Write down what each one means, which date governs it, what it excludes, and whose name is on it. Publish how fresh it is and admit when a load fails. Give exceptions somewhere legitimate to live. Then build the smallest thing that serves those twelve numbers, and reconcile it against the spreadsheets it is meant to replace until every difference has a name. Do that, and the private copies quietly disappear, which is the only evidence that ever matters.

Objections we hear, and what we say back

Frequently asked questions