Settle group debts in the fewest payments

The problem is the number of payments, not the amounts

By the end of a shared week nobody disagrees about the expenses. They disagree about nothing at all, in fact — they simply never settle, because the list of payments looks like homework. Five people and seven expenses generate twenty-eight small reimbursements, each one a bank transfer somebody has to initiate, and each one an opportunity for a payment to be forgotten, duplicated or sent to the wrong person.

Debt simplification — netting — solves the count rather than the amounts. Nobody ends up better or worse off by a penny. What changes is that a group of five stops owing thirty small favours and owes two transfers, which people actually make.

Netting: one number per person

The whole idea rests on a fact that is obvious once stated and is missed constantly: what you owe the group is a single number. Not a list of debts to individuals — one number.

You get it in two steps, for each person:

1. Paid. Add up everything that person paid out of their own pocket for the group.
2. Owed in shares. Add up that person's share of every expense they took part in.

Their balance is the first minus the second. Positive means the group owes them; negative means they owe the group; zero means they are finished. A person can have paid for four expenses and still owe money, and a person can have paid for nothing and owe nothing — both look wrong and are correct.

Once every person is a single signed number, the group is no longer a web. It is two lists: people who are owed money, and people who owe it, and the two lists total the same amount. Settling is now just moving that amount from one list to the other.

Why you never need more than one payment fewer than the people involved

Count the people whose balance is not zero, and call that number k. The group can always be settled in at most k − 1 payments. Not roughly: always.

The argument is short enough to check yourself. Take the person who owes the most and the person who is owed the most, and have the debtor pay the creditor the smaller of the two amounts. One of two things happens:

• If the debt was smaller, the debtor is now at zero and the creditor is still owed the difference.
• If the credit was smaller, the creditor is now at zero and the debtor still owes the difference.
• If they were equal, both are at zero, which is even better.

So every single payment removes at least one person from the problem, and the remaining balances still sum to zero, so the same step applies again. Repeat, and after k − 2 payments you are left with exactly two people whose balances sum to zero — one who owes X and one who is owed X. One more payment ends it. That is k − 1.

Two consequences worth keeping in mind. First, people whose balance is zero take no part in the settling at all, no matter how many expenses they were in or how much money passed through their hands. That is where the surprising results come from: a group of five where two people happen to come out even settles in two payments, because k is 3.

Second, k − 1 is a ceiling, not always the true minimum. Sometimes fewer will do, because subsets of balances cancel exactly — if Bo owes exactly what Cleo is owed, one payment clears both, and the greedy largest-to-largest rule may or may not spot it. Finding the guaranteed minimum in every case is a genuinely hard computational problem, equivalent to searching for subsets that sum to zero, and it grows unmanageable well before a group gets large. This matters much less than it sounds: the simple rule already gets you from twenty-eight payments to two or three, and hunting for the last theoretical transfer is not where the win is.

A five-person example, shown both ways

Five friends share a cabin for a long weekend. Every expense is shared equally by all five, and everybody paid for something — so on the face of it, everybody owes everybody.

The expenses total €1,200, so each person's shares total €1,200 ÷ 5 = €240.

Way one: everyone pays everyone

Reimburse each expense literally and each of the seven expenses produces four payments — one from each person who did not pay it — so the weekend is 28 separate payments. Bo sends Ada €120 for the cabin, Cleo sends Ada €120, Dev sends Ada €120, Eli sends Ada €120, then everyone sends Bo €28, then everyone sends Bo €20, and so on down the list. Nobody is going to do this.

The obvious first improvement is to combine payments between each pair of people. Ada's share of Bo's spending is €48 and Bo's share of Ada's is €120, so instead of two payments Bo simply sends Ada €72. Do that for all ten pairs:

Better — 28 down to nine — and still bad. Dev has four payments to make, Cleo pays two people and receives from a third, and the group has to keep track of all of it.

Way two: net each person to one balance

The balances sum to zero: +360 − 160 − 200 = 0. Bo paid for two expenses and Eli for two, and both come out exactly even, because what they spent happens to equal their own shares. They are done. They send nothing and receive nothing.

That leaves three non-zero balances, so k = 3 and the ceiling is two payments:

€200 + €160 = €360, exactly what Ada was owed. Twenty-eight payments became two, and not one person's position moved by a cent: Cleo was always €160 down and Dev always €200 down, in every version above.

