Skills / FP&A and reporting

ARR Waterfall

The ARR waterfall is the board metric every SaaS company rebuilds from scratch every month, new, expansion, contraction, churn, and it's also one of the easiest numbers to get subtly wrong: a dropped row quietly erases the churn it represents, two opposite movements on one account net into a figure that hides what actually happened, or the board's ARR drifts away from what revenue recognition shows on the GL. None of those mistakes change the top-line number by much. All of them change what the board thinks is actually driving it.

What it does

This skill builds the ARR or MRR movement waterfall from a current-period and a prior-period subscription export, indexing off the union of both files rather than just the current one, so a customer present last period but missing from this period's extract is still picked up and classified churn rather than silently dropped. Beginning ARR plus new, expansion, contraction, and churn must equal ending ARR exactly, a closed arithmetic identity checked every run, and ending ARR is then compared against GL recognized revenue for the period within whatever tolerance is supplied.

The one rule it can't skip

It never resolves a large contraction into a confirmed downsell or a disguised churn event on its own. An account whose MRR drops sharply but not to zero lands on its own Judgment Items tab instead, since the boundary between a genuine downsell and a reduced renewal that's functionally churn is a call that needs business context this skill doesn't have. It surfaces the pattern; a person decides what it actually is.

How the classification actually runs

Every customer appearing in either the current or prior extract is classified by comparing its current MRR to its prior MRR: present in both with an increase is expansion, present in both with a decrease is contraction, present only in the current file is new, and present only in the prior file, or present in both with the account entirely gone this period, is churn. A customer whose MRR amount can't be parsed in either file is excluded and reported as its own exception, never treated as zero, since a zero would misclassify a real customer as new or fully churned. The full ARR rollforward, beginning balance plus every movement bucket, must equal the ending balance exactly before the workbook is produced, and ending ARR is separately compared to GL recognized revenue within the stated tolerance.

What it won't do

It won't net two movements on the same account into a single line, even when doing so would make the waterfall simpler to read; both are shown, and the reader sees the full picture. It won't decide that a large contraction is really a downsell or really a churn event; that goes to Judgment Items for a person to confirm. It won't treat a missing MRR amount as zero; the customer is excluded and reported instead, since zero would misclassify them outright. And it won't publish or present the waterfall; it produces the classified, tied-out schedule for the board package to draw from.

Inputs and output

InputsCurrent-period subscription or invoice export (customer, plan, MRR, effective date), prior-period ending ARR/MRR by customer, GL recognized revenue for the period, and an optional tie tolerance
OutputAn ARR waterfall with every customer classified new, expansion, contraction, or churn, a closed beginning-to-ending identity, a revenue tie against the GL, and a Judgment Items tab for large contractions
Who it's forCFOs at subscription businesses who own the ARR metric the board sees every month

Adopt's agents rebuild this waterfall every month from the subscription data you already have, index off both periods so a dropped customer can't erase its own churn, and tie the ending number to what revenue recognition actually shows. Sign up free, or book a pilot to run it against your own ARR.