Every revenue-split dispute starts the same way. Both parties are looking at the same agreement and the same bank deposit. Both did arithmetic. The numbers are different, and both people believe theirs is the honest one.
Ask the question that is actually being argued and it is never "what is the percentage?" The percentage is the one thing everyone wrote down. The argument is: 10% of WHAT?
A revenue share is not a number. It is at least three decisions wearing a percentage as a disguise — a base, a state, and an order — and a split "breaks" whenever a tool, a spreadsheet, or a payout platform silently picks a different one than the agreement did. Here are the three, and what it takes for a calculation to survive all of them.
Break 1: The base
Percentages apply to an amount, and agreements name different amounts:
- Gross — the full event amount, before anything is deducted. Typical for platform fees that come off the top.
- Net — the amount minus processing costs. What "after fees" means, when the agreement says it.
- Qualifying — the amount minus all deductions: distributor cuts, taxes, platform fees. The base behind "net receipts" royalty language.
- Remaining — whatever is left in the pool after higher-priority rules have taken their share. The base waterfall rules run on.
Most splitting tools apply every percentage to whatever happens to be left in the pool when the rule runs — one base, hardcoded, applied to everything. That works until a real agreement mixes bases, which real agreements do immediately. Same event, three rules, three bases (this is the worked example from our earlier piece, 10% of WHAT?):
Event: $100.00 transaction, $5.00 processing cost
- Platform fee: 10% of gross → 10% × $100.00 = $10.00
- Artist royalty: 20% of net → 20% × $95.00 = $19.00
- Remainder to platform: $100.00 − $10.00 − $19.00 − $5.00 processing = $66.00
Change rule 2's base from net to remaining and the artist gets $17.00 instead of $19.00. Same rate. Same event. Different money — and if the tool can't tell you which base it used, you cannot even have the argument productively. You just have two totals and a disagreement.
Break 2: The state (recoupment)
An advance changes the deal twice: once when it is paid, and again when it is earned back. Until recoupment completes, revenue routes to recovering the advance at the recoupment rate; from the moment it completes, the parties are on their post-recoupment rates. The rate is a function of where you are in the lifecycle, not a constant.
This is the break spreadsheets are worst at, because a spreadsheet formula has no memory. Whether the advance is 60% recovered or 100% recovered lives in somebody's tracking tab, and the payout formula doesn't know the state flipped — least of all mid-event, when a single payment carries the cumulative total across the recoupment line and part of that payment should be treated at the old rate and the rest at the new one.
A stateful engine handles this the way the agreement means it: recoupment is a state machine, the transition is automatic, and the mid-event flip is computed, not remembered. We verified this behavior live on the engine described below: a $1,000 advance at 50% recoupment, with the rate transition occurring inside the event that completes recovery. Nobody updated a tab. The state was the calculation's input, not its aftermath.
Search interest tells the same story: "how to track recoupment of an advance" is a query with almost no tooling content answering it, because most split tools don't model state at all. If your agreement has an advance in it, a stateless splitter is not a simpler tool. It is a wrong one.
Break 3: The order (waterfalls)
When several parties are paid from one event, the agreement almost never means "everyone simultaneously." It means a priority: this fee first, this participant next, the remainder last. Order is not bookkeeping cosmetics — it decides who absorbs a shortfall. If the pool comes in smaller than expected, the last rule in the waterfall gets what is left, which may be nothing, and the first rules are unaffected. Run the same rules in a different order and you have paid a different agreement.
Order interacts with the other two breaks. A remainder rule is defined by everything above it in priority. A recoupment recovery rule's position determines which revenue it can reach. This is why hand-rolled split code — the take-the-payment, carve-off-the-cuts sequence every marketplace and creator collab eventually writes for itself — drifts: each new agreement shape gets patched into the sequence in the order it was requested, not the order the contracts specify, and there is no audit trail when a participant asks where their money went.
What a rules engine does differently
The fix is to stop encoding agreements as sequences of arithmetic and start treating them as what they are: rules over a state, evaluated deterministically.
- The agreement is data, not code. Bases (gross / net / qualifying / remaining), rates, caps, source-specific rates — a channel or payment source can carry its own rate — and waterfall priority are declared per agreement, then ingested revenue (statements, CSV, APIs, webhooks, x402 machine payments) is evaluated against them. Changing an agreement means changing its rules, not patching a payout script.
- State persists. Recoupment balances, cumulative totals, and waterfall position survive across events and across payment rails, because the economic state belongs to the agreement, not to whichever rail happened to move this month's money.
- Every amount carries its explanation. The output is not a total; it is entitlements — who is owed what, on which base, at which rate, under which rule — recorded in a hash-chained ledger, with participant statements generated from the same record. When a participant disputes a number, the answer is the derivation, not a screenshot of a spreadsheet.
- Terms are verified before they go live. Ingested agreement terms require human verification before any of them drive a calculation. An engine that computes exactly what it is told is dangerous precisely when it was told wrong; the check belongs before the first event, not after the first dispute.
And one structural property worth stating on its own: a rules engine that determines the economics does not need to hold the money to do it. Your payment rail moves the money. The engine emits settlement-ready payout instructions (CSV/JSON) and your own rail — Stripe, bank, crypto — executes them. The custody question that haunts payout platforms is absent because the architecture never takes possession.
Where RevRule fits
RevRule (by Payload) is that engine, and its pipeline is the three nouns in this article's model: a Revenue Graph — the versioned, stateful rule graph for an agreement — turns economic events into entitlements, recorded in a hash-chained ledger. It is non-custodial by design: it never holds funds and never moves money. Recoupment with automatic mid-event transition, waterfalls in priority order, per-agreement bases, source-specific rates, and caps are the verified feature set; the recoupment behavior above was run on this engine, not described from a roadmap.
This is not a mockup you have to take our word for. The console is live, the API is live, and the engine's test suite passes 138/138 — the conservation and transition behavior is checkable, which in this category is the point: the buying criterion for split tooling is a number your team and your partners can trust, and trust comes from derivations you can inspect. It is $99 one-time — production API access, unlimited Revenue Graphs, documentation, the n8n node, and email support — because the product is the engine, not a per-transaction toll on your payouts.
Its honest limits: it determines economics; it does not move money, hold balances, or replace your rail, and if your agreement is a single flat percentage of gross with no advance and no waterfall, you do not need it — a spreadsheet genuinely is fine, right up until the agreement grows a second base, a recoupment line, or a third party. That is the moment this article is about.
If you want the graphs themselves, the companion piece — Stop hand-rolling revenue splits: 3 copy-paste Revenue Graphs — publishes three production-ready blueprints (API revenue share, marketplace split, creator recoupment) you can load and run.
The checklist
Before your next payout run, ask of whatever process computes it:
- For every percentage in the agreement: of what base? If the tool can't answer per rule — gross, net, qualifying, or remaining — it is applying one base to everything and hoping.
- Where does recoupment state live, and does the calculation read it — including the event that crosses the line?
- What is the waterfall order, and who absorbs a shortfall when the pool comes in light? Is that what the agreement says, or what the code happens to do?
- Can every amount explain itself — base, rate, rule, state — to the participant it belongs to?
- Does the thing computing your splits also hold your money? If yes, ask why it needs to.
The percentage was never the split. The split is the base, the state, and the order — and it holds exactly as long as your tooling models all three.
Top comments (1)
This matches what payout disputes actually look like. The 'of what base' question is the one that exposes it every time: two teams can compute the same percentage honestly and both be right given their base. The explanation-carrying-amount point is underrated too, since when every line on a statement can cite the rule, the state, and the order behind it, reconciliation stops being archaeology. And the last checklist question is the sharpest one: the party computing the split also holding the money is exactly where the audit questions start.