Every SME has had the meeting where two numbers disagree. Sales is reporting £412,000 for the month. Finance is reporting £398,000. The numbers are close enough that nobody's obviously wrong, and different enough that somebody must be. Twenty minutes go on a debate about the source. No decision gets made. Everyone leaves slightly less trustful of reporting than when they came in.
The temptation is to treat this as a data-quality problem. It almost never is. In nine SMEs out of ten, the underlying data is fine. The issue is that "revenue" means one thing in the sales team's spreadsheet and something slightly different in the finance pack — and nobody has ever sat down, written the difference down, and made a decision about which one the business uses.
That's a single-source-of-truth problem. It's solvable. And it doesn't require a data warehouse, a data engineer, or a six-figure platform to solve.
What Enterprise BI Got Wrong
"Single source of truth" has been a BI buzzword for two decades. In most enterprise deployments, it means a governed data warehouse — one canonical store where every business metric is computed, blessed, and distributed. It's a real discipline. It's also, for most SMEs, wildly over-engineered.
The enterprise version of SSOT is a platform problem: pipelines, ETL, master data management, an entire function of people whose job it is to curate the canonical layer. The SME version is a definition problem — and a definition problem doesn't need a platform. It needs a document, a decision, and a discipline. This is the exact trap enterprise BI has pulled small businesses into for twenty years: selling the platform when the problem was the definitions.
What SSOT Actually Means at SME Scale
For an SME, single source of truth means something much simpler than the enterprise version. It means:
- One agreed definition for every metric that shows up in more than one place.
- One agreed source where the canonical version of that metric is computed.
- One agreed owner who is responsible for the definition when it needs updating.
That's the whole discipline. No warehouse, no stack, no ETL vendor. Three columns in a document. And the document itself becomes the source of truth — not a system.
In most SMEs, the data isn't inconsistent. The definitions are. Fix the definitions and the data stops arguing with itself.
The Four Terms to Nail First
You don't need to build a full data dictionary on day one. You need to nail four terms — and four terms is usually 80% of the argument. The rest is marginal.
1Revenue
Is it gross or net? Is it invoiced or paid? Is it booked (order date) or recognised (service delivered)? Are refunds and credits netted in the period of the original sale or in the period they're issued? Does it include shipping, discounts, or taxes?
Pick one answer to each. Write it down. Every dashboard that reports revenue uses the same answer. If a specific context needs a different version (e.g. cash-recognised revenue for treasury forecasting), give it a different name and define it separately.
2Customer
Is a customer someone who's ever bought, or someone who's bought in the last N months? Is a customer a company or a contact? If the same customer has three subscriptions and two one-off orders, are they one customer or five customer-events?
Most SMEs discover they've been conflating three things: a prospect (talked to sales), an account (the company record in the CRM), and an active customer (purchased in a defined recent window). Give each its own name. Different contexts use different ones — but the names are unambiguous.
3Margin
Gross? Net? Contribution? Which costs are in and which are out? Does "direct cost" include payment-processing fees, fulfilment, warranty reserves, platform commissions? Is staff time allocated per sale or treated as a fixed overhead?
The answer depends on what decision the margin number is driving. You're allowed more than one margin metric — but each one needs a name, a definition, and an owner. "Margin" by itself, used interchangeably across three contexts, is where arguments live.
4Active
For any usage-driven business (SaaS, subscription, membership, service retainers), "active" is the single most abused word. Does active mean logged in this month? Opened the product this month? Has a live paid subscription regardless of usage? Has usage above a threshold?
Pick the definition that ties to a decision you actually make. If you'd take action when "active users" drops, define "active" by whatever measurement would make that action make sense. If you wouldn't take action either way, "active" isn't serving a purpose and doesn't need to be in the dictionary yet.
Those four — revenue, customer, margin, active — will cover the majority of definitional arguments in a typical SME. Add a fifth and sixth if you operate in a domain where a specific term (bookings, pipeline, utilisation, occupancy) carries the business. But don't add dozens. A data dictionary with fifty entries that nobody reads is another report nobody reads.
How to Enforce It (The One-Page SSOT Protocol)
Writing definitions is the easy part. Enforcing them is where most SMEs drop the ball. Here's the minimum discipline that makes the dictionary stick:
- One page, one location. Whatever tool you use (Notion, a Google Doc, a pinned README in your repo), it lives in exactly one place. No copies. No forks. No "slightly updated versions." If it's anywhere else, it's not the dictionary.
- Every dashboard references a definition. Every KPI on every live dashboard carries a reference — even if it's a single-letter footnote — pointing back to the definition in the dictionary. If a metric appears on a dashboard and doesn't have a definition, one of the two is wrong.
- One named owner per definition. If revenue's definition needs to change, one named person decides. They consult whoever they need to consult; the decision is theirs. Governance by committee is how definitions get diluted until they stop meaning anything.
- A change log. Every time a definition changes, the change is logged with a date and a reason. This sounds bureaucratic. It's not — it's what lets you trust the dictionary six months later.
- Quarterly review. Once a quarter, the owner of the dictionary runs a fifteen-minute review: are the definitions still serving the decisions they were built for? Anything obsolete gets removed. Anything ambiguous gets sharpened.
This is the same discipline enterprise teams call "data governance." For an SME, it fits on one page and takes fifteen minutes a quarter. That's the whole thing.
Where SSOT Fits in the Method
Single-source-of-truth discipline lives primarily in the Foundation stage of the BIP Method™ — the stage where you build the ten reports that matter. You can't build reliable reports on ambiguous definitions, so the data dictionary is the first artefact of Foundation, not an afterthought of it.
It also underpins the Rhythm stage. The four-part decision loop (metric, threshold, conversation, action) depends on everyone meaning the same thing by "the metric." If two people in the conversation are working from different definitions, the loop collapses before it reaches the action stage. SSOT is what keeps the loop closed.
When SSOT Is Overkill
Not every metric deserves a dictionary entry. If a number is used in exactly one place, by exactly one person, for exactly one decision, you don't need to formalise it. The dictionary exists to prevent arguments. No argument, no need.
A useful rule of thumb: if a metric is produced by one team and consumed by another, it needs a dictionary entry. If it lives inside a single team's workflow, it doesn't. The test is cross-boundary use, not importance.
Start with the four terms above. Add entries only when a new argument surfaces — because an argument surfacing is the signal that a definition is missing. Don't pre-build a dictionary of fifty entries in anticipation of conflicts that haven't happened. That's enterprise overhead dropped into an SME. It fails for the same reason enterprise dashboards fail: it optimises for completeness instead of use.
A one-page dictionary, four terms nailed, one owner, a change log, a quarterly review. That's single source of truth at SME scale. No warehouse required.