Merge overlapping bank CSVs without losing real purchases

The files can be correct and still overlap

A merge only makes sense within one account and currency. The destination instructions below describe published behavior, not tested imports or a guarantee for every edition.

Suppose you download March 1-18 while preparing a return, then March 12-31 when the remaining records arrive. Both files can be correct because you asked for some history twice. It's the merge that creates extra copies, not necessarily the bank or extraction process.

Files can also overlap with bank feeds. Intuit's duplicate troubleshooting guidance, checked October 17, 2026, lists overlapping manual imports and feeds, reconnecting accounts, and adding a downloaded transaction instead of matching an existing record as possible causes. A clean CSV can still duplicate your ledger.

If you're replacing a missing feed or backfilling history, the guide to choosing a cut-over and checking existing coverage explains where to start. For supplied CSVs, native bank exports and manual spreadsheet comparison are valid options. There's no need to convert a usable CSV.

Similar columns can mean different things

An untouched source folder gives you originals to refer back to. Label working copies by account and currency rather than pooling checking, savings and credit cards under Business, where similar transfers and regular charges can suggest the wrong removal.

Even files with identical headers need separate checks. One might use posting dates and signed amounts, another purchase dates and separate debit and credit columns. Headers help with mapping, but they don't prove the date order or amount conventions match. Compare those with the statement before sharing settings across files.

The tool asks you to resolve ambiguous dates and separators, and invalid required values block the merge. Original dates and amounts appear beside the proposed output so you can compare them. The date and number-format guide explains what to do if 03/04/2026 or 1,234 could mean two things. Duplicate checks can't fix a misread date or amount.

Descriptions are evidence, too. Removing card references, shortening merchants or stripping spaces can hide differences, so leave them alone. Rather than changing posting dates to make copies match, keep the values and explain the relationship in your review.

Matching rows still need a closer look

A date overlap tells you where to compare rows, not what to discard. When only weaker fields match, keep those possible duplicates unless source evidence resolves them.

The tool's exact match uses the interpreted calendar date, exact signed amount and character-for-character description, not every CSV column. References can differ even when those three fields agree, which is why you still need to inspect the sources before excluding a row.

Possible groups include equal dates and amounts with different descriptions. This catches reordered merchant words without claiming to understand them. If you choose an optional day tolerance, the tool also groups identical amounts and descriptions across nearby dates. The default is zero, so a wider window is your choice.

Two fictional coffee purchases for 4.00 each on the same day total -8.00. Their descriptions could be identical and still represent two real charges, so deleting one would understate spending by 4.00. A matching key helps you search. It doesn't identify a transaction or prove which source to trust.

Matches can also form a chain. One row matches a second by date and amount, then the second matches a third by description within the day tolerance. The tool groups that chain to avoid conflicting deletion choices, though not every pair necessarily matches. Row checkboxes let you keep the right subset, or you can leave KEEP ALL while you investigate.

How eight rows become six after review

This example uses the fictional March 2026 checking statement from our statement-checking guide. It's in USD, with money in positive and money out negative. We assigned dates for two overlapping exports. None of this is customer data.

Line 1 is the header in each file. The observed ranges overlap from March 12-18, inclusive, with two transactions from each file. That tells you where to look, not whether there's a duplicate: different purchases could occupy the same span.

Appending everything gives eight rows and 6.05 + (-84.95) = -78.90. The fictional source confirms that early line 4 and late line 2 are the same office-supplies purchase, while early line 5 and late line 3 are the same refund. For this example only, we'll keep the early copies.

The six remaining rows sum to -78.90 - (-43.95) = -34.95, a net increase of 43.95. That direction matters: removing a duplicate outflow raises the total, while removing a duplicate inflow lowers it.

The fictional opening balance of 2,400.00 plus the reviewed total gives a closing balance of 2,365.05. Keeping both duplicated rows would give 2,321.10. We're doing this calculation separately because the duplicate finder doesn't take or check opening and closing balances. Even a zero statement difference wouldn't prove authenticity or rule out offsetting errors.

You can inspect both files with Load example in the duplicate finder. All eight rows start out kept, so open each candidate group to choose the source copy to retain. Download the merged account CSV and row-by-row review report together so someone else can reconstruct your decisions.

A quiet stretch isn't necessarily a gap

Transaction exports usually show activity dates rather than proof of the statement period. A first transaction on March 5 could belong to a statement beginning March 1, so four quiet days aren't four missing days of records.

