Why Bank Feeds Create Duplicates, and How to Clear Them

Before feeds, everything was typed in and the errors were typos. Now most transactions arrive automatically and the errors are duplicates — which are harder to spot, because each individual entry looks perfectly legitimate.

Where they come from

Manual entry plus import. Someone enters a bill and pays it. The feed then imports the same payment from the bank. Unless the import is matched to the existing transaction rather than added as a new one, the expense now exists twice.

This is the most common source by a distance, and it happens most in businesses where more than one person touches the file.

Reconnecting a feed. Connections break — a password change, a bank migration, an expired authorisation. Reconnecting often re-pulls a window of history that was already imported. If nobody notices the overlap, every transaction in that window doubles.

The signature is unmistakable once you know it: a cluster of duplicates all dated within the same two or three weeks, all created on the same day.

Two connections to one account. Occasionally an account gets connected twice — through the bank feed and through a separate app or aggregator. Every transaction arrives from both.

Credit card payments. A payment from the checking account to the card appears in both feeds: as money out of checking, and as money into the card. Recorded as two separate transactions rather than one transfer, it becomes both an expense and a payment.

Why they are hard to see

A duplicate is not malformed. It has a real date, a real amount, a real vendor. Nothing about it looks wrong in isolation.

And the effect on reports is plausible rather than absurd. An expense category is somewhat higher than expected. Profit is somewhat lower. Neither is obviously an error, so it becomes the new normal, and the year-over-year comparison absorbs it.

The one thing that does catch them reliably is reconciliation. A duplicated expense means the book balance is lower than the bank, and the difference is exactly the duplicated amount. Which is another reason a forced reconciliation is so damaging — it makes the very difference that would have revealed the problem disappear.

Finding them in an existing file

Three passes, quickest first.

Sort by amount. Export a transaction detail report and sort by amount. Identical amounts to the same vendor within a few days of each other are the candidates. Legitimate recurring charges will show up here too, so check the dates.

Sort by date created rather than transaction date. This is the one that finds reconnection duplicates. A large batch of transactions all created on one day, but dated across several previous weeks, is the signature.

Check the transfer accounts. Look at how card payments and inter-account transfers were recorded. If they appear as expenses rather than transfers, that is a systematic error rather than an occasional one.

Removing them safely

Do not delete transactions in a reconciled period without understanding what it does to that reconciliation. Deleting a cleared transaction unreconciles the period and the balance no longer holds.

For duplicates inside closed periods, the safer route is usually a correcting entry with a clear description, leaving the change history visible. For open periods, delete the duplicate and re-reconcile.

Either way, fix the cause first. Removing four hundred duplicates while the double connection is still live means doing it again next month.

Prevention

Match rather than add when reviewing the feed — most software will suggest a match to an existing transaction, and accepting it is the correct action. Record card payments and inter-account movements as transfers. Check for a duplicate connection after any feed reconnection. And reconcile monthly, which is the control that catches all of the above within thirty days.

This is one of the more common findings in a cleanup, and preventing it is a large part of why reconciliation is not the optional step it looks like.