Duplicate transactions: why bank feeds create them and how to stop it

Duplicates are the single most common reason a reconciliation will not balance, in QuickBooks and Xero alike. They are also the easiest problem on that list to prevent, which makes the amount of time businesses lose to them slightly absurd.

Where they come from

The manual entry that the feed didn’t recognise

The dominant cause. Someone records a payment by hand. Days later the bank feed imports the same payment. The software’s matching logic compares amount, date and description — and any one of those failing to line up produces two records for one event.

The mismatches are entirely mundane:

• Date. The cheque was written on the 28th and cleared on the 3rd. Entered as the 28th, imported as the 3rd.
• Description. Entered as “Website redesign — Q3”. Imported as “STRIPE *AGENCYNAME 4471”. Nothing about those strings matches.
• Amount. The invoice was £1,200. The bank received £1,188 after a transfer fee, or £1,200 became $1,527 through an FX conversion.

None of these are user error in any meaningful sense. They are the natural gap between how a business describes a payment and how a bank describes the same payment.

Filling a feed gap with an import

The feed missed four days. You downloaded the statement and imported it. The date range you selected overlapped a day the feed had already delivered — or a day it delivered afterwards.

Every transaction in the overlap is now doubled. This is the most voluminous source of duplicates: not one or two, but everything in the overlapping window at once.

Reconnecting a broken feed

Reconnection often backfills a window of history. If that window reaches back past transactions already in the register, the backfill duplicates them. Fixing a broken bank feed is exactly when this happens, which means the cleanup and the outage arrive together.

Two connections to one account

Rarer, and mystifying when it happens. The same bank account gets connected twice — through two different institution entries, or through both a direct feed and an aggregator. Every transaction arrives twice, forever, and no amount of examining individual entries reveals why.

If duplicates are systematic rather than occasional, check the connected-accounts list before anything else.

Finding them in under a minute

Sort the register by amount, not by date.

That is the whole technique. Duplicates share an exact amount and sit days apart. Sorted by date they are separated by dozens of unrelated lines and effectively invisible. Sorted by amount they are adjacent, and a month of activity can be scanned in well under a minute.

Two refinements:

• Filter to the period first, so recurring legitimate amounts from other months don’t create noise.
• Watch for genuine repeats. A £49 monthly subscription is not a duplicate. The test is whether the bank shows one line or two — the bank statement, not your register, decides how many times money actually moved.

Which copy to delete

Delete the imported one. Keep the manual one.

The manual entry carries the work: the category, the class or tracking code, the customer or project link, the attachment, the tax treatment, the memo explaining what it was for. The imported line carries an amount, a date, and the bank’s own description string.

Delete the manual entry and someone has to recreate all of that from memory. This is how a five-minute cleanup becomes an hour, and it is the mistake almost everyone makes the first time, because the imported copy looks more “official”.

In QuickBooks, use Exclude on the banking screen rather than deleting outright — it removes the line from the feed’s review queue without destroying the record of it having arrived. In Xero, if the duplicates came from an import, undo the entire import rather than deleting lines individually; it is faster and it cannot pick the wrong copy.

The dangerous kind

Everything above is the visible case: the reconciliation will not balance, so somebody investigates.

The dangerous duplicates are the ones that do balance. If both copies get reconciled against two separate bank lines — which happens when a payment and its reversal both appear, or when a legitimate identical amount occurs twice in the period — the reconciliation completes cleanly while the expense is counted twice.

Your books balance. Your profit is understated. Nobody looks, because reconciliation passed.

This is the case for not treating a completed reconciliation as proof of correctness. It proves the totals agree. It does not prove the transactions mean anything. The discrepancy checklist covers the visible failures; this one hides behind a green tick.

Prevention that actually works

Stop entering transactions manually if the feed will import them. The single largest source of duplicates is doing the same job twice. If the feed reliably delivers an account’s activity, categorise from the feed rather than pre-entering and hoping the match lands. Enter manually only where the feed genuinely cannot see the transaction.

Never round an import range outward. Trim to the exact missing days. “A couple of days either side to be safe” is precisely the behaviour that creates the problem it is trying to avoid.

Check the connected-accounts list when duplicates are systematic rather than occasional. One account connected twice explains everything instantly.

Reconcile weekly rather than monthly. Not for tidiness — for scale. Five duplicates in a week are visible and cheap. Twenty across a month, mixed into eight hundred transactions, are a lost afternoon.

The underlying reason this exists at all

Duplicates happen because two systems independently observe one event and neither is authoritative. The business records what it believes happened. The bank reports what it processed. Software then tries to guess, from three fuzzy fields, whether two records describe the same thing.

That guess is doing remarkable work, and it will still be wrong sometimes, because it is reconstructing a relationship that was never recorded. The payment did not arrive carrying a pointer to the invoice it settles or the entry someone already made — that link is inferred afterwards from amount, date and a description string designed for a bank statement, not for matching.

Which is the actual argument for handling money and its record as one operation rather than two: not that matching is difficult, but that matching is only necessary because the connection was discarded at the moment it was free to keep. What an AI reconciliation agent actually does is largely to stop throwing that link away.

Where Fynex fits

Fynex creates the payment record at the moment the payment moves, and that record carries its own identity — which invoice it settles, which fee applied, which payout it belongs to, which party is owed.

There is one source for the payment rather than two racing each other, so there is nothing to match by amount and date and nothing to duplicate. A payment that arrives short, or with a deduction nobody expected, or with a reference that resolves to no open invoice, is flagged the same day as a specific exception — not discovered at month-end as a number that will not clear.

The best duplicate-handling process is the one you never have to run.