SumFair
  1. Home
  2. Mobile app

The SumFair mobile app, screen by screen

Mockups of the iPhone app in the same design as this site, following the product flow: scan, share, claim, settle, then group management and the trip ledger on top. Guests use the same screens in their phone browser.

Restaurant mode

Host screens are 1–5 and 9–11; guests see 6, 7, 8 and 10 in the browser without installing anything.

1 · Home (host)Two primary actions from the spec: Split a bill and Start a trip. Recent bills are visible without an account; an optional account only adds history and sync.
2 · Scan the receiptDetects the paper, corrects perspective, accepts several photos of one long receipt and images from the gallery (spec §6.2, §7).
3 · Check the numbersThe reconciliation engine compares items + fees against the printed total and highlights low-confidence lines; every field is tap-to-edit (spec §9, §10).
4 · Tip and serviceTip is derived from receipt total vs amount paid, or entered directly; proportional by default, with equal, custom and exclude options. Mandatory service stays a separate line (spec §17–19).
5 · Share the QR codeRandom, unguessable token in the link; host can regenerate or expire it. Joins and claims appear in real time (spec §11, §48, §59).
6 · Guest joins (browser)This is the whole guest onboarding: open the link, type a first name, continue. No email, phone number, password or app (spec §4.1, §12).
7 · Everyone claims their itemsTap to claim; shared items show who else is in and the per-person amount; quantities can be claimed one by one (spec §13–16). Conflicts are resolved by the server (§49).
8 · Split one itemThe four MVP methods per item: equal, exact, percentage, shares. Totals must reconcile to the item price before saving (spec §14, §15, §23).
9 · Finalize (host)Unclaimed items block finalization until handled; per-person totals sum exactly to the amount paid (spec §22, §77, §93).
10 · Guest's resultItemised breakdown including deposits, service and tip. No payment processing in MVP: copy amount or IBAN, then mark as paid (spec §24, §25).
11 · Settlement (host)Who owes whom, payment status, and an audit trail of every change. Reopening requires explicit confirmation and recalculates (spec §33, §47, §78).

Groups

Creating a group, managing who is in it, and finding it again. Both restaurant bills and trips are groups; a free account keeps them.

12 · Start a trip (create a group)A group is a name, dates and a base currency. People are added by link, not by email invitation (spec §26, §36).
13 · People in the groupHost controls from the spec: rename or remove participants, regenerate or expire the invite link, lock the session. A pre-added name is claimed when the person joins (spec §37, §59).
14 · Your groupsRestaurant bills and trips are both groups; a free account keeps them, plus saved groups and favourite people for the next time (spec §4.2, §70).

Trip mode

The same engine over many expenses, payers and currencies.

15 · Trip homeOne ledger: several expenses over days, more than one payer per expense, a currency per expense with the rate frozen at entry (spec §26–29).
16 · Add an expenseManual, receipt, transfer or refund; multiple payers on one expense; deterministic rounding shown up front (spec §27, §28, §23).
17 · Partial settlementThe differentiator from the spec: settle everything, until today, selected dates, expenses or people; each settlement becomes a checkpoint (spec §31, §32).
18 · Settlement checkpointDebt simplification into the fewest transfers, exact balances, locked expenses, and reopen with an audit trail (spec §30, §32, §33).

Want to try the real thing?

The web app runs the same flow in any phone browser.

Split a bill See how it works