The most overused phrase in finance
"Single source of truth" has been said in more finance and IT meetings than almost any phrase in the last decade. Every data vendor promises one. Every transformation project is justified by one. Every CFO has, at some point, been told that the conflicting numbers problem is about to be solved because the company is finally going to have one.
And yet the meeting where two leaders quote two different ARR figures keeps happening. Often at companies that have spent seven figures on data infrastructure.
That's worth sitting with. If the phrase described something real and achievable, the problem would be rarer by now. Instead, "single source of truth" has drifted into meaning roughly "all our data in one place" — which is a genuine technical accomplishment and, on its own, does almost nothing to make finance's numbers agree.
This piece is about the gap between those two things. What a single source of truth actually requires for FP&A, why centralized data doesn't produce one by itself, and how to think about the difference between the systems that record what happened and the layer that lets executives decide what to do about it.
Why a data warehouse alone doesn't get you there
Start with what a warehouse does well, because this isn't an argument against them. A warehouse consolidates data from many systems into one queryable place. It handles scale, history, and joins that would break a spreadsheet. It gives analysts a foundation to work from instead of a pile of CSV exports. Most finance organizations at growth stage should have one, and the ones that do are better off for it.
Here's the limit. A warehouse centralizes data. It does not adjudicate meaning.
Load billing, CRM, and general ledger data into the same warehouse and you now have three ARR-adjacent datasets in one location. They still disagree. The CRM counts a deal from close date; billing counts it from activation; the GL doesn't recognize it as revenue for months. Nothing about co-locating those tables reconciles them. It just means the conflicting numbers are now conflicting in the same database.
Then the second problem: a warehouse is queried. Two analysts write two queries against the same tables with slightly different filters, and produce two ARR numbers — both technically sourced from "the single source of truth." Centralization without agreed definitions doesn't reduce discrepancies; it can multiply them, because now everyone has access and everyone can build their own version.
Third, warehouses are typically optimized for storage and analysis, not for the specific requirements of financial reporting: period-based cut-offs, revenue recognition treatment, reconciliation to the ledger, stable finalized figures. Those are financial disciplines, not data-engineering ones.
So the warehouse is necessary infrastructure for many teams and insufficient as a source of truth. Something has to sit on top of it and decide what the numbers mean.
Systems of record vs. systems of decision
The clearest way to think about this is to separate two categories of system that get lumped together.
Systems of record
These are the authoritative operational sources. The ERP and general ledger. The CRM. The billing platform. The HRIS and payroll system.
Each one is the definitive record for its own domain. The GL is the authority on what was posted. The billing system is the authority on what was invoiced and collected. The CRM is the authority on what was sold and when it closed. The HRIS is the authority on who works here and at what cost.
These systems should not be replaced, worked around, or second-guessed. They are the transactional truth of the business, they carry the audit trail, and your auditors, your regulators, and your operational teams depend on them. Any approach to financial reporting that undermines them is solving the wrong problem.
But notice what systems of record are built to do: capture transactions accurately within their own domain. They are not built to answer cross-domain questions. Your GL cannot tell you net revenue retention. Your CRM cannot tell you deferred revenue. Your billing system cannot tell you what headcount cost is doing to gross margin. Each holds a piece.
Systems of decision
A system of decision is the layer where those pieces get validated, reconciled, standardized, and explained — so leadership can act on them.
Its job is different in kind. It doesn't originate transactions. It takes what the systems of record hold and produces a coherent, defensible operating picture: the ARR waterfall, NRR and GRR, deferred revenue, recognized revenue, cash, headcount as a driver. Figures that don't live natively in any single source system because they're derived across several.
The distinction matters because most "single source of truth" projects are aimed at systems of record — consolidating data — when the actual pain is at the decision layer. Finance doesn't struggle because the data isn't accessible. It struggles because nobody has authoritatively answered which definition, which cut-off, and which reconciliation produces the number the board sees.
Why conflicting numbers survive heavy data investment
Given how much gets spent on data infrastructure, why does the "which number is correct?" moment persist?
Definitions were never agreed. This is the largest single cause and the least technical. Sales counts ARR at close. Finance counts it at activation. Neither is wrong; they were never reconciled to one policy. No amount of pipeline engineering fixes a definitional disagreement — you can build a flawless pipeline to the wrong definition.
Derived metrics live outside the pipeline. Even with clean centralized data, the ARR waterfall and retention metrics usually get assembled in a spreadsheet at period end. That assembly step — the one that actually produces the board numbers — often sits entirely outside the governed infrastructure.
Access without governance. Modern data stacks are good at giving teams self-serve access. That's valuable, and it means multiple teams can produce credible-looking versions of the same metric from the same tables. Without an agreed calculation, self-serve becomes self-conflicting.
Reconciliation isn't automatic. Getting billing, CRM, and GL data into one place doesn't tie them to each other. Someone still has to match customer records, handle the IDs that don't align, and explain why the three views differ. If that work happens manually each period, it varies each period.
Timing differences get flattened. Warehouses tend to reflect current state. Financial reporting depends on as-of-date logic and period cut-offs. A number pulled Tuesday and the same number pulled Thursday will differ for entirely legitimate reasons — and look like an error to anyone comparing two decks.
The pattern: infrastructure solves data movement. Conflicting numbers are a governance problem, and governance doesn't come in the box.
What a real decision layer requires
If the decision layer is where trust is won or lost, it needs specific properties.
Consistent metric definitions. One written definition per headline metric, agreed across finance, sales, and RevOps, applied everywhere. This is organizational work before it's technical work, and skipping it guarantees the conflict returns.
Deterministic calculations. The same inputs produce the same outputs, every time. Run a period twice, get an identical result. Determinism is what makes period-over-period comparison meaningful and what makes a number defensible when a director asks how it was computed.
Traceable outputs. Every figure drills back to source. If ending ARR is $14M, you can see the movements that built it, and each movement ties to specific customer records in the source systems. Lineage is what turns "let me get back to you" into an answer in the room.
Governed reporting. Numbers are finalized through a controlled process, and once finalized for a period, they hold. A report that changes after distribution teaches the board that finance's numbers are provisional — an expensive lesson to unteach.
Financial governance, concretely
Those properties rest on three disciplines that are worth naming plainly.
Validation is checking data before it's used: completeness, period alignment, whether the pieces are internally consistent. Catching that a billing export is missing three days before it feeds the board pack.
Reconciliation is proving the sources agree, or explaining precisely why they don't. ARR to billing to the ledger. Where differences are structural — timing, scope, recognition rules — reconciliation documents the bridge rather than pretending it away.
Controlled reporting is the process discipline: who can change what, when figures are finalized, how adjustments are recorded, and how corrections are handled after the fact.
None of this is exotic. It's the same control thinking that governs the close, applied to the derived metrics that increasingly drive board decisions but often sit outside the close's formal controls.
The goal isn't replacement — it's confidence
Worth being explicit, because "single source of truth" projects often become empire-building exercises.
The goal is not to replace your ERP, CRM, HRIS, or billing platform. Those systems should keep doing exactly what they do. Your GL stays your GL, owned by your team and your auditors. Your CRM stays the sales team's operational tool. Your warehouse stays your data foundation.
The goal is confidence in the numbers leadership uses to run the business. That's a narrower objective and a more achievable one. It doesn't require rebuilding your stack. It requires a governed layer above it where the derived financial picture gets assembled consistently, traced to source, and finalized under control.
Put differently: the single source of truth for transactions is your systems of record, and it already exists. What most finance teams are missing is a single source of truth for decisions — and that's a layer, not a database.
Where SMPL.ai fits
SMPL.ai is built to be that decision layer, and it's worth being precise about the boundary.
SMPL reads and reconciles information from your source systems — billing, CRM, and the general ledger — into one governed operating model, then computes the SaaS metrics leadership needs from that single reconciled base: the ARR waterfall, NRR and GRR, deferred revenue, recognized revenue, cash, headcount as a driver. Because they come from one reconciled foundation, they tie to each other rather than to five separate exports.
SMPL never writes back to your ERP or general ledger. It reads from your systems of record; it does not post transactions to them. Your books stay yours. That boundary is deliberate — the system of record and the system of decision do different jobs, and blurring them is how you end up with neither.
Calculations are deterministic and every figure carries its lineage back to source, so a headline number can be walked to the contracts underneath while the question is still being asked.
And AI plays a defined, limited role: it interprets validated financial outputs and provides executive context rather than generating financial numbers. The narrative explains movements the engine actually computed, grounded in the same reconciled source as the rest of the pack. The numbers come from deterministic calculation on reconciled data. AI puts them into language a board can read — and nothing more than that.
Assessing your own reporting architecture
Practical questions to work through with your team:
- Can you name the authoritative source for each headline metric? Not the system it's stored in — the definition and calculation that make it official. If two answers exist, that's your conflict.
- Are your metric definitions written down and agreed across teams? Get finance, sales, and RevOps in one document. Most "data problems" resolve here.
- Where do your derived metrics actually get calculated? If the ARR waterfall is assembled in a spreadsheet at period end, that step is outside your governed infrastructure regardless of how good the warehouse is.
- Can you trace any board number to source in under a minute? Test it on last quarter's pack. Where you can't, that's where your risk concentrates.
- Does the same period reproduce the same numbers? If a figure moves between runs with no input change, find out why before it reaches a board.
- What happens to a report after it's distributed? If figures can still shift, you don't have controlled reporting — you have a draft with a cover page.
- Where does AI touch your numbers? Interpreting validated outputs is useful. Generating figures that can't be traced is a liability. Know which you have.
You can act on most of these without buying anything. The definitional work in particular is free, and it's usually the highest-leverage item on the list.
See it on your own numbers
The honest test of a decision layer is whether your ARR, revenue, and cash reconcile to one governed foundation and trace back to the contracts underneath — fast enough to answer a director in the room.
Book a demo and we'll walk that on data that looks like yours.