Single Source of Truth: How to Build One for Finance

A single source of truth is an agreed place and an agreed definition for each important number, so that when two people ask the same question they get the same answer. This guide is part of business analytics for finance and operations, follows data quality and data warehouses for finance teams, and leads to data governance basics and ETL vs. ELT. It does not mean one giant system that holds everything. Most companies run several systems, each correct for its own purpose, and the trouble starts when they report different figures for what appears to be the same thing: revenue, inventory value, headcount, customer count. Finance leaders spend meetings reconciling versions instead of deciding what to do. Building a single source of truth means choosing, for each data domain, which system is the system of record, defining each measure once, moving the data to a place where it can be combined and reconciled, and governing change. This guide explains what the term means in practice, works through an inventory reconciliation example with checked arithmetic, sets out a step-by-step approach, covers the organizational side and lists common pitfalls. Trusted numbers are the foundation of budgeting and forecasting.

What it is and what it is not

A single source of truth (sometimes called SSOT) is a set of authoritative, governed data and definitions. For a given fact, such as the revenue recognized in March, there is one official value, one official definition and one traceable path from the source transaction to the reported figure. It is not a single database for the whole company, nor a promise that every system will show the same number at every moment. Operational systems will always hold data that differs temporarily from the ledger, because of timing. The aim is that the differences are known, explained and bridged, and that everyone uses the same governed figure for decisions.

It is also not a technology purchase. A warehouse, a semantic layer or a master data tool can support it, but without agreed definitions and owners the same tool produces more conflicting numbers, faster.

Why numbers disagree

Four causes account for most disagreements.

1. Different definitions. Bookings, invoiced sales and net revenue are all "revenue" to someone. Active customer might mean bought in 12 months to one team and bought in 24 months to another.
2. Different sources. Two reports pull from different systems, extracts or dates.
3. Different timing. One report is as of midnight and another at month-end close, and late adjustments differ.
4. Different logic. One analyst excludes internal orders and another does not. One nets returns and another does not.

A single source of truth tackles all four by fixing the definitions, the source, the timing rules and the logic in one governed place.

A worked reconciliation: inventory value

A company has three inventory figures at month-end (hypothetical): the general ledger shows $2,290,000, the ERP inventory subledger shows $2,310,000, and the warehouse management system (WMS) shows $2,270,000. Each is "right" in its own system. The job is to bridge them.

• Ledger versus ERP subledger. The difference is 2,310,000 - 2,290,000 = $20,000. Investigation finds $20,000 of purchase price variance entries that have been recorded in the subledger and not yet posted to the ledger. After posting, the two agree.
• ERP versus WMS. The difference is 2,310,000 - 2,270,000 = $40,000. The ERP counts goods in transit between sites at the moment of shipment, which is $55,000 of stock not yet received by the WMS. The WMS also holds $15,000 of cycle count write-downs that haven't synced to the ERP. So the bridge is 55,000 - 15,000 = $40,000. Check: the WMS plus in-transit stock minus unsynced adjustments equals 2,270,000 + 55,000 - 15,000 = 2,310,000, which matches the ERP.

Once bridged, the company designates the ledger as the system of record for inventory value in financial reporting, the WMS as the system of record for physical quantity by location, and the ERP as the record for in-transit status. It publishes a monthly bridge showing the reconciling items. The bridge is the single source of truth in action: three systems, each authoritative for its purpose, joined by explained differences. Without the bridge, a planner quoting the WMS figure and a controller quoting the ledger figure could argue for an hour about a $20,000 gap that is purely timing.

Step 1: Choose the domains that matter

List the data domains that drive decisions: customers, products, suppliers, prices, sales, inventory, general ledger, headcount. Rank them by how often they cause disputes and how much they matter. Start with three to five. Revenue, inventory and customers are common first picks.

Step 2: Name the system of record for each domain

For every domain, state which system is authoritative and for what. A table helps.

If two systems claim the same role, resolve it. If the answer is "it depends," split the domain into the parts for which each system is authoritative.

Step 3: Define each measure once

Write a definition for each key measure: name, plain-language meaning, formula, source tables and fields, inclusions and exclusions, time basis, owner and date last reviewed. Revenue, for example: "Net revenue is invoiced sales less returns, discounts and rebates, recognized when the invoice is posted, excluding intercompany sales." Keep these in a shared data dictionary that everyone can find. Hold a short review with sales, operations and finance, and settle disagreements by deciding which measure answers which question. It is acceptable to have several revenue measures with different names, as long as each is defined and labeled.

Step 4: Bring the data together

Combine the data in one place where the definitions can be applied once. This might be a data warehouse, a governed dataset in a BI tool or, for a small company, a clean set of tables fed by Power Query. The important feature is that reports draw from this layer, and not from ad hoc extracts. See data warehouses for finance teams. Apply the definitions in a semantic layer or in the model, so that "net revenue" is calculated by one formula, in one place, however it is displayed.

Step 5: Reconcile and publish the bridge

For each critical total, build an automated reconciliation to the system of record, with a tolerance and a list of known reconciling items. Show the status on the dashboard. When reconciliation fails, the data is flagged and not silently published. Keep a log of breaks and their causes. Over time the log will show where processes need fixing.

Step 6: Assign ownership

Each domain needs a business owner, accountable for quality and definitions, and a steward who maintains them day to day. The finance owner of the revenue definition should be named. Establish a small governance group that meets monthly to approve changes to definitions and resolve disputes. See data governance basics.

Step 7: Control change

Definitions change as the business does: a new product line, an acquisition, a change in revenue policy. Make changes through a simple process: propose, assess the effect on reports, approve, communicate and restate history where needed. Version the definitions and keep the previous ones. When a number changes because of a definition, say so in the report.

Step 8: Retire the competing sources

A single source of truth fails if the old spreadsheets and reports are still alive. Once the governed reports are reliable, retire the alternatives: archive them, redirect users and stop maintaining them. Announce the date. If a team insists on a parallel report, require it to reconcile to the governed one, and label it as unofficial.

Cultural and organizational points

The hardest part is not technical. Teams that have maintained their own numbers feel that the central version takes away control. Involve them in the definitions. Show them how the governed data saves their time. Acknowledge when the central number is wrong, and fix it quickly, because trust is earned by responsiveness. Executive support matters: if leaders keep accepting competing numbers in meetings, the old habits survive. A simple rule helps: any number presented to the leadership team must state its source and definition.

Signs it is working

1. Meetings start with decisions and not with reconciling numbers.
2. Month-end close needs fewer manual adjustments to reports.
3. Analysts spend less time searching for data and arguing about versions.
4. New reports reuse existing definitions.
5. People can answer "Where does that number come from?" within minutes.

Common pitfalls

1. Treating it as a tool project with no definitions or owners.
2. Trying to cover everything at once.
3. Ignoring timing differences and calling every gap an error.
4. No reconciliation, so trust cannot be shown.
5. Letting parallel reports persist.
6. Changing definitions silently.
7. No executive sponsor.

FAQs

What is a single source of truth?

An agreed system and definition for each important number, so that everyone who asks the same question gets the same answer.

Does it mean one database?

No. It means governed data and definitions, with a known system of record for each domain and explained differences between systems.

How do I start?

Pick three to five domains that cause the most disputes, name the system of record for each, define the key measures and reconcile them.

How do I handle timing differences?

Document them as known reconciling items in a bridge, so that differences are explained and not mistaken for errors.

Who owns the definitions?

A named business owner for each domain, supported by a data steward and a governance group.