Paying each other back per expense blows up fast
Five friends throw a house party. A does the grocery run, B buys the drinks, C picks up the cake. If everyone now pays back whoever fronted each expense, the transfers pile up per payment, per person. In the example below, settling all five expenses one at a time takes 18 transfers. Even after cancelling out what each pair owes in both directions, all ten pairs still have something left, so ten transfers remain.
The number actually needed is four. Every round trip is money that never had to move. This guide opens up the calculation SplitPay runs internally and shows how those four transfers are derived. For how to keep records across a multi-day trip, see the travel expense splitting guide; here we stay on the math.
Worked example: a house party for 5, 31,000 yen total
| Payment | Amount | Paid by | For |
|---|---|---|---|
| Grocery run | 12,500 yen | A | Everyone |
| Drinks | 9,000 yen | B | Everyone |
| Cake | 4,200 yen | C | Everyone |
| Extra alcohol | 3,000 yen | A | A, B and D only |
| Paper plates & cleaning supplies | 2,300 yen | E | Everyone |
Costs shared by all five come to 28,000 yen; only the extra alcohol is limited to A, B and D. D paid nothing on the day.
The key move: collapse every debt into one number per person
The first thing the calculation does is throw away every "X owes Y" relationship. In its place, each person carries exactly one number.
Balance = what they actually paid − what they should bear
A positive balance means they are owed money (they overpaid); a negative balance means they still owe. To get what someone should bear, take each payment, divide the amount by the number of people it was for, and add that share to each of them.
These balances have a property that always holds: add them all up and you get exactly zero. A single payment hands a positive amount to the payer and negative amounts to the beneficiaries, and those two sides are the same total, so the sum stays at zero however many payments you stack up. Which means the reverse is a free check: if your balances do not sum to zero, something in the input is wrong.
Deriving the balances: what you should bear vs. what you paid
| Member | Should bear | Actually paid | Balance |
|---|---|---|---|
| A | 6,600 yen | 15,500 yen | +8,900 yen (receives) |
| B | 6,600 yen | 9,000 yen | +2,400 yen (receives) |
| C | 5,600 yen | 4,200 yen | −1,400 yen (pays) |
| D | 6,600 yen | 0 yen | −6,600 yen (pays) |
| E | 5,600 yen | 2,300 yen | −3,300 yen (pays) |
28,000 yen of shared costs ÷ 5 = 5,600 yen each. A, B and D, who shared the extra alcohol, add 1,000 yen for 6,600 yen. Both the "should bear" and "actually paid" columns total 31,000 yen, and the balances sum to 8,900 + 2,400 − 1,400 − 6,600 − 3,300 = 0.
Paying back per expense vs. netting the balances
Paying back per expense
10 transfersRepaying one expense at a time takes 18 transfers; cancelling each pair against itself still leaves something owed across all ten pairs
Netting the balances first
4 transfersA's 8,900 yen = 6,600 + 2,300; B's 2,400 yen = 1,000 + 1,400
Building the transfers: match the biggest to the biggest
Once the balances exist, all that remains is pairing them up. The whole procedure is this:
- Line up the negative balances (the payers), largest debt first
- Line up the positive balances (the receivers), largest credit first
- Match the two at the front and make one transfer for the smaller of the two amounts
- Drop anyone who hits zero, and move whoever is left to the next partner
Applied to the example: the payers are D (−6,600 yen), E (−3,300 yen) and C (−1,400 yen); the receivers are A (+8,900 yen) and B (+2,400 yen). D sends A 6,600 yen and drops out, leaving A at 2,300 yen. E covers that 2,300 yen, which clears A and leaves E still owing 1,000 yen. E sends it to B and drops out too, leaving B at 1,400 yen. C's 1,400 yen lands on it exactly, and everyone is at zero.
One credit can be filled by several debtors, and one debt can split across two receivers, but the procedure never changes. Taking the largest available pair every time without planning ahead is what computer science calls a greedy algorithm. SplitPay produces its settlement suggestions exactly this way.
There is a hard ceiling on the transfer count. If n people have a non-zero balance, you never need more than n − 1 transfers: each transfer zeroes out at least one person, and once everyone else is at zero the last person is at zero too, because the balances sum to zero. All five in the example carried a balance, so four transfers is exactly that ceiling, and less than half the ten needed to pay each other back directly.
Doing it by hand, in four steps
Write every payment into one table
Three columns: amount, who paid, who it was for. What matters most here is not missing any payment that covered only part of the group.
Accumulate each person's share
Divide each amount by the number of people it covered and add that share to each of them. When it does not divide evenly, settle the rounding rule before you continue; the options are covered in [how to handle leftover cents](/guides/rounding-rules).
Compute balances and confirm they sum to zero
For each person, take what they actually paid minus what they should bear, then add all of it up. If it is not zero you missed a payment or tagged the wrong beneficiaries. Fix it here, before pairing anything.
Match largest against largest
From the biggest debt to the biggest credit, transfer the smaller of the two amounts. Whoever hits zero leaves the list. Repeat until everyone is at zero.
Finding the true minimum is genuinely hard
In fairness, the greedy count is not always the theoretical minimum. Suppose five people hold balances of +4,000, +3,000, +2,000, −4,000 and −5,000 yen. Matching largest against largest produces four transfers, but if you connect the −4,000 straight to the +4,000 and split the remaining −5,000 between the +3,000 and the +2,000, three transfers do the job. Whenever a subgroup cancels out exactly, the count can drop.
So why not always search for the true minimum? Because finding every subset whose balances sum to exactly zero is the subset-sum problem, and the combinations to check explode as the group grows. Computer scientists call this NP-hard: a class of problems with no known method for solving them exactly in practical time as the input grows.
The house party balances above contain no exactly cancelling subgroup at all, so those four transfers really are the minimum. Expense groups run from a handful of people to a few dozen, and in that range greedy usually matches the minimum, missing by one or two at worst. Having the targets appear instantly is worth more than shaving off a transfer nobody would notice.
Total Spent
$73.00
Settlement
Common questions about the calculation
Q.How far can the number of transfers actually drop?
With n people holding a non-zero balance, n − 1 is the ceiling; the five-person example hit exactly that at four. Exactly cancelling subgroups can push it lower. Adding more payments never adds transfers. Only the number of people does.
Q.What if rounding leaves the balances slightly off zero?
Decide the rounding rule first, then recompute the balances from the rounded figures. Splitting to the smallest unit and letting one person absorb the extra unit always makes the totals line up. The trade-offs are laid out in how to handle leftover cents.
Q.Does the same math work when people bear unequal shares?
Yes. Only the "should bear" figure changes; balances and the matching step behave identically. For splits where seniors pay more and juniors pay less, see tiered expense splitting.
Q.My hand calculation disagrees with the app. Why?
Usually it is when the rounding happens: rounding each item before adding differs from adding first and rounding once. A different set of transfers is not a discrepancy at all, as long as each person's balance matches. There is often more than one correct way to route the money.
Key points
- Settlement starts by discarding who-owes-whom and collapsing each person into a single balance
- Balance = what they paid − what they should bear. The balances always sum to zero, which doubles as a free check
- Matching the biggest debt to the biggest credit, greedily, is enough to build the transfers
- With n non-zero balances you never need more than n − 1 transfers; the 31,000-yen example closes in four, not 18 or 10
- Computing the exact minimum is NP-hard, but at expense-splitting group sizes greedy is off by at most a transfer or two