Why Row-by-Row CSV Comparison Fails When Product Catalogs Get Reordered

Yannick Kroll — Mon, 12 Oct 2026 07:19:44 +0000

Imagine receiving an updated product catalog from a supplier.

Both files contain product SKUs, names, prices, and stock quantities. You want to know which products were added, removed, or changed.

A simple line-by-line comparison sounds reasonable. But there's a catch: the supplier may have reordered the rows without changing the products themselves.

Here's a small example.

The problem

Original catalog

SKU	Product	Price	Stock
000101	Desk Tray	18.90	24
000102	Cable Keeper	6.90	120
000103	Notebook	11.00	80
000104	Mug	14.90	35

Updated catalog

SKU	Product	Price	Stock
000103	Notebook	11.00	60
000102	Cable Keeper	7.50	120
000105	Bottle Sleeve	9.50	42
000101	Desk Tray	18.90	24

If you compare these files row by row, the first rows appear completely different.
But the Notebook didn't become a Desk Tray. It simply moved.

The solution: Match records by SKU

Instead of comparing row positions, use a stable identifier such as the SKU.

A reliable key-based comparison follows four steps:

Parse both CSV files and index their records by SKU.
Check for missing or duplicate keys in each file.
Match records using their SKU values, regardless of row order.
Compare the remaining fields for matching records and classify unmatched records as added or removed.

For the example above, the actual results are:

Status	SKU	Difference
Changed	000102	Price: 6.90 → 7.50
Changed	000103	Stock: 80 → 60
Added	000105	New Bottle Sleeve
Removed	000104	Mug no longer present
Unchanged	000101	No data changes

That's two changed products, one added, one removed, and one unchanged — regardless of their order in either file.

Watch out for leading zeros

SKUs such as 000101 are identifiers, not numbers.

Converting 000101 to a numeric value produces 101, which can break comparisons or create mismatches with other systems.
Keep identifiers as strings throughout parsing and comparison.

Also remember that spreadsheet programs may automatically reinterpret CSV values when opening them. A correctly exported CSV can still appear to have lost leading zeros if imported with incorrect column types.

Other common pitfalls

Duplicate SKUs: If multiple rows share the same matching key, a simple lookup can overwrite records. Detect duplicates and report them rather than silently selecting one.

Missing SKUs: Records without a usable key cannot be matched reliably. They need separate review.

Inconsistent formatting: Whitespace and letter casing may cause unexpected mismatches. Decide explicitly whether values should be normalized before matching.

Different columns: If the supplier adds or removes a column, distinguish structural changes from actual product-value changes.

Quoted CSV values: CSV files can contain commas, quotes, and multiline fields. Use a proper CSV parser instead of splitting lines and commas manually.

The takeaway

When comparing product catalogs, row position is rarely a reliable identity.

A stable, unique key lets you separate real business changes from harmless row reordering.
That makes the resulting difference report much more useful for checking prices, inventory, and product additions before updating another system.

Try it with real CSV files

I built Toolgrain CSV Compare, a browser-based tool that matches CSV records by a selected key and highlights added, removed, and changed rows.

You can try it with fictional sample files without creating an account. CSV processing happens locally in your browser.
If you have suggestions for improving the comparison workflow, I'd be interested in hearing them.