Revenue waterfall

A revenue waterfall lays out, period by period, how much revenue each contract will contribute. Read down a column and you get total recognised revenue for that month; read across a row and you get the recognition profile of one contract.

Contract      Jan     Feb     Mar     Apr    ...
Acme       10,000  10,000  10,000  10,000
Globex      4,167   4,167   4,167   4,167
Initech         0   8,333   8,333   8,333
           ------  ------  ------  ------
Total      14,167  22,500  22,500  22,500

What it is used for

• Forecasting. Recognised revenue for the next several quarters is largely determined by contracts already signed. The waterfall makes that visible rather than modelled.
• Deferred revenue proof. The sum of all future periods should tie to the deferred revenue balance plus unbilled amounts. Auditors ask for exactly this.
• Close support. Journal entries for the period come straight off the column.
• Scenario analysis. Because it is contract-level, you can strip out contracts at risk and see the revenue impact directly.

Why maintaining it manually fails

The waterfall is only correct as at the moment it was built. Every mid-term upgrade, downgrade, cancellation, co-term and credit note changes some row from the change date forward.

A finance team maintaining this in a spreadsheet is re-deriving the affected rows every month from a list of changes that arrives late and incomplete — because the changes were made in the billing system, or agreed in the CRM, and nobody routed them to finance.

Generating the waterfall from the contract data itself removes the reconciliation entirely: a subscription change updates the schedule because the schedule is derived, not maintained.