How Do I Stop Duplicate Transactions When Importing Bank Files?

Duplicate transactions when importing come from two causes: you imported overlapping date ranges, or you used a file format that carries no unique transaction ID. Bank feed formats like OFX, QFX and QBO include a per-transaction ID called FITID, and accounting software uses it to silently skip lines it has already seen. A CSV has no such field, so every CSV import is a fresh set of rows with nothing to match against.

That single distinction explains most of the duplicate messes people spend an afternoon untangling. Once you know which side of it you are on, both the prevention and the cleanup get straightforward.

Why duplicate transactions happen in the first place

There are really only four ways a transaction ends up in your books twice, and they compound with each other.

Overlapping downloads. You pull January 1 to March 31, then later pull March 1 to May 31 because you want the spring numbers. March now exists twice. This is by far the most common cause, and it happens because bank download screens default to a rolling window rather than picking up where you left off.

A feed and a manual import running at the same time. The connected bank feed pulls transactions automatically while you also upload a file for the same period. Neither one knows about the other unless the file carries IDs the feed already recorded.

Re-importing after an error. An import stalls, throws an error, or looks like it failed, so you run it again. Often the first pass actually committed some rows before it stopped.

A pending transaction that later posted. A card authorization for $42.00 gets downloaded, then settles at $42.87 with a different date and sometimes a different description. Software cannot always tell those are the same purchase, so you get two lines that look like separate charges.

What FITID actually does

Open an OFX, QFX or QBO file in a text editor and each transaction sits in a block that looks roughly like this: a transaction type, a posting date, an amount, a payee name, and a tag called FITID holding something like 202606030001. That FITID is the bank's own unique identifier for that specific transaction, and it does not change between downloads.

So when you import the same period twice, the software sees an ID it already stored and skips the line rather than adding it. That is the whole mechanism. It is not clever matching on dates and amounts; it is an exact ID lookup, which is why it is reliable when it is available and why its absence hurts so much.

Here is how the common formats compare on this specific point.

The practical takeaway: if you have a choice of download format and you expect to import more than once, take the OFX, QFX or QBO. If you only have a CSV, the duplicate protection has to come from your process instead of the file.

How do I prevent duplicate transactions in QuickBooks?

Import by date range, not by convenience. Before each upload, look at the last transaction date already in the account and start the new file the following day. QuickBooks will suppress repeats in a QBO file on its own, but a CSV gets no such protection, so the date boundary is doing all the work.

Two more habits matter. First, do not run a connected bank feed and manual uploads on the same account for the same period; pick one and stick with it for that account. Second, review the For Review queue before accepting anything. Once transactions are accepted into the register, removing them is much slower than excluding them beforehand.

How do I remove duplicate transactions that are already imported?

Work in the review queue if you can. In QuickBooks Online, transactions sitting in For Review can be selected and excluded in bulk, which is the fastest clean route. If they have already been accepted, you can undo the acceptance to push them back into For Review and then exclude them there. Deleting accepted transactions one at a time is the slow last resort, and it is risky once you have reconciled the period.

If the duplicates are in a spreadsheet rather than in software, the cleanup is easier. Sort by the transaction ID column and remove exact repeats. When there is no ID column, build a composite key in a helper column by joining the date, the amount and the description, then use Excel's Remove Duplicates on that column. Do not deduplicate on amount alone, because two genuine $12.99 subscription charges in the same month are not duplicates and you will delete real data.

Why do I get duplicates when importing a CSV?

Because a CSV is just rows of text with no identity. Nothing in the file says this is transaction 202606030001 at your bank, so the importer has no way to recognize a line it has seen before. It does exactly what you asked and adds every row.

That is worth knowing before you pick a format rather than after. If you are converting a PDF statement anyway, you can choose what comes out the other end: a PDF bank statement to CSV converter gives you rows for a spreadsheet, while the bank statement to QBO converter and the bank statement OFX converter produce files that carry IDs into your accounting software. If the rows are only ever going into a sheet, CSV is fine and you control duplicates by managing date ranges.

Can two transactions with the same date and amount be real?

Yes, often. Two coffees at the same shop on the same day, a split payment run in two halves, a monthly subscription that renews on the same date as an annual one at the same price. This is exactly why blind deduplication on date and amount is dangerous, and why a transaction ID is worth so much: it distinguishes two genuine identical charges from one charge counted twice.

When you have no ID and you are unsure, check the statement itself. The bank's own record is the tiebreaker, and it is one more reason to keep the PDF statement rather than only the export.

Merging several months without creating duplicates

This comes up constantly during catch-up bookkeeping, where you are assembling a year from a folder of downloads that may or may not overlap. The reliable process is:

Convert each file to rows and keep the transaction ID column. Stack every month into one sheet. Sort by transaction ID. Remove exact repeats, which are the overlaps. Then sort by date and check the row count against the statements. If your files were OFX, QFX or QBO, the OFX to CSV converter and the QBO to CSV converter both keep the FITID in its own column for exactly this purpose, and they run in the browser so the files are not uploaded anywhere.

Finish with a balance check. Take the opening balance for the period, add the sum of your amount column, and confirm you land on the closing balance from the last statement. If you are over, you still have duplicates. If you are under, a file is missing. That one arithmetic check catches both failure modes in about thirty seconds, and it is the same check that makes bank statement reconciliation work.

A short prevention checklist

Start every import the day after the last transaction already in the account. Prefer a format with transaction IDs when you have the choice. Never run a bank feed and manual uploads on the same account for the same dates. Review before accepting, because excluding is cheap and deleting is not. And when you are stitching months together in a spreadsheet, keep the ID column until the very end, then tie the total back to the closing balance.

Duplicates feel like a software problem, but they are nearly always a sequencing problem. Once the transactions are clean and deduplicated, the next step is usually sorting them into categories so the numbers mean something, and if the spending side is what you are chasing, a dedicated expense management tool will categorize receipts and card spend far faster than a spreadsheet will. From there, categorizing transactions from a bank statement covers the bookkeeping side of the same job.