Keyed row comparison
Match the record, even when its Excel row has moved.
When column A contains an order ID, SKU, account number, or another stable identifier, compare rows by that key instead of by physical row number.
Worked example
Sorting changes row numbers. It does not change identity.
In the newer workbook, order A-1002 moved and its amount changed from 480 to 525. A-1003 is new. A positional comparison can make the sort look like many edits; keyed comparison reports the two business events.
| Order ID | Customer | Amount |
|---|---|---|
| A-1001 | Northwind | 320 |
| A-1002 | Contoso | 480 |
| Order ID | Customer | Amount |
|---|---|---|
| A-1003 | Fabrikam | 210 |
| A-1001 | Northwind | 320 |
| A-1002 | Contoso | 525 |
When to use a key
Choose a column that identifies one logical record.
Good keys remain stable between exports and are unique within the table: an invoice number, employee ID, product SKU, or account code. Names and free-form descriptions are usually weaker keys because spelling and formatting can change.
In the browser, enter Sheet:Column in the optional row-key field. In the CLI, pass --keyed "Orders:A". Other matched sheets continue to use positional comparison.
A dependable key is
- Present in both workbook versions
- Stable when rows are sorted
- Unique for each logical record
- Stored in one consistent column
Keyed comparison details
Questions that matter before the run.
What if the table has duplicate keys?
WorkbookLens warns about duplicates. Use a genuinely unique ID where possible so every row maps to one record without ambiguity.
What if rows are inserted or deleted?
A keyed comparison reports the corresponding record as added or removed. Unchanged records still match correctly regardless of their new row number.
What about ordinary worksheets?
Only the sheet named in the key specification uses keyed matching. Other shared sheets are compared by cell position.