The comparison, in one line: 28 literal reimbursements, nine pair-by-pair payments, two netted transfers — the same money each time.

The honest caveats

Netting is not free of downsides, and pretending otherwise is how people end up distrusting the numbers.

You may be asked to pay someone you never shared an expense with

In a larger group this is normal, and it feels wrong. If Cleo owed Dev, Dev owed Ada and Ada owed nobody, the netted answer can be a single payment from Cleo straight to Ada, and Cleo may never have been at the same table as Ada. Nothing has gone wrong: the chain of debts cancels, and a transfer along the chain is a shortcut, not a claim about who ate whose dinner. But it needs saying out loud. Show the group the balance table — which nobody ever disputes, because it is only two columns of their own numbers — and then the transfers. In that order, netting is obvious. In the other order it looks like the app inventing debts.

Some groups genuinely want the literal trail

If an expense is disputed, or somebody wants a record showing they reimbursed a specific person for a specific thing, the expense-by-expense payments are the point and netting destroys exactly the information being asked for. Housemates who keep a long-running tally often prefer it too, because the literal version survives someone moving out mid-month better than a netted snapshot does. Netting is an optimisation, and a group that declines it is not being irrational.

The practical details that trip people up

• Do not net across currencies. A balance is only a single number within one currency; netting euros against pounds bakes in an exchange rate that nobody agreed on. Settle each currency separately, or convert deliberately, say which rate you used, and accept the result is approximate.
• Record settlements as they happen. A netted plan is a snapshot. If two people pay and a third does not, and then somebody adds a forgotten expense, the plan changes — and unless the payments already made are recorded, they will be asked for twice.
• Fees and limits can beat the optimisation. If one transfer costs money and three do not, or a bank has a cap, the cheapest plan is not always the shortest one.
• Rounding still applies. Shares that do not divide exactly leave odd pennies. Round all shares but one and set the last to the total minus the others, so the column still sums to the expense.
• One person collecting is a third option. Everybody who owes pays one nominated person, who pays out the creditors. That is more payments than the minimum but only one person has to think, which for some groups is the real constraint.

Where Splitright fits

We make one of the tools this article describes, so read this section accordingly. Splitright does the netting above automatically: it keeps a balance per person and shows the settle-up list — the two transfers, not the twenty-eight — without anybody working it out.

It is free on iPhone, iPad (iOS 16.4 and later) and Android (7.0 and later), with no account, no email, no ads, no subscription and no tracking. One person creates a group, shares a six-character code, and everyone with the code opens the same group from their own phone. Each expense can be split equally, by exact amounts or by percentage, with participants chosen per expense, and you can mark a settle-up payment as paid once it has been made.

What it does not do: it does not move money, so the transfers themselves happen in your bank app as usual. There is no CSV or PDF export, no receipt scanning and no categories. It is not a backup, and there is no server-side recovery. And the group code is the credential: anyone holding it can open and edit that group, there is no per-person login, and one person's access cannot be withdrawn — so treat the code like a password.

• Download for iPhone
• Get it on Google Play
• See everything Splitright does

If your group needs export or an account-based ledger, another app is the better answer — our comparison page says which and why. Related: splitting costs on a group trip, splitting a restaurant bill and splitting rent and bills with housemates.

Common questions

How can five people who all owe each other settle in two payments?

Because what each person owes the group is a single number, not a list. Add up what somebody paid out, subtract the total of their shares, and you have one balance per person. Anybody whose balance is zero is finished and takes no part in the settling, however many expenses they were in, so a group of five with only three non-zero balances needs two transfers.

How many payments does a group need at most?

One fewer than the number of people with a non-zero balance. Have the largest debtor pay the largest creditor the smaller of the two amounts: that transfer always brings at least one of them to zero, so each payment removes at least one person from the problem, and the last person is cleared by the same transfer as the second to last.

Is it a problem that netting makes you pay someone you never shared an expense with?

It is arithmetically correct and socially surprising, so it should be explained rather than hidden. The transfer is not a claim that you ate that person's dinner; it is a shortcut through a chain of debts that all cancel. Show the group the balance table, which nobody disputes, before showing them the transfers.

When is the everyone-pays-everyone version better?

When the trail matters more than the effort: a group that is settling a disputed expense, one where somebody wants a record of who reimbursed whom, or one where a pair of people prefer to keep their money between themselves. Netting is an optimisation, not a rule, and a group that wants the literal payments is not doing anything wrong.