Data quality
How to Find Duplicate Records in Excel Without Deleting Evidence
Identify duplicate keys, distinguish exact duplicate rows from conflicting duplicates and create a controlled correction list.
A vendor master contains repeated GST numbers; some rows are exact copies while others have different bank details and require escalation. This is the kind of ordinary spreadsheet task that becomes risky when a formula is copied without a clearly stated key, scope and expected exception behaviour. The objective of this guide is to surface repeated business keys and preserve every affected row so exact copies and conflicting duplicates can be reviewed separately. The examples use compact data so that every result can be checked by eye before the same pattern is applied to a larger workbook.
Start with the business rule, not the function name
Before entering any formula, write the question in plain language. Identify the record that should be unique, the source that is authoritative, the field that should be returned or compared, and what should happen when the record is absent. For this example, the rule is tied to Vendor ID. A reviewer should be able to explain why that field is suitable as a key and whether duplicates are allowed. If the key is not stable, a technically valid formula can still produce an operationally incorrect answer.
Typical uses include vendor masters, employee records, invoice imports, CRM contacts. These workflows often begin as a one-off request and later become monthly controls. That is why range discipline, visible missing values and repeatable tests matter from the first version. A formula should be treated as a small piece of production logic: it needs inputs, assumptions, failure behaviour and an owner.
Worked example dataset
| Vendor ID | Vendor Name | GST Number | Bank Account |
|---|---|---|---|
| V001 | Alpha Supplies | 27AAAAA0000A1Z5 | XXXX1010 |
| V002 | Beta Traders | 27BBBBB0000B1Z5 | XXXX2020 |
| V003 | Alpha Supplies | 27AAAAA0000A1Z5 | XXXX3030 |
The table is deliberately small. Confirm the key values, look for blanks and duplicates, and note the expected output for at least one present record and one absent record. On a live workbook, save a copy before changing formulas. Where personal or financial information is involved, use a controlled test extract rather than sending the workbook to an unrelated online service.
Formula pattern
=COUNTIF($A$2:$A$500,A2)>1
Read the formula from the inside out. The lookup or criteria value identifies the current record. The source ranges define where the key is searched and where the answer comes from. Exact-match controls prevent a near position from being treated as the requested identifier. A readable fallback makes missing records visible to the person reviewing the sheet. Dollar signs lock ranges that should not move when the formula is copied.
Conditional formatting is useful for a quick visual signal. A duplicate report is safer for operational work because it lists each affected row, shows occurrence counts and can be reviewed outside the original workbook. This distinction is more important than choosing the shortest formula. A maintainable formula makes its assumptions visible and survives ordinary workbook changes. A compatible formula opens correctly for its intended recipients. A controlled formula is tested against known cases and does not silently convert exceptions into harmless-looking blanks.
Build and test the calculation step by step
- Create or identify a clean master table and confirm the key column.
- Place the formula in one test row rather than filling an entire column immediately.
- Use a known key and compare the returned value with the source row.
- Use a missing key and confirm that the fallback is visible and meaningful.
- Copy the formula to a second row and inspect which references move.
- Only after these tests should the formula be filled through the production range.
Testing one successful row is insufficient. Include boundary cases: the first and last source records, a blank key, a duplicate key, text that looks numeric, a key with extra spaces, and a record whose return field is genuinely blank. These cases reveal whether the formula and the underlying data model agree.
Common failure modes
- Using Remove Duplicates before saving evidence. Review the underlying data before treating the formula output as a final decision.
- Checking the wrong column for uniqueness. Review the underlying data before treating the formula output as a final decision.
- Treating blank keys as one ordinary duplicate group. Review the underlying data before treating the formula output as a final decision.
- Ignoring conflicts within duplicate groups. Review the underlying data before treating the formula output as a final decision.
- Comparing display formatting instead of underlying values. Review the underlying data before treating the formula output as a final decision.
- Deleting one row without documenting the decision. Review the underlying data before treating the formula output as a final decision.
The most dangerous spreadsheet errors are not always visible error values. A formula can return a plausible but incorrect value, especially when approximate matching, duplicate keys or shifted return indexes are involved. The review process should therefore inspect both formula structure and result reasonableness. ReconNimble's Formula Health Checker can flag structural risks, while a reconciliation job is more suitable when complete datasets and exceptions must be evaluated.
Review checklist before distribution
- Define which field should be unique.
- Separate blank keys.
- Count every occurrence.
- Compare non-key fields within each group.
- Assign an owner for resolution.
- Keep the original source and audit export.
Record the workbook version, source date and formula purpose near the report or in a control sheet. Where a workbook is reused, assign a review date rather than assuming last month's ranges and business rules still apply. If several people edit the file, use protection, version history or an approved shared location so that the source of truth is clear.
When a formula is enough—and when it is not
A lookup or counting formula is appropriate when one controlled key should return one controlled answer and the exceptions are small enough to inspect. Reconciliation is the better method when you must compare in both directions, explain duplicates, compare several fields, reconcile three or more sources, record manual resolutions or create an audit export. Formula output can be part of a control, but it should not replace an exception workflow when the decision affects payments, access, payroll, inventory or compliance.
For repeated work, save the mapping and rules rather than rebuilding them from memory. A saved reconciliation profile can document source labels, keys, field mappings and normalization choices. Scheduled discrepancy summaries can then report the latest completed profile result without exposing uploaded source files in public URLs.
Practical governance notes
Keep source files unchanged and make corrections in a reviewed copy or authoritative system. Do not delete missing or duplicate rows merely to make totals agree. Preserve evidence showing what was compared, which rules were used and who accepted each exception. Formula cells should be distinguished from manual overrides, and manual overrides should include a note or ticket reference where the decision matters.
Performance also matters. Avoid entire-column references in formulas repeated thousands of times unless the workbook has been measured and the trade-off is understood. Limit volatile functions, repeated lookups and unnecessary cross-workbook links. In shared-hosting reconciliation, row caps and bounded fuzzy comparisons protect both reliability and other users; rejecting an oversized operation clearly is safer than timing out halfway through a report.
Final takeaway
The formula or workflow in this guide is useful because its behaviour can be explained and tested. Use the example as a pattern, not as a substitute for understanding your own columns. Confirm key uniqueness, make missing records visible, test edge cases and retain a reviewable output. These steps take longer than pasting a formula once, but they prevent much larger correction work later.
Practical questions
Frequently asked questions
Are two identical rows always an error?
Not necessarily. The business rule determines uniqueness, but repeated payment or employee records usually require review.
Why are blank keys special?
Multiple blank identifiers indicate incomplete data, not a valid duplicate entity. They should be handled as a data-quality issue.
Should duplicates be automatically merged?
Only when a documented rule identifies the surviving values. Conflicting fields need human review or an approved source-priority rule.
Sources, testing and editorial accountability
Source notes
- Microsoft guidance for COUNTIF and conditional formatting
- ReconNimble duplicate-row fixtures
- Data-governance practices for evidence preservation and manual resolution
Testing notes
The examples were checked against ReconNimble's formula, comparison and reconciliation test files for this topic.
Formula and spreadsheet behaviour may differ by Excel version, locale, workbook structure and Google Sheets support. Test examples against a copy of your real data before changing production files.