♠ ♥ ♦ ♣

How the poker settlement works

The settlement arithmetic, explained
← Back to the ledger

How the settlement is calculated

Home Poker Ledger takes two numbers per player — what they put in and what they took out — and turns them into the shortest list of payments that settles the table. This page explains exactly what it does with those numbers, because a tool that handles other people's money should not be a black box.

Step one: reduce everyone to a single number

Every player's position is one figure: net = cashed out − total bought in. Buy-ins are kept as separate entries rather than a running total, so the record still shows who rebought and how often, but for settlement purposes only the sum matters.

A player who bought in twice at $20 and finished with $65 has a net of +$25. A player who bought in once and busted has −$20. Nobody's net depends on anyone else's — that is what makes the rest of this tractable.

Step two: check the books balance

In a game with no house, the money that goes in is the money that comes out. Add every net together and the total should be exactly zero. If it isn't, something is wrong with the count, and no amount of clever settlement arithmetic will fix it.

So the calculator checks this first and tells you three things: whether there is a discrepancy, which direction it runs, and how much it is. It will not quietly distribute an error and present the result as if the night reconciled.

Step three: pair the biggest winner with the biggest loser

Once the nets sum to zero, the winners are owed precisely what the losers owe. Settling is a matter of matching them up, and there are many valid ways to do it. Most are needlessly tedious — six people making six separate transfers when three would do.

The calculator uses a greedy pairing. It takes the largest amount owed and the largest amount due, and settles the smaller of the two in a single payment. That always zeroes out at least one player, so each payment removes someone from the problem entirely.

With n players, this settles the table in at most n − 1 payments, and usually fewer. A six-handed game where three people won and three lost typically resolves in three or four transfers rather than nine.

A worked example

Four players finish at +$40, +$15, −$25, −$30. The largest debt (−$30) pays the largest credit (+$40), which settles $30 and leaves that winner owed $10. Then −$25 pays the remaining $10, leaving them owing $15, which goes to the +$15 player. Three payments, four players, everyone square.

Step four: the count that doesn't reconcile

When the chips don't match the buy-ins and you have already looked for the missing entry, someone has to absorb the difference. Splitting it equally across the table punishes people who lost money already. Charging whoever miscounted assumes you know who that was, and you usually don't.

The optional “Cover the gap from the top” setting puts it on the players who finished ahead, beginning with the biggest winner. They are the ones with winnings to give up, and a dent in a good night costs less than deepening somebody's loss.

The rule: nobody's placing changes

This is the constraint that makes the option worth using rather than doing it by hand, and it is the whole reason the arithmetic is not obvious. Whoever finished first still finishes first. Second is still second. Only the amounts move.

That is harder than it sounds. Take the obvious approach — put the whole gap on the biggest winner — and if the top two finished close together, the leader drops below second place. You have not settled the night; you have rewritten who won it.

How it actually decides

It grows the group one player at a time, and stops at the first size that works:

  1. Can the leader alone cover it and still finish above second place? If yes, they do, and nobody else is touched.
  2. If not, try the top two sharing it equally. Can they take half each and both stay above third?
  3. If not, the top three taking a third each. Then four. And so on, as far as it needs to go.

The first group that can absorb its share without anyone slipping below the player beneath them is the group that pays.

Worked examples

Alice finishes +$40, Bob +$32.

The detail that took the most care

When a gap does not divide evenly, somebody has to take the extra penny. That penny goes to the bottom of the paying group, never the top.

It sounds like a triviality and it is not: hand the extra unit to the leader and you can put them exactly one penny behind second place — the very outcome the whole rule exists to prevent. The cheapest possible violation of the constraint, and the easiest to miss.

When the gap outruns the winnings

If the shortfall is larger than everything the winners collectively won, no group can absorb it and stay ranked. The calculator then spreads it across everyone, zeroing out anyone who cannot cover their share and re-dividing what is left among the rest.

This is only reachable on a badly wrong count — if you get here, the real answer is that a buy-in went unrecorded, and it is worth another look before accepting the result.

Which side pays depends on which way the count is wrong

Everything above describes the commoner case: more chips on the table than money went in, usually a rebuy nobody recorded. The table is claiming money that was never paid in, so the winners cannot all be paid in full — and it is the winners who give up part of their win.

When the count runs the other way and the table is short, the same logic runs in reverse. The losers collectively owe more than the winners are claiming, so the biggest loser's debt comes down first, then the two biggest, and so on — under the identical constraint that nobody's placing changes.

Leave it off if you can find the error

The option is off by default, deliberately. A gap almost always means a rebuy nobody wrote down, and finding it is strictly better than distributing it: the books balance honestly and nobody gives up anything they won. Turn this on once you have genuinely looked and the money is still missing.

Cashing out a player who leaves early

A player who leaves at 11pm is one of the two commonest reasons a count will not reconcile. They count their chips, take their money, and the chips go back in the tray — and if nobody wrote the number down first, it can never be checked, because the evidence has been mixed back into the tray.

Each seat has a Cash out button for this. Enter their final count, press it, and three things happen:

Reopen reverses it if they come back or the number was wrong.

It also guards the second commonest mistake. Press Calculate settlement while some players are marked and others are not, and it names the ones still to be counted. Settling before everyone is down means money moves, then the last stack comes in wrong, and now you are unwinding payments as well as hunting an error.

The button changes no arithmetic whatsoever. The same numbers settle identically whether or not anyone presses it — it records where you are in the night, not what anyone is owed.

Rounding, and why yen and won behave differently

All arithmetic is done in the currency's smallest unit — cents for dollars, won for won — using integers, never floating point. This is not fussiness. Storing $20.10 as a decimal and adding it up sixty times produces a total that is off by a fraction of a cent, and a settlement that is off by a cent is a settlement someone will argue about.

Seven currencies are supported: KRW, USD, JPY, CNY, EUR, GBP and SGD. Won and yen have no minor unit, so the calculator shows no decimal places for them and rounds to whole units. Entering “20000” in KRW means twenty thousand won, not two hundred.

What it does not do

Every rule above is covered by an automated test suite of several hundred cases, including randomised tables checked to settle exactly and never to change anyone's placing. The arithmetic is not trusted because we say so; it is checked on every change.