What duplicate keys mean in a CSV comparison
A repeated ID is a question about identity. Resolve it before trusting row pairings.
A duplicate-key warning means more than one row shares the key you selected. It does not, on its own, prove that your export contains an error. The key may identify an order when each row represents an order line, or the file may contain exact duplicate records. Those situations need different responses.
Before removing rows or changing the source data, work out what one row represents. Then decide what combination of fields identifies that thing on both sides.
Repeated business ID or duplicate record?
Consider this synthetic order export:
| Order ID | Line ID | Item | Quantity |
|---|---|---|---|
| ORD-104 | 1 | Notebook | 2 |
| ORD-104 | 2 | Pencil | 6 |
| ORD-105 | 1 | Notebook | 1 |
ORD-104 repeats because the order has two lines. Deleting one row would discard a valid item. Order ID alone is an incomplete identity; Order ID plus Line ID identifies each record in this example. A composite key preserves both fields as parts of identity.
Choose a key that survives the change
A useful key stays stable between exports. Adding Quantity to the key may make rows unique, but it causes a quantity edit to look like a removed row and an added row. If the purpose is to find quantity changes, Quantity belongs among the compared values.
The same caution applies to names, addresses and status values. Choose source identifiers when available, and use a combination only when that combination describes the record’s identity. If no stable identity exists, document the ambiguity instead of manufacturing a key that guarantees a convenient result.
Exact duplicates have a count
Suppose one file contains the same complete record twice and the second contains it once. Treating each file as a set of unique records would hide the extra occurrence. Spreadsheet Comparison accounts for repeated matching records and surfaces unmatched occurrences.
That helps you notice an extra export row, but it still does not explain why it exists. The record might have been duplicated during export, or repeated intentionally to represent separate events without separate identifiers. Investigate the source before deleting anything.
Ambiguous groups need inspection
If several rows share a key and their values differ, there may be no single defensible way to pair them. The comparison groups records under the selected key and matches exact records before handling the remaining differences. A pairing inside an ambiguous group is not proof that a particular source row became a particular destination row.
Read the warning, search the key and inspect the full rows. If the source contains a more precise identifier, add it to the key and compare again. If it does not, review the group as a group and preserve that uncertainty in your findings.
Blank keys are also a warning
Two missing identifiers do not establish that two records are the same entity. Check whether blank IDs are expected for draft records, whether the wrong column was selected, or whether an export field failed to populate. Correct the export or select a valid key before relying on the comparison.
For a composite key, inspect every component. An order ID combined with a blank line ID may still leave several rows in the same group. A unique-looking result is only useful if its identity rule makes sense.
Keep a record of the decision
Save which key fields you used, which columns you compared and how you handled duplicate groups. Preserve the original exports and keep any cleaned working copies separate. This lets another reviewer reproduce the same question rather than merely opening the same files.
Read the key-based comparison guide for a complete workflow, or the Excel guide when the repeated records come from selected workbook sheets.