RevRule by Payload, problem guide
In a waterfall, sequence is arithmetic.
Distribution fee, expenses, recoupment, participation: each step takes its cut of what the previous step left. The same percentages in a different order pay different people, which is why waterfall disputes are usually about order, not rates.
The structure
Every waterfall step needs three definitions
A waterfall step that says only "30 percent" is under-specified. To compute it the same way twice, a step needs its rate, its base (the gross, or the remainder after a named earlier step), and its position in the sequence. Film distribution deals, content platform settlements, franchise royalty structures, and joint venture agreements all share this shape, and most statement disputes trace back to one of the three being ambiguous in the contract or improvised in the spreadsheet.
Recoupment sits inside the waterfall as a stateful step: an advance or minimum guarantee is recovered from a named participant's share, event by event, until it clears, and that participant's position in the sequence determines how fast it clears. Recoupment mechanics in detail.
Worked example
A 200-won episode, five steps down the cascade
Synthetic demonstration, fictional figures
This cascade is a published synthetic fixture modeled on documented webtoon industry practice and run on the RevRule engine. One episode sells for 200 won. The app store takes 30 percent of gross (60). The platform takes 50 percent of the 140 remainder (70). The content provider takes 35 percent of the remaining 70 (24.50). The creator pool is what is left: 45.50, split writer 60 percent (27.30), artist 30 percent (13.65), assistant 10 percent (4.55). After the 4.9 percent withholding presentation used in that industry, the three creators net 43 won combined, the figure creators in that market actually talk about. Across a 60-episode run the engine ledger matched the hand calculation exactly at every step, hash chain valid. A second fixture graph recouped a minimum guarantee advance out of the provider's share across 40 episodes until it cleared. Synthetic data; not a customer result.
| Step | Base | Amount (won) |
|---|---|---|
| Episode price (gross) | Sale | 200.00 |
| App store fee, 30% | Gross | 60.00 |
| Platform share, 50% | Remainder 140 | 70.00 |
| Content provider, 35% | Remainder 70 | 24.50 |
| Creator pool | Remainder | 45.50 |
| Writer 60% / artist 30% / assistant 10% | Creator pool | 27.30 / 13.65 / 4.55 |
Run the same percentages in a different order and the creators' 45.50 moves. That is the whole argument for writing the waterfall down as an ordered rule set instead of a paragraph of percentages.
How RevRule handles it
The waterfall is the rule set
A RevRule Revenue Graph is an ordered set of entitlement rules: each step names its base and rate, recoupment steps carry their balances as engine state, and effective-dated versions handle amendments without rewriting settled history. Every revenue event flows through the same sequence, and the hash-chained ledger records the input, each step's output, and the remainder passed down, queryable by event, participant, or entry type and returnable in full as JSON. A participant with the rule set and one event can recompute the event. That is the verification standard a participation statement should meet.
Simulate a waterfall change before it governs a live run; simulation is a dry run with zero side effects. RevRule does not hold funds, execute payments, or administer statutory rights. It computes contractual entitlements for money already collected, under the rules you define.
Pricing: $99 one-time perpetual license (uncapped operations, unlimited Revenue Graphs, 1 API key), or managed plans at $29, $79, and $199 per month with higher operation, graph, and key allowances. Evaluation accounts are limited to 1,000 operations per month and 3 Revenue Graphs. Seven-day refunds. Support by email, best effort.
Questions
Waterfalls, answered plainly
What is a revenue waterfall in a contract?
A waterfall is an ordered sequence of deductions and splits applied to revenue. A typical film or content waterfall takes the distributor or platform share first, then fees, then recoupable expenses and advances, and only then divides what remains among the participation holders. Each step is computed on the remainder of the step before it.
Why does the order of a waterfall matter so much?
Because most steps are percentages of a remainder, not of the gross. Moving a fee before or after an expense changes the base every later step is computed on. Two statements can cite the same percentages and pay different amounts purely because the sequence differs, which is why participation disputes so often come down to order rather than rates.
How should a waterfall be documented so participants can verify it?
As an explicit ordered rule set, with each step named, its base defined (gross, or the remainder after a named step), and its rate fixed, plus a per-event ledger that shows the input, each step's amount, and the remainder passed down. If a participant cannot recompute one event from the published rules, the documentation is not finished.
Related guides: royalty recoupment calculation, a renegotiated split applied late, revenue-share reconciliation in a spreadsheet, creator commission splits.