Two numbers, one board meeting
A SaaS board deck almost always carries two revenue stories.
One is the ARR waterfall: new, expansion, contraction, churn, ending ARR. It tells the board where recurring momentum is heading.
The other is GAAP revenue: what the income statement recognized last quarter, audited and tied to deferred revenue.
Both are correct. They rarely tie out to the same number. And that gap is where board conversations go sideways.
A director looks at 42% ARR growth on slide 9, then sees 31% revenue growth on slide 14, and asks the obvious question: which one is real? The honest answer is "both, they measure different things" — but if your FP&A team can't show why they differ, the follow-up emails start before the meeting ends.
This piece breaks down what each number actually measures, why they diverge on purpose, and why a growth-stage SaaS CFO needs both living in one governed operating model instead of two disconnected spreadsheets.
What the ARR waterfall actually measures
ARR is a run-rate. It's the annualized value of your recurring subscription contracts at a point in time. Multiply committed MRR by twelve and you're close.
Note the word contracted. ARR is a forward-looking momentum metric, not a recognized-revenue metric. A customer who signs a $120,000 annual deal on the last day of the quarter adds $120,000 to ARR immediately — even though GAAP will recognize almost none of it in that period.
The ARR waterfall is the bridge that explains how you got from beginning ARR to ending ARR over a period. It's built from four movements.
The four movements
- New. ARR from newly acquired customers — logos that weren't paying you at the start of the period. This is the top-of-funnel growth line the board watches most closely.
- Expansion. ARR growth inside your existing base: upsells, cross-sells, added seats, tier upgrades, price increases on renewal. The customer stays; their spend goes up.
- Contraction. The reverse. Existing customers who downgrade, drop seats, or move to a cheaper tier. They're still customers, but they're worth less than they were.
- Churn. Full loss. A customer cancels and their ARR leaves the base entirely. This is gross ARR churn — the number that feeds gross revenue retention.
Beginning ARR, plus new, plus expansion, minus contraction, minus churn, equals ending ARR. That's the whole waterfall.
These movements also feed the retention metrics boards ask about by name. Net revenue retention nets expansion against contraction and churn within the existing base. Gross revenue retention ignores expansion and shows how much you kept before any upsell. A waterfall that can't reproduce NRR and GRR from the same movements isn't finished.
The ARR waterfall is a management metric. There's no accounting standard that defines it. Two companies can compute "expansion" differently and both be defensible. That flexibility is useful — and it's exactly why the number needs governance, which we'll come back to.
What GAAP revenue actually measures
GAAP revenue is what you earned, recognized under ASC 606 as you satisfy performance obligations. For most SaaS, that means recognizing subscription revenue ratably over the service period.
Take that same $120,000 annual contract signed on the last day of the quarter. GAAP recognizes roughly $10,000 per month as you deliver the service. In the quarter it was signed, recognized revenue is close to zero. The other ~$120,000 sits on the balance sheet as deferred revenue — a liability representing cash you've billed or collected but haven't yet earned.
So GAAP revenue is backward-looking and delivery-based. It's audited. It ties to the income statement, to deferred revenue on the balance sheet, and to cash once you account for billing terms and collections.
It also includes things ARR deliberately excludes. One-time implementation fees, professional services, and usage overages generally show up in GAAP revenue but not in ARR, because they aren't recurring. That's another reason the two numbers won't match.
ARR is not recognized revenue. Treating them as interchangeable is the single most common error in SaaS board reporting, and a sharp director will catch it in seconds.
Why the two never tie — and why that's fine
The divergence isn't a mistake to fix. It's structural. Three drivers explain most of it.
Timing. ARR books the full run-rate the moment a contract goes live. GAAP spreads that same contract across the delivery period. A strong bookings quarter inflates ending ARR long before it shows up in recognized revenue.
Scope. ARR is recurring subscription only. GAAP revenue includes services, one-time fees, and usage. The two are measuring overlapping-but-different populations of dollars.
Definition. GAAP is standardized and enforceable. ARR is a management convention. Ramp deals, mid-period starts, multi-year contracts with escalators, and usage-based components all get handled differently depending on your ARR policy — and none of those judgment calls apply to how ASC 606 recognizes the revenue.
None of this is a problem. The problem is when a board deck presents both numbers as if they should agree, and then can't explain the bridge when asked.
The board conversation that goes wrong
Here's the failure mode. FP&A pulls ARR from the CRM, revenue from the GL, and retention from a separate model. Each lives in its own tab, built by a different person, refreshed on a different date.
The deck looks clean. Then a director asks a simple question: "Your expansion ARR is up 60%, but recognized revenue is only up 20% — walk me through that."
If the answer requires someone to reopen three spreadsheets, hunt for the source of a hardcoded cell, and rebuild a bridge live, you've lost the room. Not because the numbers are wrong, but because they aren't traceable. The board can't see the lineage from the headline figure back to the contract that produced it.
The follow-up questions after the meeting are a symptom of the same disease. Executives keep asking because the first answer wasn't grounded in something they could verify. Trust in the numbers erodes one unresolved question at a time.
Putting both in one operating model
The fix isn't picking ARR or GAAP. Boards need both — one for momentum, one for earned performance. The fix is putting them in a single operating model built on the same governed data, with an explicit reconciliation between them.
That means the ARR waterfall and recognized revenue draw from one reconciled source of truth, not two exports that happen to sit in the same file. When new-logo ARR moves, you can trace which contracts drove it, and show how that same population flows into recognized revenue over the coming quarters. The bridge between the two becomes a standing artifact, not a fire drill.
Three things make that bridge trustworthy.
Traceability is the price of trust
Every number in the board pack should drill down to its source. If ending ARR is $8.4M, a director should be able to see the movements that built it, and each movement should tie back to the underlying customer records — not to a cell someone typed in.
Deterministic calculation
The same inputs should always produce the same ARR. If two runs of the same period return different numbers, no amount of narrative will rebuild trust. Deterministic calcs mean expansion is computed the same way every close, so quarter-over-quarter comparisons actually mean something.
Governed close, not a moving target
A board number should be locked before it's presented. When your ARR waterfall and revenue figures can still shift after the deck ships, the board is reviewing a draft. A governed close — where data is loaded, validated, locked, and frozen in sequence — means the figures on slide 9 are the figures, full stop.
How SMPL.ai handles it
SMPL.ai is built for exactly this reconciliation problem, and it's worth being precise about what it does and doesn't do.
SMPL reads and reconciles your source systems — billing, CRM, and the general ledger — into one governed model. It computes the ARR waterfall, MRR movements, NRR, GRR, deferred revenue, and recognized revenue from the same reconciled base, so ARR and GAAP live side by side instead of in separate files.
SMPL does not write back to your ERP or general ledger. It reads from your systems of record; it never posts to them. Your GL stays your GL. That's a deliberate boundary — the platform is a reporting and reconciliation layer, not a bookkeeping system.
The calculations are deterministic. Run the same period twice, get the same waterfall. Every figure carries its lineage, so when a director asks how expansion ARR reconciles to recognized revenue, you can walk the bridge on screen and drill to the contracts underneath.
The close is governed through a Load → Validate → Lock → Freeze sequence, so board numbers are locked before they're presented, not still moving in the background.
And the AI narrative is grounded in those validated engine outputs. It explains the movements the model actually computed — it doesn't invent a number or a trend that isn't in the data. If the narrative says expansion drove the quarter, the figure behind that sentence traces to the same reconciled source as everything else in the pack.
The result is a board conversation where ARR and GAAP revenue can both be on the table, clearly distinct, and fully reconcilable — with far fewer follow-up emails after the meeting.
See it on your own numbers
The fastest way to judge whether one governed model beats two spreadsheets is to watch your own ARR waterfall reconcile to your own recognized revenue.
Book a demo and we'll walk the bridge on data that looks like yours.