The tool shows inclusive overlaps for each pair of observed ranges and counts each source's rows inside them. It flags an informational gap only when the next first transaction is more than your chosen number of days past the end already covered. A shorter file nested inside a longer one won't shorten coverage or create a false gap.

Those notices need checking against statement headings, continuation pages and the bank's export-range selection. If you need to check that every requested month has a statement, enter explicit periods in the statement coverage checker. A dense transaction list or gap-free timeline can't prove all source documents exist.

In QuickBooks Online, the extra copy's location matters

Intuit's exclusion help, updated August 10, 2026, says duplicates may occur when a bank update follows a manual upload. If they're still in For review, selecting the extras and choosing Exclude moves them to Excluded. You can use Undo if you exclude a row by mistake.

Its duplicate troubleshooting page distinguishes pending bank-feed rows from entries already added or entered manually. That distinction determines the procedure: for an added feed entry, undo the addition, then match the existing record or exclude it.

Intuit starts with the bank statement. If the charge appears twice there, matching fields aren't a reason to erase a bookkeeping row. Before changing records, check linked payments, deposits and attachments, too. The local tool can't inspect these or tell you which ledger entry to keep.

Xero's duplicate report uses its own matching rules

Xero's Duplicate Statement Lines report documentation, opened October 17, 2026, describes comparing dates and amounts in the selected bank account, then seeking an exact match across reference, particulars or payee. One line's payee can even match another's reference.

The report doesn't show partial matches or duplicates identified and deleted at import. Those deleted duplicates appear in the Statement Exceptions report in the Bank Reconciliation report pack instead. An empty duplicate report therefore doesn't mean nothing was skipped earlier or that no partial match exists.

Xero warns that deleting a statement line changes the statement balance. Before following its removal procedure, run the report for the correct account and dates so you can compare candidates with the statement. The local tool's date, amount and description rule doesn't reproduce this report or predict what Xero will retain on upload.

YNAB may skip a transaction you've deleted

YNAB's File-Based Import guide, updated September 22, 2026, says imports match manual entries when amounts are exactly equal and dates are within ten days. Separately, repeated file imports or imports alongside Direct Import skip imported transactions with the exact same date and amount.

It also says an imported transaction you delete can't be imported into that account again. The documented options are manual entry or a replacement account that you move existing history into. Because this goes beyond ordinary CSV cleanup, read the full procedure and check the balance before changing accounts.

If an import reports skipped or no transactions, its reason, destination account, existing records and earlier deletions are the places to look. Changing dates, signs or identifiers to bypass duplicate suppression corrupts the evidence. Reconverting an unchanged PDF or downloading the CSV again won't reset the destination's import history.

The merge is ready for review, not straight to import

A finished merge should still be traceable to originals kept separately. Confirm that each output has one account, currency, date meaning and amount perspective, then check every exclusion against its source. Leave uncertain groups intact while you compare rows in, rows out and sums before and after, explaining each difference.

The merged CSV isn't guaranteed to import: its columns and dates may not suit your destination, and it includes extra account metadata and optional provenance columns. Make a separate copy in the required layout, keeping the full report and source-file and source-line columns for review even if the importer needs fewer columns.

Because the tool can't see your live destination, compare the upload with it separately. Inspect the import preview, then reconcile the account after importing.

If your missing source is a PDF, the bank's exports or your accounting app's native statement tools are the first options to check. You can transcribe a small file manually, too. AnyStatement can extract PDF statements into reviewable rows if that suits the job, but extraction won't compare the result with your live books or decide which repeated purchases are genuine.

What we checked, and what we didn't test

On October 17, 2026, we opened the linked QuickBooks Online US and YNAB web-import help pages. We read Xero's Duplicate Statement Lines article in a real browser with United Kingdom selected. Its matching rules, exclusions and deletion warning were visible without expanding anything. We didn't import into QuickBooks Online, Xero or YNAB, change any ledger, or test vendor duplicate suppression.

We independently checked the fictional file totals, removal total, six-row result and closing balance with Python Decimal. The tool's logic tests cover the example, repeated real purchases, account boundaries, exact large amounts, multiline source lines, day-tolerance chains, nested coverage, explicit decisions and formula-protected exports. Those checks cover the method and test data; they don't establish real customer accuracy or document authenticity.