2026-07-23
How to Compare Two Excel Files and Actually Trust the Result
The comparison is only as good as the column you tell it to match on.
Comparing two versions of a spreadsheet — this month's export against last month's, or a corrected file against the original — sounds simple, but the result is only trustworthy if you understand how the matching actually works.
How the comparison actually works
Compare Excel Files matches rows between the two files using a key column you choose — typically an ID, invoice number, or another value that should be unique per row. For every key that exists in both files, it checks whether the rest of the row is identical; if not, it's reported as changed. Keys that exist only in the second file show up as added, and keys only in the first show up as removed.
This means the quality of the result depends entirely on picking a column that genuinely identifies a unique row — not a name or category that repeats across many rows.
The failure mode to watch for
If the key column you pick has duplicate values within a single file — two rows sharing the same 'ID' by mistake — only one of them will be represented in the comparison for that key, and the other is silently dropped from the result. This isn't a bug so much as an inherent limit of key-based matching: check that your chosen key column is actually unique per row before trusting the comparison's added/removed/changed counts.
A quick way to check: run Remove Duplicates on just that key column first (matching only on it) to confirm there are no repeats before using it as your comparison key.
Reading the result correctly
'Changed' means at least one value in the row differs between the two files, not necessarily the one you care about — check exactly which column changed before assuming it's the field you were expecting to track.
Tools used in this guide
FAQ
What happens if my key column has duplicate values?
Only one row per duplicate key ends up represented in the comparison — the others are effectively dropped. Verify your key column is unique before relying on the result.
Does the comparison care about column order?
It compares matched rows by their full content, so the same underlying data structured consistently across both files is what matters — pick a key column present and comparably structured in both.
Can I compare files with different numbers of columns?
The tool works from each file's own row data joined on the key column; wildly different structures between the two files will make the result harder to interpret even if it technically runs.