In this article
Six families of tools let you pay several parties by percentage: a spreadsheet with manual transfers, a bank standing instruction or sweep, a payment processor's split-payment feature, revenue-share or royalty software, an onchain splitter contract, and an onchain payment router. The criterion that separates them is whether the percentages are applied automatically to each incoming payment, or calculated afterwards by a person or a scheduled run.
When the rule is applied afterwards, one party or one service holds the full amount for a while, and somebody has to turn percentages into amounts that add up to the cent. That arithmetic is where hand-made splits go wrong, and it is the same whatever tool you pick: a percentage needs a base (gross, or net of a fee), deductions need an order, and rounded shares need a rule so that they sum exactly to the amount paid. This article works one split from start to finish, 55 / 30 / 10 / 5 on a stated amount, then shows what each family of tools does with it.
Worked example of this article: one payment split 55 / 30 / 10 / 5, with an illustrative fee of 2.9% plus $0.30. The fee is an assumption, not a quoted price.
What can apply a percentage to a payment automatically?
A payment processor's split feature, an onchain splitter contract and an onchain payment router apply percentage rules to each incoming payment without anyone recalculating. A spreadsheet, a bank standing instruction and revenue-share software either leave the calculation to a person or run it later, on a statement.
The difference is not about quality. A spreadsheet is the most flexible of the six: it can express any rule you can write as a formula. Revenue-share and royalty software exists because some splits cannot be computed at the moment of payment at all: a royalty that depends on returns or on a quarter's total can only be calculated once the period is closed.
| Family | Percentage applied to each payment | Rounding and remainder | Record left |
|---|---|---|---|
| Spreadsheet and manual transfers | No: a person calculates, then sends each transfer | Whatever the formulas do; often unhandled | The sheet and one bank line per transfer |
| Bank standing instruction or sweep | Rarely: most instructions carry fixed amounts or move a whole balance | Not applicable to fixed amounts | Bank statements of the paying account |
| Processor split-payment feature | Yes, by rule on each sale | Set by the processor, in the smallest currency unit | Processor dashboard and payout reports |
| Revenue-share or royalty software | Calculated per period, paid later | Set by the software, usually per statement | A statement per recipient |
| Onchain splitter contract | Yes, by the contract on what it receives | Integer arithmetic in the token's smallest unit | The public ledger of the network |
| Onchain payment router | Yes, in the payment transaction itself | Integer arithmetic in the token's smallest unit | The public ledger, one transaction for all |
A bank standing instruction is "rarely" a percentage tool because, in everyday business banking, it is an order to pay a fixed amount on a fixed date, and a sweep moves the balance above a threshold to one other account. Percentage rules across several outside beneficiaries are arranged bank by bank and are not something you can assume.
Is each percentage taken on the gross amount or on the net after fees?
A percentage share has no meaning until the agreement says what it is a percentage of: the gross amount the client paid, or the net amount left after the payment fee. On the same payment, the two readings give every party a different amount, and the gap equals the fee.
Take the worked example. A client pays $18,400.35. Four parties have agreed shares of 55%, 30%, 10% and 5%: a lead firm, a second firm, a specialist and an introducer. Suppose the payment arrives through a channel that charges an illustrative 2.9% plus $0.30. The fee is 2.9% of $18,400.35, which is $533.61 to the cent, plus $0.30: $533.91. The net received is $18,400.35 minus $533.91, which is $17,866.44. The table rounds each share with the method shown further down, so that every column sums exactly.
| Party and share | Share of gross $18,400.35 | Share of net $17,866.44 | Difference |
|---|---|---|---|
| Lead firm, 55% | $10,120.19 | $9,826.54 | $293.65 |
| Second firm, 30% | $5,520.11 | $5,359.93 | $160.18 |
| Specialist, 10% | $1,840.03 | $1,786.65 | $53.38 |
| Introducer, 5% | $920.02 | $893.32 | $26.70 |
| Total | $18,400.35 | $17,866.44 | $533.91 |
Shares of net spread the fee across everyone in proportion: the four differences add up to $533.91 exactly. Shares of gross look more generous, but they cannot all be paid, because only $17,866.44 arrived. Somebody absorbs the fee. If the agreement says the lead firm bears the cost of collection, the lead firm receives $10,120.19 minus $533.91, which is $9,586.28, and the other three receive their gross shares. That is $240.26 less than the $9,826.54 of the net reading.
Neither reading is the correct one. What goes wrong is a split agreed as "55 / 30 / 10 / 5" with no base, calculated by one party on gross and expected by another on net. With a processor's split feature, ask which account the processing fee is taken from; a tool that pays shares of the amount received applies the net reading by construction.
Which deduction comes first when costs come off before the split?
The order of deductions changes every share: an amount taken "off the top" before the percentages are applied is paid by all parties in proportion to their shares, while the same amount taken from one party's share afterwards is paid by that party alone. An agreement that lists the deductions without their order can be computed in several ways.
Use the same $18,400.35, this time with no fee, and add one fact: the second firm advanced $1,200.00 of expenses that the parties agreed to reimburse.
Read one way, the percentages apply to the full amount and the expense stays with the second firm: the shares are those of the gross column above. Read the other way, the expense is reimbursed first. The pool to share becomes $18,400.35 minus $1,200.00, which is $17,200.35. The lead firm receives 55% of it, $9,460.19; the second firm 30%, $5,160.11, plus its $1,200.00, so $6,360.11; the specialist $1,720.03; the introducer $860.02. The four payments add up to $18,400.35.
Compared with the first reading, the second firm receives $840.00 more, and the three others receive less: $660.00 for the lead firm, $120.00 for the specialist, $60.00 for the introducer. The introducer, who had nothing to do with the expense, has paid 5% of it. That is what "off the top" means.
Percentage rules in automated tools are almost always flat: so many percent of the amount received, to this destination. A waterfall with reimbursements, minimums or tiers has to be converted into flat percentages for that one payment, or it stays in a spreadsheet or in royalty software, which is built for it.
Why do rounded percentage shares fail to add up to the amount?
Shares rounded one by one to the nearest cent do not always add up to the amount paid, because each rounding moves a share by up to half a cent and the movements do not cancel. With four recipients the total can be one or two cents off in either direction.
The exact shares of $18,400.35 are not whole cents. 55% is $10,120.1925. 30% is $5,520.105. 10% is $1,840.035. 5% is $920.0175. Those four figures add up to $18,400.35 exactly, but none of them can be paid.
Round each to the nearest cent, halves up, as a spreadsheet's rounding function does, and you get $10,120.19, $5,520.11, $1,840.04 and $920.02. Their sum is $18,400.36: one cent more than the client paid. Do the same on the net amount of $17,866.44 and the error goes the other way: $9,826.54, $5,359.93, $1,786.64 and $893.32 add up to $17,866.43, one cent short.
One cent over, and the last transfer of a manual run cannot be made in full. One cent under, and a cent stays behind in an account that was meant to be empty, on every payment.
The most common shortcut is to compute all shares but one and give the last party whatever is left. It always sums, but the same party absorbs every rounding difference, and the result depends on the order of the list. For two parties it is reasonable. For a longer list, the largest-remainder method is the even-handed version of the same idea.
How does the largest-remainder method make the shares sum exactly?
The largest-remainder method rounds every share down to the cent, then hands out the cents left over, one each, to the shares that lost the largest fraction of a cent. The shares always sum to the amount, and no share ends more than one cent away from its exact value.
The method comes from the allocation of seats in proportional elections, where it is also known as the Hamilton method: seats, like cents, cannot be cut. Here it is on the gross split of the worked example.
- Compute each exact shareMultiply the amount by each percentage without rounding: $10,120.1925 for the lead firm, $5,520.105 for the second firm, $1,840.035 for the specialist, $920.0175 for the introducer.
- Round every share down to the centDrop everything after the second decimal: $10,120.19, $5,520.10, $1,840.03 and $920.01. These four add up to $18,400.33.
- Count the cents left over$18,400.35 minus $18,400.33 leaves 2 cents to hand out. The number left is always smaller than the number of recipients.
- Rank the fractions that were droppedThe introducer lost 0.75 of a cent, the second firm 0.50, the specialist 0.50, the lead firm 0.25.
- Give one cent to each of the largestThe first cent goes to the introducer. The second is a tie between the second firm and the specialist; the rule agreed in advance, here the larger share first, gives it to the second firm.
- Check the sum$10,120.19, $5,520.11, $1,840.03 and $920.02 add up to $18,400.35, the amount paid.
The fifth step shows the one thing the method does not settle by itself: a tie. Two parties lost exactly half a cent, and only one cent was left. Any rule works as long as it is written before the payment: the larger share first, the order of the list, or a party named in the agreement.
If you build this in a spreadsheet, do the calculation in whole cents, not in dollars with decimals. Spreadsheets store decimal fractions in binary, and a value such as 0.105 may be held a hair under or over, which is enough to flip a half-cent rounding. Converting the amount to an integer number of cents first (1,840,035 here) removes that class of error.
Why are shares written in basis points and not in percentages?
Basis points express a share as a whole number, with one basis point equal to one hundredth of a percent and 10,000 basis points equal to 100%. Automated tools and contracts store shares that way because whole numbers leave no doubt about precision and can be checked by a simple sum.
In basis points, the split of the worked example is 5,500, 3,000, 1,000 and 500. The share of a payment is the amount multiplied by the basis points and divided by 10,000. A share of 12.5% is 1,250 basis points; a share of 0.75% is 75.
Basis points also expose a confusion that percentages hide. "Raise the introducer from 5% by 1%" can mean 6% (one percentage point, 100 basis points more) or 5.05% (one percent of five percent, 5 basis points more). On the example the first reading adds $184.00 to the introducer's share and the second $9.20, to the nearest cent. Written as "from 500 to 600 basis points", the change has one reading.
Who holds the money between receipt and payout, and when is each party paid?
Whoever applies the percentages after the payment holds the full amount until the payout: the receiving party with a spreadsheet, the processor or platform with a split feature, the collecting company with royalty software, the contract with a pull-based splitter. Only when the split happens inside the payment itself does no one hold the others' shares.
| Family | Who holds the money | When each party is paid | Who can change the percentages |
|---|---|---|---|
| Spreadsheet and manual transfers | The party that received the payment | When that party sends each transfer | Whoever edits the sheet |
| Bank standing instruction or sweep | The account holder's bank account | On the dates of the instruction | The account holder alone |
| Processor split-payment feature | The processor, in the platform's or each recipient's balance | On the processor's payout schedule | The platform that set the rules |
| Revenue-share or royalty software | The company that collects the revenue | After the period closes and the payout run is approved | The administrator of the account |
| Onchain splitter contract | The contract, until withdrawal or distribution | When a recipient withdraws, or when someone triggers a push | Nobody if the contract is immutable; its controller if it is not |
| Onchain payment router | Nobody: the amount is routed in the paying transaction | At the same moment as the client's payment | Depends on the router: fixed before payment where shares are signed |
Holding is not a fault. A processor holds a balance because card payments can be disputed, and marketplace payment documentation commonly describes payout delays and reserves set for that reason. A royalty administrator holds revenue because the amount due is not known until returns and adjustments are in. What matters is that the parties know who holds, and for how long. With a processor, each recipient usually also has to open and verify an account with that processor before a first payout.
Can one party change the percentages alone?
In most families, yes: the percentages live in a sheet, an instruction or a settings page that one party controls, and the others rely on that party not to change them. Two onchain designs remove that reliance, an immutable splitter contract and a router where shares are signed before the payment, at the price of rigidity.
With a spreadsheet, the person who makes the transfers decides the numbers on the day. With a standing instruction, the account holder can amend or cancel it at the bank. With a processor's split feature or revenue-share software, the rules belong to the account that set them up; recipients see what they are paid, and rarely the rule itself. The split is then protected by the contract between the parties, not by the tool.
An onchain splitter contract moves the rule into code. The documentation of OpenZeppelin, a widely used open-source contract library, describes its reference splitter in these terms: the distribution of shares is set when the contract is deployed and cannot be updated afterwards, the split can be equal or in any proportion, and the contract follows a pull model, where each payee collects by a separate release step and the funds stay in the contract until then. Other splitter designs differ on both points: some let a controller edit the recipients and shares, and some push every share in one distribution transaction that anyone can trigger.
The same documentation warns that tokens which change balances by themselves or charge a fee on transfer are likely not to behave as expected in its splitter. An immutable contract also means a mistaken address or a wrong share cannot be corrected in place. A payment router that has each recipient sign a share before the client pays fixes the percentages deal by deal instead, with the agreement of the people concerned.
What does each family require for the same 55 / 30 / 10 / 5 split?
For one payment of $18,400.35 split four ways, the six families differ in how many payments are made, who holds the amount in between, and when the last party is paid. The table assumes no fee, so the four shares are $10,120.19, $5,520.11, $1,840.03 and $920.02 in every row.
| Family | Payments made | Who holds the $18,400.35 | When the last party is paid |
|---|---|---|---|
| Spreadsheet and manual transfers | 1 from the client, then 3 transfers by the lead firm | The lead firm | When the third transfer lands |
| Bank standing instruction | 1 from the client, then 3 fixed-amount orders re-entered for this payment | The lead firm's bank account | On the date of the orders |
| Processor split-payment feature | 1 from the client; 4 payouts by the processor | The processor, by balance | On the payout schedule |
| Revenue-share or royalty software | 1 from the client; 1 payout run of 3 or 4 payments | The collecting company | After the period's statement |
| Onchain splitter contract | 1 from the client; 4 withdrawals, or 1 distribution | The contract | When the last recipient withdraws |
| Onchain payment router | 1 from the client, which pays all 4 | Nobody | With the client's payment |
In the first two rows the lead firm receives everything and pays the other three, so $8,280.16 of other people's money sits in its account: $5,520.11, $1,840.03 and $920.02. A standing instruction is built for the same amount on the same date; for a one-off amount it comes down to three manual transfers.
The two onchain rows compute in the token's smallest unit, not in cents. Many dollar-denominated tokens are divisible to six decimal places, and at that precision the exact shares of this example, $10,120.1925, $5,520.105, $1,840.035 and $920.0175, are all whole numbers of units: nothing is rounded at all. A remainder appears only when a share does not divide evenly at that precision, and a contract either leaves it behind or assigns it to one recipient by rule. The record is in those units too, so each party's accounting software rounds to the cent on its side.
What changes when the same percentages apply to many small payments?
When a percentage split is applied to every payment of a stream, rounding each payment separately drifts away from the split of the total, and when the amounts repeat the drift favours the same parties every time. The answer is either to split the period total once, or to track what each party is owed to date and pay the difference.
Take 100 payments of $49.99, split 55 / 30 / 10 / 5. The exact shares of one payment are $27.4945, $14.997, $4.999 and $2.4995. The largest-remainder method on a single payment gives $27.49, $15.00, $5.00 and $2.50, which adds up to $49.99. Repeat it 100 times and the lead firm has received $2,749.00, the second firm $1,500.00, the specialist $500.00 and the introducer $250.00.
Now split the total of $4,999.00 once. The shares are $2,749.45, $1,499.70, $499.90 and $249.95. Over 100 payments, the per-payment method has paid the lead firm $0.45 too little, and the three others $0.30, $0.10 and $0.05 too much. On every single payment the lead firm's fraction was the smallest, so it never received a leftover cent.
A pull-based splitter contract avoids the problem by design: it computes what a recipient is owed as a share of everything the contract has ever received, minus what that recipient has already withdrawn, so no rounding is repeated. The same cumulative method works in a spreadsheet: each transfer is the party's share of the total received to date, minus what that party has already been paid.
Where does Shaka fit among these options?
Shaka is one onchain payment router. Each party's share is set as a percentage of the deal, each recipient can sign that share before the client pays, the client pays once through a payment link, and every party is paid its share at the same moment, in one transaction. Shaka routes the amount and never holds it.
The destinations are fixed and signed before the payment, so the split cannot be redirected at the last minute. Signing costs the parties nothing. The payment is onchain and final, every party can see that the others were paid, and the record of who was paid what stays available onchain. A deal has at most 20 recipients.
It does not fit every case covered here. Shaka is not a payment processor, a payroll tool, a bank or an escrow service. A split that has to be paid into bank accounts, a card-based stream of small sales, or a royalty calculated after a period closes belongs to the other families. Because shares are percentages of the deal, an arrangement with expenses reimbursed first or with tiers has to be worked out by the parties and expressed as plain percentages for that deal before anyone signs. And a final payment suits a deal whose amounts are settled, not one the parties expect to adjust afterwards.
How do you choose a way to pay several parties by percentage?
The choice depends on four things: whether the split is a one-off or a stream, whether the amount due is known at the moment of payment, how the recipients need to be paid, and whether the parties are comfortable with one of them holding the money. No family wins on all four.
- A handful of occasional splits between people who trust each other, paid to bank accounts. A spreadsheet and manual transfers are enough, provided the sheet works in cents and uses a remainder rule.
- The same amounts on the same dates. A bank standing instruction suits fixed sums. It stops being useful the day the amount varies.
- Many card or online sales, each to be shared by rule. A processor's split-payment feature applies the rule per sale. Check which account bears the processing fee, the payout schedule, and the onboarding each recipient must complete.
- Shares that depend on a period's results. Revenue-share or royalty software is the family built for statements, adjustments and later payouts.
- A standing split of everything sent to one address, among recipients who hold wallets. An onchain splitter contract does this. Ask whether its shares can be changed, and whether it pulls or pushes.
- A deal with a known amount, where each party wants its share fixed beforehand and paid at the same moment as the others. An onchain payment router does this in one transaction. It requires every recipient to accept an onchain payment, and the amounts to be settled before the client pays.
Whatever the family, the agreement still has to state the amount the percentages apply to, the order of any deduction, and the rule for the cents left over. A tool applies a rule; it cannot tell which rule the parties meant.
