How to check duplicate orders in Excel or CSV.

First, decide what one row represents.

A repeated order ID is a reason to inspect an export. It is not, by itself, a reason to delete a row. In an operations report, one order can legitimately have several items, split shipments, returns or status events.

Ask the person who owns the source system whether each row is an order, an order line, a shipment or an event. Then choose the fields that identify one record for the task. Write that rule down before using a duplicate-removal tool.

Keep an original and a traceable working copy.

Save the source export unchanged. Work on a separate copy and keep the source filename, export time and row count in your notes. Add an original-row identifier in the working copy if you need a simple way to trace changes.

Record the totals that matter to this workflow before making a change: data rows excluding the header, unique order IDs, quantities and amounts. Check what those amounts mean. An order total repeated on every item line should not be summed as though it were a line total.

Write an explicit duplicate rule.

For the small fictional example below, the source owner has confirmed one row per order. Two records count as an exact duplicate only when order ID, order date, product code, quantity, unit price and line total all match. The first occurrence is kept. The source-row number is retained for tracing but excluded from the match.

That rule belongs to this example. A real order-line export might need a line ID; a shipment export might need a shipment ID. If two otherwise similar records disagree on quantity, status or price, keep the discrepancy in an exception list until someone can explain it.

Also agree how to treat blanks, spaces, letter case and field types. Do not silently trim, change case or convert identifiers just to make records match. Any normalization should be a separate documented step with its own checks.

How to inspect duplicate rows in Excel

Microsoft documents filtering or highlighting duplicates before removal, and recommends keeping a copy because removal deletes rows. In a working copy, select the full table, choose Data → Remove Duplicates, and select the columns that implement your agreed rule. Confirm headers and inspect the reported removal count. Unselected columns remain part of the rows being removed; they are not protected from deletion.

Product reference: Microsoft: filter unique values or remove duplicate values. The operations rules and fictional example on this page are DC Health Check’s own explanation.

Before saving a CSV result, check representative identifiers and dates in the exported file. An order code with leading zeros is an identifier, not an arithmetic quantity. Keep it consistent with the source. If the chosen tool’s comparison behavior does not match your business rule, stop and use a process that you can validate.

Worked example: one order counted twice

The downloadable example has six data rows. Source rows 3 and 4 contain the same business record for ORD-1002: two units at $30 each, with a $60 line total. The agreed rule removes only source row 4.

The lower total is a reconciliation of this fictional file. It is not a customer saving or a recovered payment. No price, quantity or other business field was edited.

Download the worked example (ZIP) ↓

Includes the before CSV, corrected CSV, change log, validation checks and scope notes. Entirely fictional data. No signup required.

Validate the repaired report.

• Reconcile row counts. Input rows minus approved removed rows should equal output rows. Treat blank rows and headers consistently.
• Reconcile quantities and amounts. Explain every difference using the removed records or another agreed change. Compare monetary amounts at the precision used in the source.
• Compare retained records with the original. Check that remaining business fields did not change during sorting, filtering or export.
• Check the rule, not just uniqueness. One row per order is valid only if that is the agreed row structure. A multi-line order can legitimately retain repeated order IDs.
• Refresh the report that uses the file. Recheck the downstream formula, pivot or summary after updating its accepted input. Keep unresolved discrepancies beside the corrected report.

Leave a change log the next owner can follow.

A useful handoff identifies the original file, the agreed rule, each removed source row, the reason for removal, before-and-after checks, and unresolved exceptions. Include enough refresh instructions to repeat the same checks with the next export.

If the recurring file changes structure, revisit the rule before reusing the repair. A clean result on one sample does not establish that all future files will follow the same pattern.