← Payment Reconciliation Workbench
This workbench vs. reconciling in a spreadsheet
A VLOOKUP matches one payout to one deposit at one exact amount. It has no answer when the bank split a payout into two deposits, or posted one a few days later than you scanned for.
What a spreadsheet formula gets right
Pasting a payout export and a bank export into two sheets and running a VLOOKUP or MATCH on the amount column is the ordinary way anyone checks payouts against deposits, and for the common case it works: same amount, landed within a day or two, one row finds the other. Sorting both columns and scanning by eye works about as well for a short list.
What both approaches assume is that every payout corresponds to exactly one deposit row at exactly the amount you are looking up. That assumption holds often enough to feel reliable -- until it doesn't.
A real pair, from this tool's own worked example
This is not a hypothetical. It is the four-payout, five-deposit fixture shipped with this workbench's own "Load a worked example" control, reproduced exactly:
payouts.csv deposits.csv
2026-03-02 1420.00 2026-03-03 1420.00
2026-03-05 2310.50 2026-03-06 1200.00
2026-03-09 890.00 2026-03-06 1110.50
2026-03-16 1750.00 2026-03-10 864.35
2026-03-30 455.00
=VLOOKUP(2310.50, deposits, 1, FALSE) returns nothing, because
no single deposit row equals $2,310.50 -- the bank actually posted that
payout as two rows, $1,200.00 and $1,110.50, three days later. The row is
not missing from the export; it is simply not shaped like the amount you
looked up. Running this workbench against the same pair instead reports it
as one matched payout, explicitly naming both deposit rows that together
account for it.
The $890.00 payout is a second, quieter failure: the nearest deposit is $864.35, a $25.65 gap (2.88%) that reads as a processor fee once you know to check the percentage. A sorted scan either has to make that judgment by eye or leave the row as an unexplained gap; this tool states it in one line -- "deposit is 25.65 (2.88%) short — consistent with a processor fee deducted from the transfer" -- still a lead to verify against your statement, not an asserted match.
Side by side
| Spreadsheet formula or manual scan | This workbench |
|---|---|
| A VLOOKUP or MATCH on amount finds a payout only if one deposit row equals it exactly. | Also checks whether a payout equals the sum of several nearby deposits, searching up to 18 candidates per payout. |
| Judging whether a small gap "looks like a fee" is a call the person scanning has to make each time. | Computes the gap as a percentage and flags it when it falls in the roughly 0.1%–6% range typical of a processor fee. |
| A blank amount cell inside a SUM or VLOOKUP range is silently treated as zero. | Rejects a row with no digits in its date or amount column before reconciling anything. |
| An unmatched row has to be noticed while scrolling a sorted sheet. | Reports every payout and deposit exactly once, as matched, unmatched, or explained -- nothing to scroll past. |
| Free, and needs only a spreadsheet you already have. | Also free, local, and needs only the two CSV exports you already have. |
Using both together
A spreadsheet you already trust, tuned to your own processor's column names and checked against a quarter of statements, is a reasonable thing to keep using. What this workbench removes is the two failure modes above on a file you have not already built formulas for: the split deposit a single-row lookup cannot see, and the late or short deposit a date scan can miss or misjudge.
Open the workbench and load the worked example above, or upload your own payout and bank CSVs — no account, no connection, and it keeps working once the page has loaded. Comparing against a paid, connected sync instead of a spreadsheet? See this workbench vs. Synder.
Common questions
Isn't a VLOOKUP or SUMIFS good enough to match payouts to deposits?
It handles the ordinary case -- one payout, one deposit, the same amount -- well. It breaks on the two cases that actually cost time: a payout the bank split across several smaller deposits, which a single-row lookup cannot see at all, and a deposit that landed a few days late, which either needs a fuzzy formula nobody builds for a one-off check or gets missed on a plain exact-amount match. Both are ordinary occurrences, not edge cases -- this workbench's own worked example produces one of each.
How does the split-deposit case actually break a spreadsheet formula?
On this tool's own worked example, a $2,310.50 payout on March 5 lands at the bank as two separate deposits three days later: $1,200.00 and $1,110.50. A VLOOKUP or MATCH on the payout amount finds nothing, because no single deposit row equals $2,310.50 -- the row is genuinely not there. Finding it requires either noticing two deposits near that date happen to add up, or writing a SUMPRODUCT or Power Query step that checks combinations, which is more spreadsheet engineering than most people build for a single reconciliation run. This workbench searches deposit combinations for a matching sum automatically, up to 18 nearby candidates per payout.
What does a scanned date range miss that this tool doesn't?
On the same worked example, an $890.00 payout has no exact deposit match, but a $864.35 deposit landed nearby -- a $25.65 gap, 2.88% of the payout, which is inside the roughly 0.1%-6% range typical of a processor fee. A person scanning a sorted list for 'close enough' either has to remember what a normal fee percentage looks like or skip the judgment entirely and leave the row as a flat unexplained gap. This tool computes the percentage, checks it against that range, and states the reading in one sentence -- still a lead to verify against your statement, never an asserted match.
A blank amount cell in a spreadsheet formula is easy to miss -- what happens here?
In a spreadsheet, a blank cell inside a SUM or VLOOKUP range is silently treated as zero -- the formula still returns a number, so nothing flags that a row was incomplete. This workbench's CSV reader checks every date and amount cell before reconciling anything: a row with no digits in its amount column, or a date it cannot parse, stops the run with an error naming the file, rather than quietly reconciling a phantom $0.00 payout or deposit.
Does this replace building my own reconciliation spreadsheet?
Not for every case -- a spreadsheet you already trust, already customized to your own processor's CSV columns, and already checked against a quarter of statements is a reasonable thing to keep using. What this tool removes is the two failure modes above on a file you have not already built formulas for: the split deposit a lookup cannot see, and the late deposit a date scan can miss or misjudge. It runs entirely in your browser on the two CSVs you already exported, with nothing to connect and no formula to maintain between runs.