Every bill-splitting app has a button that promises to make settling up painless: simplify debts. Tap it and a tangle of who-owes-whom collapses into a short list of transfers — the fewest possible. It feels like the whole problem, solved. It isn’t. The button optimizes one number: how many payments the group has to make. It has nothing to say about the number that actually decides whether you get your money back — how many of those payments ever happen.
Those are two different variables, and the second is the one that hurts. A settlement can be mathematically perfect — the provable minimum number of transfers — and still leave you short, because the person who owes you saw the request, meant to pay it, and never did. Minimizing the count of payments does not minimize the count of unpaid payments. Getting paid back is not a math problem the way apps treat it. It’s a friction problem, and friction lives in the handoff, not in the graph.
Settlement bound: Verhoeff (2004). Redemption gap: Sunstein, “Sludge and Ordeals” (2019).
What does “simplify debts” actually optimize?
It minimizes the number of separate transfers needed to zero everyone out. That’s a real, well-defined problem, and it’s the one our companion piece on settling in the fewest payments works through in full: you don’t pay back every IOU, you pay back each person’s net balance, and a group of n people never needs more than n − 1 transfers to do it. A weekend that generated a dozen little debts settles in two. That collapse is genuinely useful, and the math behind it is elegant.
It’s also computationally serious. Tom Verhoeff, the computing scientist who framed this as a clean problem, showed that finding the absolute fewest transfers is NP-hard — equivalent to a notorious problem called 3-Partition, “NP-complete in the strong sense.” For a big, messy web the true optimum is out of practical reach, so a simplification feature leans on a fast heuristic that lands near it. Either way, the objective is fixed and unambiguous: fewer transfers. Notice that’s a choice of target, not the only one. Minimizing the total dollars that change hands is a different — and computationally easy — problem, the least-cost-flow cousin of the transportation problem Frank Hitchcock posed in 1941, which a computer solves in an instant. Simplification optimizes the transfer count anyway, because a short list is what looks like a solved problem. A live free competitor, Spllito, states it outright — its calculator “instantly calculates the optimal settlement… minimizing the total number of transactions needed.”
Debt simplification’s whole job: take a group’s up to n(n − 1) possible IOUs and clear them in at most n − 1 transfers — often fewer. A beautiful reduction — of a number that was never the thing standing between you and your money.
Source: Tom Verhoeff, “Settling Multiple Debts Efficiently,” Informatics in Education (2004); 3-Partition hardness per Garey & Johnson, Computers and Intractability (1979); transportation problem, Hitchcock (1941); competitor claim: Spllito.
Why the payment count isn’t what strands your money
Because a computed settlement is a to-do list, and to-do lists don’t execute themselves. Whether an item on it gets done depends on how much friction sits between intention and action — and paying back a friend is the exact kind of task that friction devours. It has an immediate cost (open an app, type an amount, confirm) and a diffuse, delayed benefit (being square, someday). That shape is the textbook trigger for procrastination.
The economists Ted O’Donoghue and Matthew Rabin modeled precisely this. People with present-biased preferences — all of us, to some degree — systematically put off activities that carry an up-front cost, even when they fully intend to do them. In their framing, “naive people procrastinate immediate-cost activities,” and “a small present bias can severely harm only naive people” when the cost lands now and the payoff later. A $40 Venmo request — say, your share of the table — is a small immediate cost with a later, fuzzy reward. Applied to that shape, the model points to a familiar fate: later.
The legal scholar Cass Sunstein gave this friction a name — sludge — and showed how little of it is needed to stop a wanted action cold. His clearest example isn’t a bill; it’s a mail-in rebate. A rebate is free money the person actively wants, yet across markets redemption rates run just 10 to 40 percent. In one study, people said it was about 80 percent likely they’d redeem within the 30 days they were given. The actual rate was 31 percent. Nobody decided not to be paid; the gap between 80 and 31 opened up between wanting the money and doing the small task to get it — the effort of the handoff, plus the present bias that keeps pushing it into what Sunstein calls “Laterland,” the foreign country where deferred tasks go and never return. A friend’s IOU isn’t a rebate — it carries a social weight a rebate doesn’t, which cuts the other way. But the mechanism is the same one: a small effort wedged between intention and a wanted payment is enough, on its own, to strand it.
The number that matters: what you actually collect is the payment count times the odds each one gets made. Simplification shrinks the first term. Friction sets the second — and a settlement that ignores it can be count-optimal and collection-poor at the same time.
Sources: O’Donoghue & Rabin, “Doing It Now or Later,” American Economic Review (1999); Sunstein, “Sludge and Ordeals,” Duke Law Journal (2019).
The graph-optimal screenshot: an optimizer aimed at the wrong target
Watch what happens when an app optimizes the count and stops there. Spllito computes the minimal settlement — the mathematically correct answer — and, in its own words, shows you “exactly who needs to pay whom and how much.” Then it hands that answer off the only ways it can: a WhatsApp message, copied text, or a saved image. There is no Venmo, PayPal, Zelle, or Cash App integration on the page at all — the settlement leaves as a screenshot. So the output is a list to read, not a payment to make. The transfer itself — opening a payment app, entering the amount, sending it to the right person — is left entirely to you, reconstructed from that image by hand, later.
The optimizer did its job perfectly and left collection exactly as hard as it started. A computed figure can’t be tapped: it isn’t an amount field, a recipient, and a button. Every step the debtor has to rebuild — which app, what amount, to whom — is another place for present bias to say “in a minute,” and the minute becomes Laterland. Minimizing the number of transfers while leaving each transfer a manual re-entry is a weaker trade than it looks, because the count was never the binding constraint.
Fewest transfers
A provably minimal list of who pays whom — down to the n − 1 ceiling, computed in an instant. The tangle disappears on screen.
Friction per transfer
How many taps, re-keyed amounts, and app-switches stand between the debtor’s intention and a completed payment — and how fresh the debt still is when they see it.
Fewer, bigger payments can settle worse than more, smaller ones
There’s a second twist hiding in “simplify.” Netting doesn’t just cut the number of payments — it changes their shape. Many small, obvious debts get merged into fewer, larger, less-obvious ones. Simplification can even route you to pay someone you never actually transacted with, because the algorithm cares only that the balances net out, not that the payment makes intuitive sense. (That legibility cost is its own problem.) But even setting trust aside, a larger ask is plausibly easier to defer than a small one — a bigger immediate cost is a more aversive task, and aversive tasks are exactly the ones a present-biased mind puts off.
Concentration also concentrates risk. Spread across six small tappable requests, one person flaking costs the group one small share. Collapsed into two large netted transfers, a single default strands a big chunk of the total — and the largest transfer is also the easiest to keep putting off. The count went down; the fragility went up.
It helps to remember what a group check actually is. On splitty’s own US receipts, the most-ordered line items are individual drinks — Diet Coke, espresso martinis, water — not shared plates, and nearly half of group checks top $150. A real bill is a stack of small, individually owned items, each one recognizable to the person who ordered it. Netting takes that legible stack and rewrites it as a couple of round numbers nobody can trace back to a taco or a martini — trading exactly the recognizability that gets a share paid for a lower transfer count.
of group restaurant checks on splitty’s US receipts top $150 — and they’re built from many small, individually ordered items (the most common are drinks). That granular structure is what makes each share payable, and what “simplify” blurs into a few opaque totals.
Source: splitty first-party receipt data (US-leaning scanned receipts; shares only, not extrapolated to any population).
None of this means the fewest-payments math is wrong — it’s beautiful, and worth knowing. It means the math answers a question that was already easy (how few transfers could settle this) instead of the one that’s actually hard (how do we make the transfers occur).
How to actually get a group to settle up
If friction is the binding constraint, then getting paid back is an exercise in removing friction — not in shaving transfers. Three moves do almost all the work, and none of them require a smarter settlement algorithm.
Make the payment a tap, not a re-entry
The biggest lever is the handoff. A request that arrives pre-filled — right amount, right recipient, in the app the payer already uses — turns settlement into one confirmation. A number to re-enter turns it into a small data-entry chore, and chores get deferred. Never hand someone a figure they have to copy.
Collect while the debt is still fresh
Present bias is a clock. The longer a debt sits, the more it fades into Laterland and the less anyone remembers what it was for. Send the ask at the table, not next week. A debt settled the night it forms never gets the chance to become the awkward IOU nobody wants to bring up.
Keep each share small, obvious, and attributable
A share someone recognizes — “your two tacos and a margarita” — gets paid faster than an abstract netted figure they can’t reconstruct. Don’t let simplification merge clear small debts into one opaque large one just to drop the transfer count by one.
Where does splitty fit in all this?
splitty optimizes the variable the “simplify debts” button ignores. It doesn’t run a netting algorithm over a pile of accumulated IOUs, because it never lets the pile form: one person pays the check, splitty reads the receipt, assigns each item to the people who shared it, and sends everyone else a single pre-filled request straight back to that one payer. That structure — one creditor, everyone else owing only them — is already the n − 1 minimum. No simplification needed, because there’s nothing tangled to simplify.
But the shape is the easy half. The half that gets you paid is that each of those requests is a tap, not a number to re-key — pre-filled with the exact amount, opening in the app each person already uses, sent while the bill is still warm. splitty doesn’t move the money or hold a balance; it removes the friction and the delay that otherwise turn a settled split into an unpaid one. Fewest payments is a side effect. Payments that actually happen is the point.
Simplification optimizes the number of transfers
→splitty’s one-payer split is already the minimal count — so the whole optimization is free, and attention goes to the part that’s actually hard.
Whether a payment happens is set by handoff friction and present bias
→splitty sends a pre-filled, tappable request in the recipient’s own app — the lowest-friction handoff there is — instead of a number to re-key later.
A debt’s odds of being paid decay the longer it sits
→splitty settles at the table, before the debt drifts into Laterland — not in a ledger you reconcile weeks later. Splitwise tracks the tab; splitty closes it.
The next time an app offers to “simplify” your debts, take the math — it’s real and it’s free. Just don’t mistake it for the finish line. The tangle on the screen was never what kept you from getting your money back. “I’ll Venmo you later” was.
FAQ
Debt simplification — quick answers
Straight answers about what “simplify debts” does, what it doesn’t, and how to actually get a group to pay up.
01 What does the “simplify debts” feature actually do?
It minimizes the number of separate payments a group needs to settle up. Instead of paying back every individual IOU, it nets each person to a single balance and finds a short list of transfers — at most n − 1 for n people — that zeroes everyone out. It's a genuine optimization, but the only thing it optimizes is the count of transfers. It says nothing about whether those transfers actually get made.
02 Does simplifying debts help you get paid back faster?
Not by itself. Getting paid back is governed by friction, not by how few payments there are. A settlement handed off as a computed number — a figure with no tappable payment link — forces each debtor to re-enter the amount in a separate app, later. Behavioral research on present bias (O'Donoghue & Rabin) and 'sludge' (Sunstein) shows that exactly this kind of small immediate effort is what makes wanted payments get deferred indefinitely. Fewer payments delivered with more friction can settle worse than more payments delivered as one-tap requests.
03 Why do people forget to pay back money they intend to pay?
Because paying back a friend is a task with an immediate cost (open app, enter amount, confirm) and a delayed, diffuse benefit (being square). Present-biased preferences make people systematically procrastinate immediate-cost tasks even when they fully intend to do them. Sunstein's rebate example shows the size of the gap: people estimated they were about 80% likely to redeem a rebate within 30 days, but only 31% actually did. The intention was real; the friction won.
04 Can fewer payments ever be worse than more payments?
Yes. Netting merges many small, obvious debts into fewer, larger, less-recognizable ones — and larger payments are more aversive, so present bias defers them harder. Concentration also concentrates risk: if a settlement collapses into two big transfers and one person flakes, a large chunk of the total is stranded, versus one small share when the same money is spread across several tappable requests. The lower transfer count can mean higher fragility.
05 What actually makes a group settle up?
Removing friction from the handoff and collecting while the debt is fresh. A request that arrives pre-filled with the right amount, opening in the app the person already uses, turns settlement into a single tap. Sending it at the table — before the debt fades into what Sunstein calls 'Laterland' — beats reconciling a ledger next week. Keeping each share small and recognizable ('your two tacos and a margarita') beats an abstract netted figure nobody can reconstruct.
06 Is this different from splitting the bill fairly or the fewest-payments math?
Yes — three different steps. Splitting fairly decides how much each person owes. The fewest-payments math decides the minimum number of transfers once those amounts exist. This is a third question: whether those transfers actually happen. A split can be fair and a settlement can be count-optimal, and you can still be unpaid, because completion is a friction problem the first two steps don't touch. splitty handles the fair split from a photo and sidesteps the tangle by sending each share as a pre-filled request back to one payer.
