"You're getting 10%."
Ten percent of what?
This is the question that breaks most revenue-sharing arrangements. Not because anyone is dishonest, but because a percentage without a defined base is not a number. It is a shape. And shapes don't pay rent.
The Problem
Every revenue split you've ever seen looks simple on paper:
Artist gets 18%. Producer gets 3 points. Platform takes 5%.
But run the math and the ambiguity explodes. Here is a real scenario from music, but the same pattern shows up in SaaS partnerships, marketplace splits, API revenue shares, and creator deals:
- Gross revenue: $100.00
- Distributor fee: $15.00
- Platform processing: $5.00
- Taxes withheld: $3.00
Now calculate "18%":
| Base | Calculation | Result |
|---|---|---|
| Gross | 18% × $100.00 | $18.00 |
| Net (after processing) | 18% × ($100 − $5) | $17.10 |
| Net (after all deductions) | 18% × ($100 − $15 − $5 − $3) | $13.86 |
| Remaining pool (after platform fee) | 18% × ($100 − $5 − $5) | $16.20 |
Same contract. Same 18%. Four different payouts, ranging from $13.86 to $18.00. That is a 30% swing on a single line item, and nobody lied about anything. They just never defined the base.
In music, this is why contracts specify "net receipts," "PPD" (published price to dealers), or "wholesale price" as the base. In SaaS, it is why partner agreements distinguish gross bookings from net revenue. The base is a contract term, not a detail.
Why Splitters Get This Wrong
Most payment-splitting tools apply every percentage to whatever amount is left in the pool at the time the rule runs. That is one specific base ("remaining pool"), hardcoded as the only option.
But real agreements need more:
- Gross: the full event amount, before anything is taken out. Used for platform fees that come off the top.
- Net: amount minus processing costs. Used when the agreement says "after fees."
- Qualifying: amount minus all deductions (distributor cuts, taxes, platform fees). Used for "net receipts" royalty language.
- Remaining: the current pool after higher-priority rules have consumed their share. Used for waterfall-style splits.
A single revenue graph might need all four on the same event. A platform fee calculated on gross, an artist royalty on net, a producer share on qualifying, and a remainder rule on whatever is left.
The Math, Shown
Here is a real calculation from a working revenue engine. Same event, three rules, three different bases:
Event: $100.00 marketplace transaction, $5.00 processing cost
Rules:
- Platform fee: 10% of gross → 10% × $100.00 = $10.00
- Artist royalty: 20% of net → 20% × ($100.00 − $5.00) = 20% × $95.00 = $19.00
- Remainder to platform: pool − $10.00 − $19.00 = $66.00
Pool conservation check: $95.00 (pool) = $10.00 + $19.00 + $66.00. Every cent accounted for.
Change rule 2 to use "remaining" instead of "net" and the artist gets 20% × $85.00 = $17.00 instead of $19.00. Same rate, different base, different money. The engine has to know which one the agreement intended.
[SCREENSHOT: RevRule Console Simulator showing a $100 event with the three rules above, each rule's reason string displaying the base used: "10.00% of gross $100.00 → $10.00" and "20.00% of net $95.00 → $19.00"]
What to Do About It
If you are writing or signing a revenue agreement:
- Name the base explicitly. "18% of net receipts (defined as gross less distributor fees, platform fees, and taxes)" beats "18%" every time.
- Define the deduction stack. What comes out, in what order, before each party's base is computed?
- Test the math. Run a sample $100 transaction through the rules before anyone signs. If two people get different numbers, the agreement is ambiguous.
If you are building the system that executes these agreements, the percentage base has to be data on the rule, not a constant in your code. Every rule should carry its base, and every calculation should show its work: "20.00% of net $95.00 → $19.00."
Try It
The RevRule Console lets you define percentage rules against gross, net, qualifying, or remaining revenue, then simulate events and see the exact arithmetic for every entitlement.
Try the Simulator: https://payloadhq.github.io/revrule-console/
RevRule is $99 one-time. Free sandbox, no card required. The engine that ran the calculations above is the same one behind the Console.
RevRule turns agreements and revenue into auditable economic entitlements. Your payment rail moves the money. RevRule determines who is owed what, why, and under which rules.
Top comments (0)