An investor puts up $1,000. The deal: they recoup from 50% of revenue until the advance is repaid, then drop to a 5% residual.
Simple enough. Until you ask the question nobody's spreadsheet answers cleanly:
What happens on the exact transaction where the advance finishes recouping?
The Problem
Recoupment is stateful. It is not a percentage. It is a threshold with memory.
Most split calculators handle "before recoupment" and "after recoupment" as two separate configurations. But real revenue does not arrive in neat phases. It arrives as a stream of events, and one of those events will cross the threshold mid-transaction.
Consider:
- Advance: $1,000.00
- Recoup rate: 50% of each revenue event
- Post-recoupment rate: 5%
- Total recouped so far: $950.00
- Remaining to recoup: $50.00
Now a $200.00 revenue event arrives.
A naive splitter does one of two wrong things:
- Applies 50% to the whole event: investor gets $100. But only $50 was needed. The investor is now over-recouped by $50, and nobody's accounting caught it.
- Applies 5% to the whole event: investor gets $10. But the advance wasn't finished yet. The investor is shortchanged $40.
The correct answer requires intra-event semantics: the engine must split a single event at the threshold.
The Math, Shown
Here is the actual execution from a revenue rules engine processing this exact scenario:
Setup: $1,000 advance, 50% recoup rate, 5% post-rate
Event 1: $1,900.00
- Investor: $950.00 — "recoupment: $950.00 of $1,000.00 advance at 50.00% (cumulative $950.00)"
- Creator: $950.00 — remainder
- State: $950 recouped, $50 remaining
Event 2: $200.00 — THE THRESHOLD EVENT
- Investor: $55.00 — "recoupment: $50.00 of $1,000.00 advance at 50.00% (cumulative $1,000.00), $5.00 of pool remainder at post-rate 5.00%"
- Creator: $145.00 — remainder
- State: RECOUPED. Advance complete.
Look at what happened inside Event 2. The engine took the $200, applied 50% to the first $100 (yielding exactly the $50 needed to finish the $1,000 advance), then switched to the 5% post-rate for the remaining $100 (yielding $5). Total to investor: $55. Not $100. Not $10. Exactly $55.
Event 3: $100.00 — AFTER RECOUPMENT
- Investor: $5.00 — "$0.00 of $1,000.00 advance (cumulative $1,000.00), $5.00 at post-rate 5.00%"
- Creator: $95.00 — remainder
The state persisted. The next event automatically used the new economics. No manual intervention, no configuration change, no spreadsheet update.
[SCREENSHOT: RevRule Console Simulator showing Event 2 with the recoupment reason string visible, highlighting the threshold crossing: "cumulative $1,000.00" and the split between recoupment and post-rate amounts]
[SCREENSHOT: RevRule Console Entitlements page showing the investor's recoupment progress bar at 100% after Event 2]
Why This Matters Beyond Music
Recoupment shows up everywhere:
- Marketplaces: platform recoups onboarding costs from seller revenue before the standard fee applies
- SaaS partnerships: a reseller advance against future commissions
- Creator deals: brand recoups production costs from ad revenue share
- API monetization: infrastructure costs recouped from usage revenue before profit splits
- Film/TV: the classic "backend participation after recoupment" waterfall
In every case, the threshold-crossing event is where handshake deals break and spreadsheets fail. Someone has to decide how to split a single transaction across two economic regimes. If your system cannot do it deterministically, with an audit trail, you are doing it by hand.
The Audit Trail
Every calculation above produced a ledger entry with:
- The event ID that triggered it
- The graph version (agreement version) in effect
- The rule ID that fired
- The exact arithmetic in plain language
- The state before and after
For Event 2, the ledger shows the cumulative recoupment hitting exactly $1,000.00. If anyone asks "why did the investor get $55 on that transaction?", the answer is one ledger query away. No reconstruction needed.
Try It
The RevRule Console Simulator lets you set up a recoupment scenario, process events, and watch the threshold crossing happen in real time. Each simulation shows the exact reason strings from the engine.
Try it: https://payloadhq.github.io/revrule-console/
RevRule is $99 one-time. Free sandbox, no card required. The recoupment engine above — intra-event threshold crossing, persistent state, automatic rate transition — is the same code running behind the Console.
RevRule turns agreements and revenue into auditable economic entitlements. Upload the agreement. Connect the revenue. RevRule determines who is owed what.
Top comments (0)