The ARR waterfall is the most-shown chart in SaaS finance and one of the least-trusted. Every board deck has one. Starting ARR on the left, ending ARR on the right, and a row of floating bars in between — new business, expansion, contraction, churn. The math is grade-school arithmetic. And yet the same finance leaders who present it every quarter will, if pressed, admit they can't fully defend it. They know roughly why the bars are the size they are. They could not, on demand, name the contracts inside each one.
That gap — between a chart that's trivial to draw and a chart you can actually defend — is what this piece is about. We'll cover how to build an ARR waterfall correctly, the definitional traps that quietly corrupt most of them, and why the waterfall is best understood not as a report but as a test of whether your revenue data has any single source of truth at all.
What the ARR waterfall actually shows
An ARR waterfall (also called an ARR bridge) explains how you got from your recurring revenue at the start of a period to your recurring revenue at the end of it. The structure is fixed:
Starting ARR + New + Expansion − Contraction − Churn = Ending ARR
Each middle bar is a category of movement in your existing-or-incoming contract base:
- New — ARR from customers who weren't customers at the start of the period.
- Expansion — additional ARR from existing customers: upsell, cross-sell, seat growth, price increases on renewal.
- Contraction — reductions from existing customers who stayed but shrank: fewer seats, downgrades, negotiated decreases.
- Churn — ARR lost from customers who left entirely.
That's the whole model. The reason it's valuable is that it separates the sources of revenue change. Two companies can both grow ARR 20% in a year and be completely different businesses — one on the back of new logos with a leaky base, the other on expansion with near-zero churn. The net number hides that. The waterfall exposes it. That's why investors care more about the shape of the bridge than the height of the endpoints.
How to build one
There are two altitudes you can build at, and the difference is the entire point.
The aggregate method. Pull total ARR at the start, total at the end, and back into the movement categories using rates and reports — churn from the billing system, expansion from the CRM, new from bookings. Fast, and it produces a chart that looks right. It's how most waterfalls get built, and it's where most of them start to lie, because the bars are derived from summary numbers in different systems rather than from the underlying contracts. The bars sum to the right total because you forced them to, not because each one is independently true.
The contract-level method. Build the waterfall from the bottom up: every contract that was active, started, changed, or ended in the period, each classified into exactly one movement category, each contributing its specific dollar amount. The bars are sums of contracts, not estimates reconciled to a total. This is more work up front and dramatically more trustworthy, because every bar is now attributable — you can click into "churn" and see the four logos that make it up.
The aggregate method answers "how big was churn." The contract-level method answers "which contracts churned, and for how much, and when." Only the second one survives a board member asking a follow-up question.
The definitional traps
Here's the part that corrupts more waterfalls than bad math ever does: the categories sound obvious and aren't. Every one of them hides a judgment call, and if those calls aren't made consistently and written down, your waterfall is non-reproducible by construction.
Expansion vs. new. A customer adds a second product line. Is that expansion of an existing customer, or new ARR from a new business unit? Defensible either way — but if Sales logs it as new and Finance counts it as expansion, your bars are wrong and your net is still right, which is the worst possible failure because nothing looks broken.
Contraction vs. churn. A customer drops from $200K to $20K. Did they contract, or did they churn and you happened to retain a scrap? Most teams have no written rule, so it gets classified by whoever touched it last.
The renewal that isn't flat. A $100K contract renews at $120K. That's a $100K renewal and a $20K expansion — but it's tempting (and wrong) to log it as $120K of "retained" ARR and lose the expansion signal entirely. Renewals are where expansion and contraction actually happen, and flattening them is how NRR quietly disappears from the picture.
Timing. A contract churns effective the last day of Q2 but the cancellation was processed in Q3. Which quarter's waterfall does it hit? Without a rule that ties movement to contract effective dates rather than when someone entered the data, the same event can land in two different periods depending on who's building the chart that day.
None of these are math problems. They're definition problems. And definition problems can't be solved by a better spreadsheet — they're solved by every number deriving from one place where the definition is applied once, consistently, to every contract.
Why most waterfalls lie
Put the two halves together and the failure mode is clear. The math is trivial, so the chart always balances. But the bars are assembled from different systems — bookings from the CRM, churn from billing, expansion from a renewals tracker — each with its own definition of a customer, its own definition of ARR, and its own timing. The waterfall looks like a reconciliation. It's actually a collage. It balances because someone made it balance, not because each bar is independently traceable to the contracts inside it.
The tell is always the same: ask "what's in this churn bar?" and watch how long the answer takes. If it's a name and a number in five seconds, the waterfall is real. If it's "let me pull that together," the waterfall is a picture of a number, not the number itself. And a picture is exactly what falls apart in diligence, when someone external rebuilds your bridge from your raw contracts and gets a different answer than your board deck did.
This is why the ARR waterfall is best understood as a test. Not a report you produce, but a probe of whether your revenue data has a single source. A waterfall you can defend contract-by-contract means your underlying data is coherent. A waterfall you can only defend in aggregate means you have several systems describing the same revenue in incompatible ways — and the chart is hiding that, not solving it.
What a defensible waterfall requires
A bridge that survives scrutiny has three properties, and all three come from the same root:
- Every bar decomposes to contracts. Click any movement category and see the specific contracts inside it, each with its dollar amount and effective date.
- Every category is defined once. Expansion-vs-new, contraction-vs-churn, and timing rules are written down and applied uniformly, not decided per-contract by whoever's building the chart.
- It's reproducible across time. The Q2 waterfall built in July and the Q2 waterfall rebuilt in diligence next year produce the same bars — because they read from the same contract records, not from reports that have since changed.
You'll notice all three collapse into one requirement: the contract is the single thing every bar derives from. When that's true, the waterfall stops being something you assemble and becomes something you query. New, expansion, contraction, and churn aren't four reports stitched together — they're four views of one contract table, filtered by movement type. They reconcile because there's nothing to reconcile. They're the same data.
That's the idea underneath HarborOS: the contract is the atom the entire revenue picture is built from. The ARR bridge, the retention metrics, the renewal forecast, and the board pack are all derived from the same contract records — one query, one number, every bar traceable to a specific contract decision. The waterfall isn't drawn from four systems and forced to balance. It reads off one, and balances because it was never fragmented to begin with.