Two-List Reconciler
Paste two lists (billing versus GL, bank versus ledger, CRM versus invoices) and instantly see what is missing from each side and where the amounts disagree. Replaces a screen of VLOOKUPs and a manual eyeball pass.
How do I reconcile two lists of transactions quickly?
Match the two lists on a shared key, then classify every row into one of three outcomes: present in both and matching, present in both but with different amounts, or present in only one side. The standard spreadsheet approach uses VLOOKUP in both directions plus a difference column, which takes a few minutes to set up, breaks on trailing spaces and inconsistent formatting, and has to be rebuilt from scratch the next time. This tool does all three comparisons in one pass and normalises the keys automatically.
How to use this tool
- 1
Paste both lists
Two columns each: a key and an amount. Billing versus GL, bank versus ledger, CRM versus invoices: anything with a shared identifier.
- 2
Let it normalise
Whitespace, case, currency symbols, commas, and parenthesis negatives are handled automatically before matching.
- 3
Work the three buckets
Matched, mismatched by amount, and missing from each side, with the total variance and the largest gaps ranked first.
The match fails on formatting far more often than on facts
Most failed reconciliations are not accounting problems. Four formatting issues cause the majority of false mismatches.
Invisible whitespace
A trailing space on an invoice number exported from one system and not the other produces a mismatch on rows that are actually identical. This is the single most common cause of a reconciliation that will not tie.
Negatives in parentheses
Accounting exports write negatives as (1,200) while other systems write −1200. Compared as text they never match, and compared as numbers one of them parses as zero.
Rounding at different precisions
One system stores two decimal places and another stores four. The difference is fractions of a cent per row and a visible variance once summed across thousands of rows.
Case and prefix drift
INV-1024, inv-1024, and 1024 refer to the same document. Any comparison that does not normalise case and strip prefixes will report three unmatched rows instead of one match.
Finding the break is not explaining it
This shows you exactly which rows disagree and by how much. Why they disagree: a credit note posted to the wrong period, a customer paying two invoices with one payment, a currency revaluation, a system that syncs on a delay: needs the surrounding context from both systems and an understanding of how each one behaves. That investigation is the part that consumes the afternoon, and it recurs every close.
See how DataWyse answers thisQuestions finance teams ask about this tool
What data do I need to reconcile two lists?
A shared key and an amount from each side. The key can be an invoice number, a transaction ID, a customer reference, or anything else that appears in both systems. If the two sides use different identifiers with no overlap, no tool can match them and the reconciliation has to be done on a different field.
Does this handle different date or currency formats?
It normalises currency symbols, thousands separators, parenthesis negatives, and whitespace before comparing. It matches on your key rather than on dates, so differing date formats between the two systems do not affect the result.
What tolerance should I use for amount differences?
Set it just above your expected rounding noise, commonly one cent for same-currency reconciliations. Anything larger than the tolerance is a genuine difference worth investigating; anything smaller is precision drift between systems and not worth anyone's time.
Why does a reconciliation not tie even when nothing is wrong?
Timing is the usual answer. One system records on transaction date and the other on settlement date, so rows near a period boundary appear on different sides. This is a cut-off difference rather than an error, and it resolves itself in the following period.
Is my data uploaded anywhere?
No. Everything is parsed and compared in your browser. Nothing is sent to a server, stored, or logged, which is why the tool works with no account and why it is safe to use with real ledger extracts.
Is this tool really free?
Yes. No signup, no email required, no usage limit. It runs entirely in your browser: nothing you type is uploaded to a server or stored anywhere. We build these because the people who find them useful are the people who eventually need a financial analyst that works the same way.
DataWyse answers the next thirty
Variance deep-dives, cash re-forecasts, scenario plans, board prep: asked in plain English, answered in minutes, with every number traceable to its formula and source data.