Two-List Reconciliation Kit

It reconciles two lists that should describe the same set of things — a bank statement vs your ledger, a vendor's invoice list vs your PO log, a payroll register vs the time system, a shipment manifest vs what was received. You paste List A and List B, pick a match key (an ID, invoice number, or email) and an amount tolerance, and it joins the two lists on that key and classifies every distinct key as RECONCILED, EXCEPTION, or ORPHANED. It's one .xlsx with three tabs — Start Here, Dashboard, Reconciliation — and a worked bank-vs-ledger example ready to overwrite. It reads only the two lists you paste; it never touches your accounts or systems.

An EXCEPTION is a key that's on both lists but a compare value disagrees — an amount that differs beyond the tolerance, or a status that doesn't match. The record exists on both sides; the values don't line up, which usually means a posting or pricing error. An ORPHAN is a key that's on only one list: ORPHAN A is in List A and missing from B, ORPHAN B is the reverse — a record one side has and the other never saw. They're genuinely different problems, which is why a plain matched/unmatched count hides the more useful signal: a row that matches the key but disagrees on the money is not the same as a row that's simply absent.

The batch verdict is a gate, not a percentage. The pair is RECONCILED only when every key reconciles — a single exception or a single orphan blocks it, because you cannot honestly call two lists reconciled while any row is unaccounted for. If orphans show up on both sides at once, the batch escalates past EXCEPTIONS to ORPHANED — the signal that the two lists don't even align (usually a key-format mismatch or the wrong file, not a few stragglers). The reconciled share is shown for context only; the verdict keys off the gate, never the number. A net difference of zero is not a reconciliation: two offsetting errors plus a missing record can net to exactly zero and still hide three real problems.

You set how close two amounts must be to count as agreeing. The default is 0.01, which absorbs a one-cent rounding difference so a trivial gap isn't flagged as a false mismatch — 845.124 and 845.12 reconcile, while 500.00 and 545.00 are an exception. Set the tolerance to 0 to require exact equality. A difference exactly at the tolerance still reconciles: the comparison uses a relative epsilon, not an exact equality test, so float representation never tips a boundary case the wrong way.

No. The Invoice–PO–Receipt 3-Way Match (TWM) is a three-way match with accounts-payable semantics — price, quantity, and receipt, with a payment-block gate. This kit is the general two-way reconcile: it joins any two lists on a key and a couple of compare fields, for any pair of lists, not just AP. It's also not a close workbook like the Finance & Reporting Automation Kit, which checks a single source's own tie-outs against the books' math. This kit joins two independent external lists and classifies each key. Different unit, different mechanism.

Keys are matched exactly, after trimming surrounding spaces and lowercasing — so 'INV-1001' and ' inv-1001 ' are treated as the same key, but it does not do fuzzy or approximate matching. If your two lists key on slightly different formats (leading zeros, prefixes, punctuation), normalize the key column before pasting so the join lands. It joins on an exact, normalized key by design: that's what makes every outcome deterministic and repeatable — the same two lists always return the same verdicts, with no model and no invented matches.