More data, less clarity
A finance team in 2016 had a general ledger, a CRM, a spreadsheet, and a bank login. A finance team today has access to nearly every fact about the business, updated continuously, across dozens of systems.
By any reasonable expectation, financial reporting should have gotten easier.
It hasn't. Ask most growth-stage CFOs whether producing a board pack is simpler than it was five years ago and the answer is no — it takes longer, involves more people, and requires reconciling more sources. The board asks harder questions and the answers take more work to produce.
That's a strange outcome, and it's worth understanding rather than accepting. More data did not produce more clarity, because the constraint on trusted financial reporting was never data availability. It was coherence: getting many independently correct systems to tell one story that leadership can act on.
This piece is about why that gap widened as software proliferated, why warehouses and integrations don't close it on their own, and how to think about the layer that does.
Every department got its own system
The SaaS explosion was, for each individual team, an unambiguous win.
Sales got a CRM tuned to pipeline management. Finance and accounting got an ERP and general ledger. HR got an HRIS; payroll got its own platform. Billing moved to a subscription management system. Marketing got automation and attribution. Customer success got a health-scoring platform. Product got analytics. Treasury got banking connectivity. Procurement got spend management.
Each of these is genuinely better than what it replaced. Each is authoritative within its own domain — the definitive record of what happened in that function. None should be removed, worked around, or second-guessed.
Here's what nobody planned. Each department optimizes its own system for its own workflow. The CRM is configured for how sales sells. The CS platform is built around how success measures health. The HRIS reflects how HR thinks about people. All reasonable, all locally optimal.
And then finance is handed the job of assembling those independently optimized systems into one coherent picture of business performance.
That's the structural asymmetry. Ten teams each make a locally sensible decision about their own tooling and data model. One team — yours — inherits the integration problem created by all ten. Nobody chose that; it's an emergent property of how software gets adopted. But it means finance carries a cost that no other function sees on its own ledger.
Why adding software adds complexity, not clarity
Each new system arrives promising better visibility into its domain. And it usually delivers that. What it also delivers, less visibly, is a new set of connection problems.
Another version of the same entity. A customer exists in the CRM, the billing platform, the CS tool, and the GL — with four different identifiers and four slightly different naming conventions. Every cross-system question now requires matching them.
Another interpretation of the same event. When did a deal "happen"? The CRM says close date. Billing says activation. The GL says when revenue recognition began. Three systems, three defensible answers, three different numbers.
Another data model to understand. Someone has to know how each system structures its data, what its edge cases are, and where its quirks bite. That knowledge tends to live in one person's head.
Another refresh cadence. Systems update on different schedules. Pull two of them at different times and the same metric legitimately differs.
Another dashboard producing its own numbers. Each platform reports on itself. Now department heads walk into leadership meetings quoting figures from their own tools, which don't tie to finance's.
The math is unforgiving. Adding a system adds one source of data and a connection to every existing system. Complexity grows with connections, not with count. The tenth system doesn't add 10% more integration burden — it adds considerably more.
So finance ends up with more information and less confidence, which is exactly the wrong trade.
What a data warehouse does and doesn't solve
The standard response is a data warehouse, and it's often the right call. A warehouse consolidates data from many systems into one queryable place, handles history and scale, and gives analysts a real foundation instead of a folder of exports. Most companies at this stage should have one, and this isn't an argument against it.
But building and maintaining one surfaces a series of questions that are financial judgments, not technical ones.
What should be stored? Every field from every system is expensive and unusable. A curated subset means someone decides what matters — and that decision is made before anyone knows what the board will ask next quarter.
How often should it refresh? Real-time sounds ideal, but financial reporting depends on period cut-offs, not current state. A continuously refreshing figure is a moving target for a board pack.
How are historical snapshots preserved? This one is underestimated. Operational systems overwrite. When a customer's contract value changes, the CRM shows the new value — the old one is gone. If you didn't snapshot ARR as of quarter-end, you cannot reproduce last quarter's number, only recompute it from today's state and get something different. That's a reproducibility failure that surfaces at the worst possible moment.
What happens when definitions change? You refine how ARR treats ramp deals in Q3. Do prior periods get restated? Are both definitions kept? How does anyone know which applies to a given report? Business definitions evolve; warehouses store data, not the decision history behind it.
Notice that none of these are engineering problems. They're financial policy questions that get resolved implicitly by whoever builds the pipeline, often without finance in the room. The warehouse does its job well. The unanswered questions sit on top of it.
Technology doesn't create a single source of truth
This is the crux. A warehouse centralizes data. It does not adjudicate meaning.
Load billing, CRM, and GL data into the same place and you have three disagreeing views of ARR in one location. Co-locating tables doesn't reconcile them. And now two analysts can write two queries against the same tables, apply slightly different filters, and produce two numbers — both sourced from "the single source of truth."
What actually produces one requires things technology alone doesn't supply:
- Standardized metric definitions — one written, agreed definition per headline metric, applied everywhere.
- Validation — checks that data is complete and internally consistent before it feeds a report.
- Reconciliation — proof that sources agree, or documentation of exactly why they differ.
- Deterministic calculations — the same inputs producing the same outputs, every run.
- Financial governance — ownership, approval before distribution, and figures that stay stable once finalized.
You can build flawless infrastructure on top of two conflicting definitions and get conflicting numbers faster. Integration is necessary. It isn't sufficient.
A framework worth remembering
Here's a simpler way to hold all of this. Three layers, each answering a different question.
Operational Systems → Financial Intelligence → Executive Decisions
Operational systems answer: what happened? Your ERP, CRM, HRIS, billing, payroll, and the rest. They capture transactions accurately within their own domain. They are your systems of record, and they're the right tool for that job.
Financial intelligence answers: can we trust it, how does it connect, and what does it mean? This is where data gets validated, sources get reconciled, definitions get applied consistently, derived metrics get computed, and results get explained. It's the layer that turns ten independently correct systems into one coherent picture.
Executive decisions answer: what should we do next? Hiring plans, pricing, spend, fundraising timing — the decisions leadership makes on what finance reports.
The distinction that matters most is between the first two. Systems of record capture operational transactions. Systems of decision help leadership understand performance and act. They are different jobs, and no system of record can do the second one.
Your GL cannot tell you net revenue retention. Your CRM cannot tell you deferred revenue. Your billing platform cannot tell you what headcount cost is doing to gross margin. These metrics are derived across systems — they live natively in none of them.
Which means the middle layer exists whether or not you've named it. In most companies it's a spreadsheet, assembled at period end by one or two people, holding the entire financial intelligence function in ungoverned form. That's not a criticism of the people doing it. It's an observation that the most consequential layer in the stack is usually the least governed.
Why confidence erodes even when the data is correct
Worth being precise here, because this is often misdiagnosed as a data quality problem.
The numbers are usually right. The systems are accurate within their domains. Yet executive confidence still degrades, for four reasons that have nothing to do with correctness.
Fragmented data. When the answer to a board question requires assembling three sources by hand, the answer arrives late — or with a caveat. Delay reads as uncertainty regardless of the underlying accuracy.
Inconsistent definitions. Sales counts ARR at signature; finance counts it at activation. Both correct, both internally consistent. The board sees 44% on one slide and 38% on another and hears: leadership can't agree on its most important number.
Organizational silos. Each function reports from its own tool with its own conventions. Nobody is wrong. Nothing ties out.
Disconnected reporting processes. When the path from headline figure to source record can't be walked quickly, "let me get back to you" becomes the standard answer. Every instance chips at the assumption that finance has command of its numbers.
None of these is a data error. All of them are coherence failures — and coherence is what the financial intelligence layer is supposed to provide.
AI doesn't fix this, and shouldn't try
AI is arriving into this environment fast, often pitched as the thing that finally makes fragmented data legible.
It isn't. AI operates on what it's given. Hand it metrics built on conflicting definitions and it will explain conflicting metrics — fluently, confidently, at speed. It has no way to know that "ARR" meant two different things in the two datasets it received.
And the failure is harder to catch than the one it replaced. An analyst writing commentary might sense the numbers feel off and go check. A language model produces well-formed prose around whatever it's handed. Ungoverned data plus AI is articulate wrongness, delivered faster.
So the ordering is fixed: govern and reconcile first, then apply AI. And AI's role stays bounded even then — it should interpret validated financial outputs and provide executive context, never generate financial numbers. Figures come from deterministic calculation on reconciled data. AI puts them into language. A person reviews and signs.
Where SMPL.ai fits
SMPL.ai is built to be the financial intelligence layer in that framework — the middle tier, deliberately.
SMPL reads and reconciles information from your source systems — billing, CRM, and the general ledger — into one governed operating model, then computes the metrics leadership needs from that single reconciled base: the ARR waterfall, NRR and GRR, deferred revenue, recognized revenue, cash, headcount as a driver. Calculations are deterministic, and every figure carries lineage back to source, so a headline number can be walked to the contracts underneath while a director is still asking.
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, owned by your team and your auditors. The systems of record keep doing their job; SMPL does the middle one.
And AI-generated narratives are grounded in validated engine outputs rather than independently generating financial metrics. The commentary explains movements the engine actually computed, drawn from the same reconciled base as the tables — so narrative and numbers can't quietly disagree. That's what makes the executive reporting trustworthy: not that it's well written, but that everything in it traces back.
Evaluating your own reporting architecture
Practical questions to work through:
- Map where each headline metric is actually computed. Not stored — computed. If the ARR waterfall is assembled in a spreadsheet at period end, that step is your financial intelligence layer, and it's ungoverned.
- Count the systems that produce numbers reaching leadership. Each department dashboard quoting its own figures is a future conflict. Decide which are authoritative for executive reporting.
- Test reproducibility on a closed period. Recompute last quarter. If you don't get the same numbers, you have a snapshot or definition-drift problem worth finding now.
- Time a trace. Take a board number and follow it to source. Under a minute is healthy. Anything longer marks where risk concentrates.
- Find the single-person dependencies. Which reconciliations only one person can perform? That's operational risk with a resignation letter attached.
- Ask what each new tool adds to the reporting burden. Before the next purchase, ask who will reconcile it and against what. The license fee is rarely the real cost.
- Check where AI touches your numbers. Interpreting validated outputs is useful. Generating untraceable figures is a liability.
The goal isn't fewer systems. Your operational stack is mostly serving you well. The goal is one governed layer between those systems and the decisions leadership makes on them.
See it on your own numbers
The honest test 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.