The Tangled Web Problem
Four friends rent a cottage near Muskoka for the weekend. Over three days, different people pay for different things. Alex covers the Airbnb ($600). Sam buys groceries at Metro ($200). Jordan fills the tank ($100). Taylor grabs drinks at the LCBO and pays for dinner ($100). Total spending: $1,000.
Sunday afternoon, everyone's packing up and someone asks the question: "So... who owes what?"
This is the moment where most groups pull out the Notes app, start a messy spreadsheet, or just give up and agree to "figure it out later." The problem isn't that the math is hard - whether you're splitting a restaurant bill or a week at the cottage. It's that the obvious approach to tracking debts creates a tangle that gets worse with every transaction.
There are two fundamentally different ways to answer the "who owes what" question. One of them scales. The other doesn't.
Pairwise Debts: Simple Idea, Messy Reality
The instinct most people have is to track individual debts between pairs. Alex paid for the Airbnb, so Sam, Jordan, and Taylor each owe Alex $150. Sam paid for groceries, so Alex, Jordan, and Taylor each owe Sam $50. And so on for every expense.
After just four expenses across four people, you end up with a list like this:
- Sam owes Alex $150, Alex owes Sam $50
- Jordan owes Alex $150, Alex owes Jordan $25
- Taylor owes Alex $150, Alex owes Taylor $25
- Jordan owes Sam $50, Sam owes Jordan $25
- Taylor owes Sam $50, Sam owes Taylor $25
- Taylor owes Jordan $25, Jordan owes Taylor $25
That's twelve individual debt entries. You can simplify overlapping ones (Sam owes Alex $150 and Alex owes Sam $50 cancel down to Sam owes Alex $100), which leaves five separate debts to settle. Five Interac e-Transfers for a four-person weekend trip.
And this was a simple example with equal splits. Imagine the same group but with unequal room sizes, some meals where only three people ate, and a shared streaming subscription that only two people use. The debt list multiplies fast. For practical advice on handling these situations, see our guide on how to split bills with roommates.
The Scaling Problem
With four people, you have six possible pairs. With five friends on a trip, ten pairs. A bachelor party of eight? Twenty-eight pairs. Each new expense can generate a debt entry for every pair that includes the person who paid. The bookkeeping grows quadratically, which is a fancy way of saying it gets bad fast.
Some apps deal with this by running a "debt simplification" algorithm after the fact. They let the pairwise debts pile up, then crunch through the graph to reduce the number of transfers needed. It works, but it's solving a problem that doesn't need to exist in the first place.
One Number Per Person: The Net Balance Approach
Here's the alternative. Instead of tracking who owes whom, track one number per person: their net balance with the group.
The concept is straightforward. For each person, take what they paid for the group and subtract their fair share of all expenses. The result is positive if the group owes them money, and negative if they owe the group.
Back to the Muskoka example. Total spending was $1,000, split equally four ways, so each person's fair share is $250.
- Alex: paid $600, fair share $250. Balance: +$350
- Sam: paid $200, fair share $250. Balance: -$50
- Jordan: paid $100, fair share $250. Balance: -$150
- Taylor: paid $100, fair share $250. Balance: -$150
Four numbers. That's the entire state of the group. No pairs, no overlapping debts, no simplification step. And those four numbers always add up to zero ($350 - $50 - $150 - $150 = $0), which is a built-in sanity check that nothing was lost or double-counted.
Settlement in Three Transfers or Fewer
Settling up from net balances is mechanical. People with negative balances send money to people with positive balances until everyone reaches zero.
- Sam sends Alex $50
- Jordan sends Alex $150
- Taylor sends Alex $150
Three Interac e-Transfers and the trip is squared away. For any group of n people, you need at most n - 1 transfers to settle up completely. No algorithm needed.
Compare that with the pairwise approach, which produced five transfers before simplification. The net balance method reaches the minimal settlement directly because it never built up the unnecessary complexity in the first place.
The Full Picture: Refunds, Transfers, and the Real Formula
The basic formula (paid minus fair share) covers most situations. But real groups deal with more than just expenses. Someone gets a refund. Someone sends a partial settlement mid-trip. A deposit comes back. The full model accounts for all of these with four running totals per person.
The Four Components
- Paid: total amount you physically spent on behalf of the group, including any settlements you've sent
- Payable portion: your fair share of all group expenses (what you consumed or owe)
- Received: money that came back to you, whether it's a refund, a reimbursement, or a settlement from another member
- Receivable portion: your fair share of any group income (refunds or reimbursements that were split among members)
Your net balance: paid - payable portion - received + receivable portion.
If you only have regular expenses, this simplifies down to "paid minus your share," which is the basic version. The extra two components activate when money flows back into the group or between members.
A Full Example
Let's extend the Muskoka scenario. After the four original expenses, two more things happen: the Airbnb host refunds $80 to Alex (a booking credit, split equally among the group), and Jordan sends Alex $100 as a partial settlement via Interac e-Transfer.
Here's how each person's four components look after all six transactions:
Alex: paid $600, payable portion $250, received $180 (the $80 refund plus Jordan's $100 transfer), receivable portion $20 (their share of the refund). Balance: 600 - 250 - 180 + 20 = +$190.
Sam: paid $200, payable portion $250, received $0, receivable portion $20. Balance: 200 - 250 - 0 + 20 = -$30.
Jordan: paid $200 (the $100 for gas plus the $100 transfer to Alex), payable portion $250, received $0, receivable portion $20. Balance: 200 - 250 - 0 + 20 = -$30.
Taylor: paid $100, payable portion $250, received $0, receivable portion $20. Balance: 100 - 250 - 0 + 20 = -$130.
Balances still sum to zero: 190 - 30 - 30 - 130 = 0. The refund and the partial settlement were absorbed into the same framework without any special handling. Jordan's earlier $100 transfer reduced their balance from -$150 to -$30. No separate "who has already paid whom" ledger is needed.
The balance formula handles expenses, refunds, and settlements all in one pass. There is no separate reconciliation step.
Want to see your group's balances in real time?
ShareBills tracks the math so you don't have to. Log expenses, scan receipts, and settle up with one number per person.
Try ShareBills Free