In this article
A spreadsheet with manual transfers is the right way to split a payment when the rule is decided or adjusted after the money arrives, and an automated payment router is the right way when every share is a percentage agreed before the client pays. The criterion that separates the two methods is the moment the split is carried out: after receipt, by one person, transfer by transfer, or inside the client's payment itself.
Everything else follows from that moment. With the spreadsheet, one party receives the whole amount, works out what each of the others is owed and sends it, so the method can express any rule and depends on that one party doing it correctly and on time. With a router, the percentages are fixed first and the payment carries them out, so no one holds the total and no one can adjust anything afterwards. Neither method is the better one in general: it depends on the shape of the rule, on how the client pays and on what the other parties need to verify.
Worked examples of this article: one $48,000 payment shared 40 / 25 / 15 / 12 / 8 among five parties. The minutes per task are illustrative assumptions stated in the text, not measurements.
What is the real difference between a spreadsheet split and a payment router?
A spreadsheet split is a calculation followed by separate transfers made by whoever received the client's payment, while a payment router applies percentages agreed in advance to the client's payment and pays every party in the same operation. The spreadsheet method is a procedure a person runs; the router is a rule the payment follows.
The spreadsheet method has three parts: a file that holds the rule, a bank account that holds the money, and a person who connects the two. A router collapses the three into one object, the deal, which states the amount, the recipients and their percentages. Whatever the deal cannot state, the router cannot do.
The table below puts both methods on the same eight criteria. The router column describes the family of onchain payment routers, the kind of automated router that pays every party in one transaction.
| Criterion | Spreadsheet and manual transfers | An onchain payment router |
|---|---|---|
| Who holds the money | The party who received the client's payment, until each transfer leaves | No one: the payment is routed to the recipients, not parked |
| When each party is paid | When the holder sends each transfer, one after the other | All at the same moment, when the client pays |
| Who can change the split after payment | The holder, alone, by sending different amounts | No one: the payment is final |
| Error exposure | At every payout, in formulas, copies and each typed transfer | Before the payment, in the amount, destinations and percentages entered |
| Time spent per payout | Grows with the number of recipients | About the same whatever the number of recipients |
| What each party can verify | Their own receipt, once it arrives; the rest only if the holder shares the file | Their share before payment, and that every party was paid after |
| Rules it can express | Any rule a formula can hold: tiers, expenses, caps, exceptions | Percentages of the deal amount, fixed beforehand |
| Cost in kind | Free software, a bank fee per transfer where the bank charges one, and the holder's time | The router's fee, and the condition that the client can pay through it |
What does the spreadsheet and manual transfer method do well?
A spreadsheet with manual transfers costs nothing to start, expresses any sharing rule, works with every bank and every payment method, and is understood by everyone involved.
It is free and already there. Every party has spreadsheet software and a bank account. The client pays one invoice the way they always pay.
It can hold any rule. A split is not always a set of percentages. A waterfall pays one party back first, then shares what is left. Expenses come off the top before anyone's percentage applies. A tier changes the rate above a threshold. A formula can state every one of these, and a note in the next column can explain why.
It handles the exception decided after the fact. When the client pays short, pays late, asks for a credit or disputes one line, the person holding the money can adapt on the spot. No automated rule set before the payment can know about a decision that had not been made yet.
It works across payment methods and currencies. The incoming payment can arrive by any rail the holder's bank accepts, and each outgoing transfer can use whatever suits that recipient.
Where does the spreadsheet method stop?
The spreadsheet method stops at the point where the other parties need certainty and not just a correct calculation: the money sits with one person, each transfer is a separate act that can be late, wrong or forgotten, and nobody else can verify anything until they are paid.
One party holds everything. Between the client's payment and the last outgoing transfer, the full amount is in one account. If that account is frozen, overdrawn by an unrelated charge, or belongs to a business in difficulty, the other parties are creditors waiting in line. Depending on the country, money that lands in your account before being passed on can also raise bookkeeping and tax questions about whose revenue it was, which is a point to settle with an accountant.
Every transfer is its own event. Four recipients mean four chances to mistype an amount, choose the wrong saved payee, hit a daily limit or simply postpone until tomorrow. A bank transfer sent to a wrong account is hard to bring back, and the sender usually discovers it when the intended recipient asks where the money is.
The others see nothing until they are paid. A recipient cannot check that the client has paid, what amount arrived, or what the other parties received, unless the holder chooses to show the statement and the file.
What does an automated payment router do well?
An automated payment router removes the holding period and the manual transfers: the client pays once, and every party receives their share at the same moment, according to percentages each party could read before the payment.
Nobody holds the total. The router routes the payment to the recipients. There is no intermediate balance in one party's account.
Payment is simultaneous. There is no order of payment, and so no last in line.
The split is known and agreed beforehand. Each recipient sees their own percentage before the client pays, and with a router that supports it, signs it. A disagreement about shares surfaces before any money has moved.
Each party can verify the result alone. With an onchain router, the record of who was paid what is visible to all the parties, without asking the organiser for a statement.
The work no longer grows with the number of recipients. There are no outgoing transfers to key in afterwards.
Where does a payment router stop?
A payment router stops where the deal stops being a fixed set of percentages: it does not handle a rule decided after the fact, it requires that the client can pay through it, its payment is final, and it has a ceiling on the number of recipients.
Shares must be percentages agreed in advance. A router applies percentages to an amount. A waterfall, an expense to reimburse first, or a tier has to be converted into percentages of this particular deal before the client pays, which means doing the calculation somewhere else first, often in a spreadsheet. If the numbers that drive the split are not known until later, a router cannot carry it.
The client must be able to pay through it. With an onchain router, the client pays onchain and each recipient is paid onchain. A client who only pays by bank transfer or card cannot use it, and the decision ends there.
Nothing is adjusted afterwards. A final payment cannot be rearranged when the client asks for a credit or one party's share turns out to be wrong. The correction is a new, separate payment between the parties concerned. Every check a spreadsheet user might do after receipt has to be done before the payment: the amount, each destination, each percentage.
It does not hold money on a condition. A router that never holds funds cannot keep part of a payment back until a milestone is met or a dispute is settled. A group that needs funds held pending a condition needs a service built for holding, such as an escrow service.
There is a recipient limit. A router has a ceiling on the number of recipients per deal. A distribution to a hundred holders is a mass payout, which is another family of tools.
What does the same $48,000 payout require done both ways?
For one $48,000 payment shared among five parties, the spreadsheet method takes five payments and about 45 minutes of the holder's work, and a router takes one payment and about 20 minutes of the organiser's work, under the illustrative assumptions below.
The worked example: a client owes $48,000 for a project delivered by five parties. The agreed shares are 40% for the lead, who invoices the client, 25% for party B, 15% for party C, 12% for party D and 8% for party E. That gives $19,200, $12,000, $7,200, $5,760 and $3,840, which add up to $48,000.
The minutes are assumptions chosen to be plausible for a careful person, and you should replace them with your own. For the spreadsheet method: 5 minutes to confirm the receipt against the invoice, 10 to update the file and check the shares, 4 per outgoing transfer for four transfers, 2 per recipient to send a payment notice, and 6 to file the statement lines, 45 minutes in all. For the router: 10 minutes to enter the amount, the five destinations and the five percentages, 5 to check the total and confirm the destinations, 2 to send the payment link and 3 to save the payment record, 20 minutes in all. The middle path, described further down, is the spreadsheet for the calculation and one bulk bank file for the transfers: 5, 10, then 8 to export, upload and approve the file, 4 for one notice to everybody and 3 for filing, 30 minutes in all. Only the organiser's time is counted; with a router, each recipient also spends a moment reviewing and signing their own share.
| What the payout requires | Spreadsheet and manual transfers | Spreadsheet and bulk bank file | Payment router |
|---|---|---|---|
| Payments made | 5: one in, four out | 2: one in, one file of four transfers | 1: the client's payment |
| Who holds the $48,000 | The lead, until the fourth transfer leaves | The lead, until the file is processed | No one |
| When the four other parties are paid | One by one, after the lead acts | Together, after the lead acts | With the lead, when the client pays |
| Organiser's minutes (illustrative) | 45 | 30 | 20 |
The 25 minutes between the first and last column are not the main finding. The second and third rows are: in two of the three methods, $28,800 belonging to four other parties passes through the lead's account, and their payment date is the lead's decision.
Where can an error enter each method?
In the worked example, a value is typed or copied by hand in 16 places per payout with the spreadsheet method and in 11 places with a router; the difference that matters is that the router's 11 are all entered before the payment and can be reviewed by the parties they concern.
| Hand-entered value | Spreadsheet and manual transfers | Spreadsheet and bulk bank file | Payment router |
|---|---|---|---|
| Amount to share | 1 | 1 | 1 |
| Percentages | 5 | 5 | 5 |
| Rounding remainder and choice of file version | 2 | 2 | 0 |
| Destinations | 4 pasted, one per transfer | 0 per payout: stored payee list | 5, entered once for the deal |
| Transfer amounts | 4 retyped | 1 file export | 0 |
| Total per payout | 16 | 9 | 11 |
A holder who uses saved payees in online banking removes the four pasted account numbers and falls to 12. On the router side, the 11 values are exposed to review in a way the spreadsheet's are not: a recipient who signs their share has read their own percentage, and a destination fixed before the payment cannot be swapped at the last minute.
Four findings come up again and again when a payout file is reviewed.
- A percentage column that does not total 100. One row is edited and the others are not rebalanced. If party E's share is raised from 8% to 10% and nothing else changes, the column totals 102% and the file instructs $48,960 of payments from $48,000 received: $960 too much, which the holder absorbs or discovers at the last transfer.
- A rounding remainder with no owner. Shares rounded one by one can sum to a cent more or less than the amount received. The file needs a stated rule for who takes the remainder; without one, the difference lands silently on the holder.
- A stale copy. The payout is computed from an older file in which the shares were 45 / 25 / 15 / 10 / 5. The lead keeps $21,600 where $19,200 was due, party D receives $4,800 in place of $5,760 and party E $2,400 in place of $3,840: $960 and $1,440 short, the same $2,400 the lead kept too much. Every transfer is internally consistent, so nothing looks wrong.
- A wrong account number pasted. The amount is right and the destination is another recipient's, or an old account. This finding is the costly one, because recovering a transfer sent to the wrong account depends on the receiving side.
Which controls make a spreadsheet payout reliable?
Six controls remove most of the exposure of a spreadsheet payout: one master file, a total check on the percentages, a total check on the amounts, a stated remainder rule, a second look at destinations and a notice sent to every party.
- Keep one master fileStore a single file in one shared place, give every party read access, and never compute a payout from a copy. Write the date of the last change to the shares in the file itself.
- Check that the percentages total 100Add a cell that sums the percentage column and a visible warning when the result is not 100. In the example, 40 + 25 + 15 + 12 + 8 must show 100 before anything else is read.
- Check that the amounts total the receiptAdd a second cell that sums the computed shares and compares the result with the amount on the bank statement, not with the invoice. $19,200 + $12,000 + $7,200 + $5,760 + $3,840 must equal the $48,000 actually received.
- State who takes the remainderWrite the rule once, in words, in the file: which party receives or gives up the odd cent when rounded shares do not sum exactly.
- Verify each destination separately from the amountsRead each account number against a reference confirmed by the recipient through a channel you already trust, and treat any request to change an account as a new verification, never as a quick edit.
- Send every party the same noticeAfter the last transfer, send one message to all the parties with the amount received, each share and the date sent. A recipient who can see the whole payout can catch what the holder missed.
Where two people are available, the strongest control is to separate the roles: one prepares the transfers and another approves them. Some business bank accounts offer this as a two-approver setting.
How many hours a year does each method take from 5 payouts to 60?
Under the assumptions of the worked example, the spreadsheet method takes 3.75 hours a year at 5 payouts and 45 hours at 60, and a router takes about 1.7 hours and 20 hours, so the gap goes from about 2 hours a year to 25.
Horizontal axis: payouts per year. Only the organiser's time is counted. One-off setup, the recipients' own time and the time spent resolving an error are not included.
At 5 payouts a year, the time argument for changing method is weak: about 2 hours a year is not a reason to ask a client to pay differently. At 60 payouts, the spreadsheet method means 240 outgoing transfers a year keyed in by hand and 960 hand-entered values.
The chart leaves out the cost that does not scale smoothly: one transfer sent to the wrong account, or one payout computed from a stale copy, can cost more hours and more goodwill than a year of routine payouts.
Is there a middle path between the spreadsheet and a router?
The middle path keeps the spreadsheet for the calculation and replaces the one-by-one transfers with a single bulk payment file uploaded to the bank. It keeps the full flexibility of the spreadsheet and removes the retyped amounts, at 30 minutes per payout in the worked example, or 30 hours a year at 60 payouts.
Most business banking services accept a file that lists many transfers and is approved once. The formats are standardised. In the United States, the Nacha developer guide describes an ACH file as made of one or more batches, each made of one or more transactions, and closed by control records that carry a count and a dollar total. In Europe and many other regions, banks accept the customer credit transfer initiation message of the ISO 20022 standard; bank specifications for that file describe a header carrying the number of transactions and a control sum, which the bank checks against the content of the file.
What the bulk file changes: the four amounts are exported, not retyped; the four transfers are approved in one act, so the other parties are paid together and not in the order the holder gets to them; and the stored payee list replaces pasting. What it does not change: the lead still receives and holds the full $48,000, the other parties still wait for the lead to act, and they still cannot verify anything before they are paid. Bulk files are a business-banking feature, so the middle path suits a group whose lead already runs a business account that offers it.
Where does an onchain payment router such as Shaka fit?
Shaka is one onchain payment router: one payment comes in and every party is paid their share at the same moment, in one transaction, and it routes the funds without ever holding them. It fits a group whose shares are percentages agreed before the client pays, and it does not fit a split that has to be worked out after the money arrives.
Each party's share is set as a percentage of the deal, and each recipient can sign their share before the client pays, at no cost to the parties. The client pays once, through a payment link. The destinations are fixed and signed before the payment, so the money cannot be redirected at the last minute. The payment is onchain and final, every party can see that the others were paid, and a payment record can be kept for the file. A deal has at most 20 recipients.
The limits described earlier apply in full. The client has to be able to pay onchain. An expense or a waterfall has to be turned into percentages of the deal beforehand. A payment that is final leaves no room for a correction afterwards. Shaka is not an escrow service, a bank, a payroll tool or a card processor, and a group that needs funds held on a condition, or a client paying by bank transfer, is better served by one of those.
When should you keep the spreadsheet, and when should you switch?
Keep the spreadsheet while payouts are few, the parties trust the holder and the rule changes from one payment to the next; switch to a router when the shares are fixed percentages, the amounts or the number of parties make the holding period uncomfortable, and the client can pay through it.
| Your situation | Method that fits | Why |
|---|---|---|
| A few payouts a year among people who know each other well | Spreadsheet and manual transfers, with the six controls | The time gap is about 2 hours a year at 5 payouts |
| Expenses, a waterfall or tiers settled after the client pays | Spreadsheet, with manual transfers or a bulk file | The rule is not known when the payment is made |
| The client pays only by bank transfer or card | Spreadsheet, with manual transfers or a bulk file | The client cannot pay through an onchain router |
| Frequent payouts, a lead with a business bank account, a flexible rule | Spreadsheet and bulk bank file | Removes retyped amounts and pays everybody together |
| Fixed percentages, parties who do not know each other well, large amounts | Payment router | No one holds the total and each party can verify the payout |
| Parties who want their share agreed in writing before the work is paid | Payment router | Shares are read, and can be signed, before the payment |
| Part of the payment must wait for a milestone or a dispute | A service that holds funds, such as an escrow service | Neither method compared here holds money on a condition |
| More recipients than a router's limit | A mass payout tool or a bulk bank file | A router caps the recipients per deal |
Three questions settle most cases in order. Can the client pay through a router at all? If not, the choice is between manual transfers and a bulk file. Is the split a set of percentages you can state today, before the payment? If not, the spreadsheet stays, at least for the calculation. Would the other parties accept waiting on one person, with no view of the payment until their share arrives? If they would, the spreadsheet with its controls is a sound method. If they would not, the holding period is the thing to remove.
