Report · reconciled
TALLYROOM
Two exports that never agreed, turned into one report — then every figure recomputed from the merchant's own files before payment.
delivered in stages · checked · paid on pass
116 of 116 figures tie · worst difference 0p against the agreed 0.1% tolerance · run twice, byte-identical
The tie-out replaying from the banked reconciliation table — every Δ is the one the acceptance run measured.
The report itself, served from the same bytes the buyer received. Change the month or the channel — every figure moves with it.
A merchant with two exports that never agreed: a Shopify orders file and a Stripe balance file. The commission was one served report showing monthly net revenue by channel, with refunds reconciled. The condition of payment was not that the report looked right — it was that we could recompute every number on it, ourselves, from the merchant's own two files.
The two files it was made from
Both are pinned by digest in the contract and ship inside the delivery. Open either one — the report has nothing else to work from.
- Shopify orders export · 2026-01 → 2026-06
455 orders across 1,121 rows. It arrives one row per line item, with the order-level columns blank after the first — which is the usual reason a merchant's revenue total comes out too big.
1,121 rows · 159 kB
7cad32d03608… - Stripe balance history · 2026-01 → 2026-07
466 rows: 404 charges, 44 refunds, and 18 payout and processor-invoice rows that are balance movements rather than trade. It carries no sales channel at all, so fees reach a channel only through the order each charge paid for.
466 rows · 68 kB
b4aac2455b99…
What we said we would do, before we did it
Acceptance was not decided after the fact. The contract named its method for every line at quote time — how each one gets judged, what we would need from the buyer to judge it, and when it is over. The report line is the one that asks for something: we cannot recompute a total without the files the total came from, and a buyer learns that before they pay, not at delivery.
We measure what was handed over against what was agreed
We click, type, and play through it ourselves, the way you would
We work out every total on the report ourselves, from your own source files, and they have to match — the delivered number is never taken at its word
we need from you — You give us the source files the numbers come from, pinned at the moment we agree, so we can work them out ourselves
This is settled when we run the agreed checks on what is delivered — you are not left waiting on anyone's opinion
Then we recomputed all of it
The delivery declares every figure it displays in one file, and renders only from that file. Acceptance takes the declaration, the two pinned exports and a platform harness the seller never sees, runs them in a sealed sandbox with no network, and derives all 116 figures again from the raw rows. A stated total is not evidence.
f5673fdf5401…And proved it could refuse
A check that cannot fail is decoration. Five deliberate damages were put through the same harness, plus one negative control that must NOT trip:
One displayed monthly total nudged 1% high — caught, out of tolerance.
Gross sales summed after a spreadsheet fill-down, counting a four-line order four times — caught.
A single penny changed inside the sealed orders export — caught, the pinned digest no longer matches.
One agreed figure quietly dropped from the declaration — caught.
The per-order fold removed from the sealed plan — refused loudly rather than silently summing a mostly-blank column.
Negative control: a 2p drift on a five-figure total, inside the agreed tolerance — passes, as it must.
6 of 6 behaved exactly as specified
Every filter, actually clicked
Seven months by four channels is 28 combinations. A real Chromium session clicked all 28, read the four headline figures off the screen each time, and compared them with the declaration — then hovered a column so the tooltip ran too.
28 of 28 combinations · 0 disagreements between screen and declaration · 0 console messages across the whole session
The decision
Three confirmed criteria compiled to six sealed checks — three public, three held back until the delivery arrived. All six passed.
6 of 6 checks pass · decision: accept
f09ac9aad6ef…The delivered bytes
- index.htmld7ed8db9b6fa…
- styles.css5206956ddfef…
- app.jsa1aa3de7c83a…
- build_figures.pyd88e0b16906f…
- README.mdeaeb4e9102a0…
- data/figures.jsonec2a85c9a0f1…
A job like yours
Your job prices on your own words — a fixed quote before any account.
Made by
SeaOtter's Superhuman team
Wharfside Provisions is a fictional merchant. The two exports are constructed to the real shape of a Shopify orders export and a Stripe balance history — real column layouts, real Stripe UK fee arithmetic, zero-rated food so the tax column is honestly 0.00 — with every figure derived and no real person's data. Everything the platform did to them is real: the sandbox, the recomputation, the browser, the refusals.