When three exports should agree,find the one that disagrees.
A deterministic reconciliation across three or more sources on one match key — a bank export, a payment-processor export, and your ledger; or three feeds that must agree on quantity. Every key is classified AGREED, DISPUTED, or INCOMPLETE, and one disagreement is enough to block the reconciled verdict.
Two-list tools break the moment a third source shows up.
sources that must agree — a two-way join can't tell a coverage gap from a conflict.
disagreement is enough. A net-zero difference is not a reconciliation.
AI, network, or uploads — deterministic, offline, your inputs only.
With two lists, every key is either matched or orphaned. With three or more, a key can be present in some sources and missing from others (a coverage gap) entirely separately from disagreeing in value across the ones that have it (a conflict). Those are different problems with different fixes — and a two-way tool can't tell them apart. This engine does.
Tick a source off, change an amount, watch the verdict move.
Live demo · edit an amount, or clear a cell to drop a source
| Key | Bank | Processor | Ledger | Verdict |
|---|---|---|---|---|
| TXN-1001 | AGREED | |||
| TXN-1002 | AGREED | |||
| TXN-1003 | DISPUTEDconflict on amount | |||
| TXN-1004 | INCOMPLETEmissing from ledger | |||
| TXN-1005 | AGREED |
Set verdict
NOT RECONCILED
disagreement gate FIRED on TXN-1003
Keys
3 agreed · 1 disputed · 1 incomplete (60% agreed)
Fix first: TXN-1003
A value conflict (DISPUTED) outranks a coverage gap (INCOMPLETE), and one disputed key trips the gate — the set is NOT RECONCILED however many keys agree. A net difference of zero is not a reconciliation.
Verbatim output on the shipped bank / processor / ledger sample.
The tolerance does real work here: bank 432.10 and processor 432.11 agree within a cent, but ledger 455.00 disagrees — so that key is DISPUTED on amount. TXN-1004 is a clean coverage gap (missing from the ledger), which on its own would only be FIX. But one dispute trips the gate, and the set is NOT RECONCILED — 60% agreed notwithstanding.
MULTI-SOURCE RECONCILIATION — 3 sources (bank, processor, ledger) as of 2026-06-23 ====================================================================== [txn-1001] -> AGREED [txn-1002] -> AGREED [txn-1003] -> DISPUTED conflict on: amount [txn-1004] -> INCOMPLETE missing from: ledger [txn-1005] -> AGREED ---------------------------------------------------------------------- Keys: 3 AGREED / 1 DISPUTED / 1 INCOMPLETE (60% agreed) Disagreement gate: FIRED on txn-1003 SET VERDICT: NOT RECONCILED Fix first: txn-1003 Deterministic and offline — your inputs, no AI. Reconciles your own sources; does not score or rank people. Not accounting or legal advice.
Three rules that keep a reconciliation honest.
A value that disagrees (DISPUTED) outranks a row that's merely missing somewhere (INCOMPLETE) — the conflict is the one that can move money.
A single DISPUTED key blocks RECONCILED and forces NOT RECONCILED. The agreed-share % is context only and never sets the band.
Amounts agree within a cent so rounding isn't a false alarm; status agrees case-insensitively. Never an exact float equality. Don't widen it to bury a real variance.
A reconciliation check, not your system of record.
- An N-way reconciliation on one key with per-key and set verdicts.
- A runnable engine plus a workbook that reproduces it, line for line.
- A clean split of value conflicts from coverage gaps.
- Deterministic and offline — your pasted inputs, no AI, nothing uploaded.
- A system of record — you fix the wrong value at its origin, then re-run.
- A money mover — it reports; it never edits, merges, or transfers.
- A within-list de-duplicator — that's the Duplicate & Near-Duplicate Finder.
- Accounting or legal advice, and it does not score or rank people.
Anyone whose numbers live in more than two places.
- · Finance and accounting teams reconciling bank, processor, and ledger.
- · Ops leads reconciling multiple regional or warehouse feeds.
- · Anyone closing a period across three or more exports.
- · Analysts who keep eyeballing three CSVs side by side.
- · Teams who outgrew a two-list reconciliation.
- · Anyone who needs the conflict separated from the gap.
Where this sits in the Document Processing line.
The two-list version in one workbook, when you only ever reconcile List A against List B.
The AP-specific three-way match — invoice against PO and goods receipt, with a payment-block gate.
Validate each record's fields by rule before you reconcile — the upstream correctness layer.
The questions finance and ops teams actually ask before they trust a reconciliation.
The Two-List Kit reconciles List A against List B — every key is either matched or orphaned. The moment a third source shows up, that model breaks, because a key can now be missing from some sources (a coverage gap) entirely separately from disagreeing in value across the sources that do have it (a conflict). A two-way join can't tell those apart. The Multi-Source Data Reconciliation Engine reconciles 3+ sources on one key and classifies each as AGREED, DISPUTED, or INCOMPLETE, so the conflict and the gap are never confused. If you only ever reconcile two lists, the Quick Kit is the simpler buy; this is for three or more.
DISPUTED means a value conflict: the key is present in two or more sources but at least one compare field disagrees across them (an amount beyond tolerance, or a status mismatch) — someone's number is wrong. INCOMPLETE means a coverage gap: the key is present in some sources but missing from at least one, with no conflict among the sources that have it — someone hasn't reported yet. They're different problems with different fixes, which is exactly why a three-source reconciliation has to separate them. And precedence matters: if a key has both a conflict and a gap, it's DISPUTED, because the conflict is the one that can move money.
Because one disagreement is dispositive. A single DISPUTED key trips the disagreement gate and forces NOT RECONCILED, regardless of how many keys agreed — in the worked sample, three of five keys agree (60%) and the set still reads NOT RECONCILED, because one transaction's amount disagrees across the sources. The agreed-share percentage is shown for context only and never sets the verdict. A net difference of zero is not a reconciliation; the engine refuses to call a set reconciled while any key is actually in conflict.
Amounts agree within an absolute tolerance (default one cent) plus a tiny relative-epsilon guard at the boundary, never an exact floating-point equality — so a routine rounding gap between a bank and a processor export isn't flagged as a false variance. In the sample, bank 432.10 and processor 432.11 agree within a cent, but ledger 455.00 is well outside it, so that key is DISPUTED on amount. Text fields (like a status) compare exactly after trimming and case-folding. The tolerance is yours to set, but the honest move is to keep it tight — don't widen it to bury a real variance.
No. The engine is a reconciliation check, not a system of record and not a money mover — it reports per-key and set verdicts and points you at the key to fix first, but it never edits, merges, transfers, or writes back to any source. You correct the wrong value at its origin (the source that's actually off) and re-run. It's deterministic and offline: your pasted inputs, no AI, no network, nothing uploaded — the same inputs always produce the same verdict, which is what makes it defensible at close.
A long-format CSV with one row per source-and-key plus your compare-field columns (amount, status, quantity — whatever should agree), and a small declaration of which fields are amounts vs text. You point the runnable Python engine (zero dependencies) at it and get the verdicts; the companion workbook reproduces the same per-key and set logic on a pasted sample so you can see it without running Python. It handles any number of sources on one key — bank/processor/ledger, three regional inventory feeds, multiple warehouse exports. It reconciles your own data values, never people, and it's not accounting or legal advice.
New to the document-ops line? Run the Document Processing Pipeline Diagnostic first — it scores your workflow across six stages and routes you to the exact drop that fixes your bottleneck.
Three sources, one key.
One honest verdict.
One purchase, lifetime access, 12 months of updates. $89, once.
Deterministic and offline — your inputs, no AI. Reconciles your own sources; does not score or rank people. Not accounting or legal advice.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai