Review duplicates across overlapping bank CSV exports
Updated · 6 min read
Review overlapping bank CSV exports by marking repeated observations, not by deleting every matching date and amount. Keep the original files and record where each row came from. Two identical-looking payments can be two real transactions; a repeated export of one posted transaction is a different problem. This guide is for preparing existing CSV data, not deleting entries from an accounting ledger.
If you already have CSV, work from that native export. LocalExtract can help when the source is a PDF, but conversion is not a duplicate-detection step.
The desktop apps export date, description, and amount as CSV. Open CSV in Excel to save an XLSX workbook. Statement support varies: verify the result against your own PDF.
Preserve enough evidence to decide
Create a working table with source filename, source data-record number, export period, account and currency alongside the original transaction fields. Keep identifiers as text. A record number should be assigned within each source before sorting or filtering; a number added after combining cannot reliably identify the original record. It counts CSV data records after the header, not physical lines inside quoted multiline descriptions.
Do not assume a merchant reference is a unique transaction ID. Establish what an identifier means in that bank’s export and whether it is stable across both downloads. Compare only a verified account and currency scope. A matching reference in another account, a pending item and a posted item, or a changed export may require further evidence rather than a shared removal rule.
If you need to assemble the files first, use the separate folder-combination workflow. Preserve every observation in that assembly; deciding which ones represent the same event comes next.
Work through seven observations before removing anything
The following synthetic deposit-account example defines receipts as positive and payments as negative. Both files belong to invented account SYNTHETIC-A in USD. The early export covers October 1–10; the overlap export covers October 8–15. T101, T102 and T103 are deliberately defined as distinct, stable posted-event IDs in this exercise. They are extra teaching fields, not part of LocalExtract’s three-field export.
| Source record | Date | Description | USD amount | Posting ID | Review decision |
|---|---|---|---|---|---|
| early.csv:1 | 2026-10-08 | Coffee | -8.50 | T101 | Keep first observation |
| early.csv:2 | 2026-10-08 | Coffee | -8.50 | T102 | Keep: a second real purchase |
| early.csv:3 | 2026-10-09 | Refund | 8.50 | T103 | Keep: a separate posted refund |
| overlap.csv:1 | 2026-10-08 | Coffee | -8.50 | T101 | Exclude confirmed repeat of early.csv:1 from the working output |
| overlap.csv:2 | 2026-10-09 | Refund | 8.50 | T103 | Exclude confirmed repeat of early.csv:3 from the working output |
| overlap.csv:3 | 2026-10-10 | Transfer | -25.00 | Missing | Hold for source verification |
| overlap.csv:4 | 2026-10-10 | Transfer | -25.00 | Missing | Hold for source verification |
Matching only date, description and amount would group three coffee observations and could discard T102, a genuine second purchase. The refund is another event, not a duplicate of the purchase merely because the values offset. The two transfers are unresolved: their identical visible fields do not establish whether one was exported twice or both actually occurred.
Seven observations become five after excluding the two copies established by this scenario’s event identities. Those five still include two held observations; this is not a cleared import file. Record the evidence and the chosen retained source for each exclusion. Keeping the early copy here is an explicit editorial decision, not a promise about a spreadsheet’s default behavior.
The raw net amount and the net after those two exclusions are both −58.50 USD: the removed copy of −8.50 and the removed copy of +8.50 offset. An unchanged total therefore cannot validate a deduplication decision. Download the synthetic decision cases for all source records, decisions and expected counts. We checked the scenario with Python and Decimal arithmetic; it is not an Excel, bank or accounting-import execution test.
Use Power Query to find candidates, not certify them
For Microsoft 365 desktop Excel on Windows, use a disposable working query and preserve a full base table. In a separate review query or workbook copy, select the comparison columns and use Home → Keep Rows → Keep Duplicates. Microsoft’s keep/remove duplicate-row instructions explain that the selected columns determine which rows count as duplicates. Check the preview and keep the base table unchanged.
For the coffee example, date, description and amount produce a suspect group, not a deletion authorization. Including source filename, source row and export period in the matching key would instead make repeated observations look different simply because they came from different locations. Retain provenance as evidence columns, but do not confuse it with the event’s identity. Where a bank genuinely supplies a documented stable posting ID, account, currency and that ID may support a stronger comparison; investigate conflicting dates or amounts even when the ID matches.
Power Query comparisons are case-sensitive. Uppercasing, trimming or other normalization can make descriptions match, but also collapse meaningful differences. Preserve the raw descriptions, document any derived comparison key and inspect the resulting groups. Microsoft’s duplicate-handling guidance also warns that removing duplicates does not guarantee which instance is retained. Sorting the table first is not a general guarantee that the earliest source survives.
Do not run Remove Duplicates across the live base and assume the result implements your review decisions. Keep Duplicates is useful for investigating repeated keys; it does not prove transaction identity. Keep unresolved groups separate and compare them with the original export instructions or issued statement. If identity cannot be established, retain the observations and hold the affected output rather than silently dropping one.
Keep an exclusion log and a reproducible output
Give each reviewed observation a decision, reason, evidence reference and retained-source pointer where applicable. Produce the working output from those explicit decisions, retaining the raw table and excluded copies separately. Check that source counts equal retained plus excluded observations; held rows must remain distinguishable and must not enter an upload as though approved. The exercise balances as seven = three cleared retained observations + two held observations + two confirmed repeated copies.
This review concerns overlaps within your assembled CSV data. It cannot tell you which rows are already in a bank feed, ledger or prior accounting upload. Before any upload, check the target account and its existing records using that product’s own workflow. The accounting CSV checklist covers that handoff. Do not delete accounting entries on the strength of this spreadsheet comparison.
When PDF extraction is necessary, LocalExtract processes one PDF at a time locally, including OCR, and exports date,description,amount CSV. It has no desktop batch queue or accounting synchronization. Account services and periodic Pro verification need a network. Save the CSV as an XLSX workbook in Excel if needed. Download LocalExtract for PDF extraction.
Official Microsoft sources checked October 15, 2026. The synthetic identities explain review decisions; they do not establish uniqueness rules for any real bank’s references.
LocalExtract Team
We build LocalExtract, a desktop bank statement converter. Questions or corrections? Contact · Editorial policy