manzil Beta
Splitting the Money

The arithmetic of settling up with the fewest transfers

Once a trip ends, who-paid-whom stops mattering. What matters is one net number per person, and those numbers always sum to zero. From there, a group of six can settle in five transfers or fewer, not fifteen, and there's a method you can do on paper.

Every group trip ends with the same question: who owes who. The instinct is to answer it the way the expenses happened, one payment at a time. Priya paid for the cabs, so Arjun owes her a share. Arjun paid for dinner, so Priya owes him a share. Multiply that by a week of trip and however many thousands the whole thing cost, and you get a tangle nobody wants to unpick by hand. Worse, it isn’t even the right way to think about the problem.

Forget who paid whom, think in net balances

The thing that actually determines who pays who at the end is not the history of who covered what. It’s a single number per person: how much they paid in total, minus how much they were supposed to pay based on their share of everything. That number is their net balance. Positive means the group owes them; negative means they owe the group.

Every net balance in the group sums to exactly zero, always. Money didn’t leave the group, it just moved around inside it, so whatever the creditors are owed in total is exactly what the debtors owe in total. Once every expense is logged and split, which is what agreeing one system before the trip starts buys you, the list of transactions stops mattering. You need six numbers.

A worked example: six friends, one trip

Say six friends, Priya, Arjun, Meera, Dev, Kabir and Sana, come back from a trip with these net balances, after every expense has been split evenly (the simplest of the four ways to split a bill, and the easiest to check by hand):

Check the sum: 4,800 + 2,200 + 1,000 minus 1,500, 2,800, 3,700 equals zero. Good, the split was done correctly.

The naive way settles this the way it happened: each debtor pays back roughly whoever they remember owing. It’s the instinct that works fine for one dinner, settle the thing you just paid for, right then. Applied to a whole trip’s worth of expenses, if Dev, Kabir and Sana each try to pay something to each of Priya, Arjun and Meera to roughly balance out, you can easily land at seven, eight, even nine separate transfers, several of them tiny, round-trip amounts that barely move the needle and are easy to get wrong or forget.

The minimum-transfer way asks a different question: what is the smallest number of payments that clears every balance to zero? Match the biggest creditor against the biggest debtor, each round, and this is what falls out:

  1. Sana pays Priya ₹3,700 → Sana clears, Priya has +₹1,100 left
  2. Kabir pays Arjun ₹2,200 → Arjun clears, Kabir has -₹600 left
  3. Dev pays Priya ₹1,100 → Priya clears, Dev has -₹400 left
  4. Kabir pays Meera ₹600 → Kabir clears, Meera has +₹400 left
  5. Dev pays Meera ₹400 → both clear

Five transfers, for six people, against a naive approach that could easily hit seven or eight small payments going back and forth. Every one of those five transfers clears at least one person’s balance to exactly zero, so nothing is left half-settled or repeated. Each is also one person opening one app once: in India that means a UPI payment, and UPI on a group trip covers what makes one land cleanly, while a group settling anywhere else uses whatever rail they already move money on.

The method: match the biggest creditor to the biggest debtor

You don’t need software to do this, though it helps. The rule a human can run on paper:

Each round clears at least one person completely, so a group of n people never needs more than n minus one transfers, five for six friends, and usually fewer once amounts happen to cancel out neatly, the way Arjun’s did above.

It isn’t the mathematical minimum, and that’s fine

Finding the absolute smallest possible number of transfers for an arbitrary set of balances is what’s known as a hard problem in general, the kind where the only guaranteed way to find the true optimum is to check a large number of possible groupings against each other. For a trip with six or eight or even fifteen friends, that’s not worth solving exactly. The greedy largest-to-largest method above lands on the true minimum or within a transfer of it essentially every time, and that one possible extra transfer never changes anyone’s evening. Good enough beats optimal, if optimal costs an hour of computation nobody asked for.

Why the amounts have to be exact, not close

There’s a quieter trap in all of this: doing the arithmetic in rupees and paise as decimal numbers. Split ₹1,000 three ways and you get ₹333.33 repeating, and if every expense in a trip gets rounded independently to the nearest paisa, those tiny roundings drift. By the end of a trip with thirty expenses, the six balances might not sum to zero at all, they’ll be off by a rupee or two, and now somebody’s settle-up plan has a phantom amount nobody can explain. The fix is to never touch a rupee as a decimal at all: track every amount in whole paise as a plain integer, and only convert to rupees for display at the very end. It’s the same discipline as counting cash instead of estimating it.

This is exactly the computation manzil runs for you once a trip’s expenses are logged: it tracks every split in whole paise, works out the net balance per person, and hands the group the minimum-transfer plan directly, so nobody has to run the largest-to-largest method by hand at a table after a long trip. In India it turns each line of that plan into a tap-to-pay link. It’s invite-only for now, though manzil itself is free to download on iOS and Android while you wait on a code. Either way, the arithmetic above is the thing worth carrying: stop thinking in who-paid-whom, and settle the net.