Why Duplicate Transactions Appear in Bank Feeds (and How Direct Open Banking Prevents Them)

A CPA on the QuickBooks community forums described spending two days manually deleting thousands of duplicate transactions after a bank feed update pushed 15 months of re-imported data directly into a client’s ledger. Auto-rules had accepted everything before anyone reviewed it.

Her conclusion: there is no way to prevent this from happening again.

That is partly true – and partly a function of the feed architecture she was using. The duplicate transaction problem is not random. Every type of duplicate traces to a specific point in how the feed collects, times, or re-delivers bank data. Change the architecture of the feed, and most of the sources disappear.

“Finance teams spend time clearing duplicates and adjusting reconciliation rules. What they rarely do is question the feed architecture that created them. That is the only level where the problem is actually fixed.” – Ravi, Finexer

TL;DR

Duplicate transactions in bank feeds come from five architectural sources: screen-scraping refresh cycles, batch sync timing gaps, legacy aggregator lag, feed reconnection re-imports, and manual entry conflicts with auto-rules. Each source creates unreconciled transactions downstream. Direct Open Banking AIS receives transaction events from the bank itself – three of the five sources disappear structurally because there is no refresh cycle to exploit.

What Is a Duplicate Transaction, and Why Does It Keep Coming Back?

A duplicate transaction is the same real-world payment appearing more than once in the accounting system. The transaction happened once. The feed recorded it twice – or three times after a reconnect.

An unreconciled transaction is different: an entry in the accounting system with no matching bank statement entry, or vice versa. Duplicate transactions cause unreconciled entries as a side effect – when the same payment appears twice in the ledger, one matches the bank statement, one does not.

The reason duplicates keep coming back after manual clearing is that clearing them does not fix the feed. The accounting software receives whatever the feed sends. If the feed keeps re-sending the same transaction under different conditions, the accounting software keeps creating a duplicate entry.

For AP invoices submitted twice at the vendor – a different problem at a different layer –duplicate invoice detection addresses that workflow separately.

What Are the Five Sources of Duplicate Transactions in Bank Feeds?

Understanding which source is generating the duplicates in a specific setup is the step most teams skip. They go straight to clearing. Here is what is actually generating them.

Screen-scraping refresh cycles. Aggregators like Yodlee log into the bank account on a timer and re-download the transaction list. Per Yodlee’s own developer documentation, a duplicate occurs when a transaction’s description changes between refresh cycles – the aggregator treats the change as a new transaction and both versions land in the feed.

Bank transaction descriptions change frequently: pending transactions update when they post, merchant names normalise, and references get amended. Each change is a potential duplicate.

Batch sync timing gaps. Platforms including QuickBooks Online request bank data in transaction windows rather than continuously. When a batch sync fails partway through and retries the full window, when a manual refresh overlaps with a scheduled sync, or when a date-boundary difference places one transaction into two consecutive windows, the same transaction appears in two separate download passes.

Legacy aggregator feed lag. Screen-scraping introduces a lag between a transaction occurring at the bank and appearing in the feed. During that lag, the pending version and the settled version of the same transaction can both arrive as separate feed items – one carrying the estimated amount, one the confirmed amount. Both appear as separate unreconciled transactions until one is manually excluded.

Feed disconnect and reconnect re-imports. When a bank connection breaks and reconnects, poll-based aggregators have no persistent delivery record. They re-download the full available transaction history from the new connection point.

The QuickBooks community documents this directly: one accountant described 15 months of client transactions downloading twice after a bank feed update, with auto-rules posting most of them to the ledger before anyone reviewed them.

Manual entry conflicting with auto-rules. Auto-categorisation rules in QuickBooks Online and Sage automatically post incoming feed transactions to the ledger. If a finance team member has separately entered the same transaction manually – a supplier payment, a salary disbursement, an expense claim – the rule fires on the feed entry and creates a second posted record alongside the manual one.

Every finance team I speak to wants a setting to turn off the duplicates. There is not one – because duplicates are not being generated inside the accounting software. They arrive with the data. Until the feed source changes, any fix inside QuickBooks or Xero is a recurring maintenance task, not a solution.

Why Does Direct Open Banking AIS Remove Three of These at Source?

The root difference between screen-scraping aggregators and direct Open Banking AIS is not data quality – it is the mechanism by which transactions arrive.

Screen-scraping and poll-based feeds operate on a pull model: the aggregator asks the bank for data on a schedule. How that question is answered depends on the session, the timing, and what state the bank’s interface is in at that moment. The variability in those answers is where duplicates originate.

Direct Open Banking AIS operates on a push model. Under the PSD2 framework, FCA-authorised Account Information Service Providers connect directly to the bank’s regulated API. When a transaction occurs, the bank pushes the event to the platform – with a stable, bank-issued transaction identifier that does not change when descriptions are later updated.

This architectural difference removes three of the five sources:

• No screen-scraping refresh cycle means description changes cannot generate duplicates
• Direct delivery of settled transactions reduces the lag window where pending and posted versions both arrive
• The PSD2 consent framework constrains reconnection behaviour – delivery is tracked against a defined consent window rather than restarting from a full history pull

The two sources it does not address – manual entry conflicts and AP invoice duplicates – sit at the platform configuration and AP layer respectively. For unreconciled transactions arising from manual entry errors downstream, the automated payment reconciliation guide addresses matching logic that catches discrepancies at that layer.

For a broader look at how bank statement feed architecture affects operational workflows, the bank statement automation guide explains what changes when the feed source changes.

How Does Finexer Prevent Duplicate and Unreconciled Transactions at Source?

Finexer provides FCA-authorised Open Banking AIS – the regulated direct bank API connection that accounting SaaS platforms, ERP systems, and finance automation tools used to replace screen-scraping and batch-poll bank feeds.

The architecture is straightforward: Finexer connects to UK bank APIs directly under its FCA authorisation (FRN 925695). Transactions arrive from the bank with stable identifiers and near-immediate webhook delivery – no polling, no refresh session, no re-download window. Coverage spans almost all major UK banks – high street, challenger, and business accounts – through a single integration point.

What Finexer’s AIS does not fix:

• Duplicate transactions already in an accounting system from manual entries made before the feed was replaced
• AP invoices submitted twice at the vendor level

The feed architecture change prevents new feed-layer duplicates. It does not retrospectively clean existing accounting databases.

For how the consent-driven access model underpins feed stability, theconsent-driven financial data guide explains the framework. When evaluating Open Banking providers on feed architecture criteria, evaluatingan Open Banking partner guide is the selection framework.

PSD2-compliant. Usage-based pricing, commercial terms agreed based on use case. 3 to 5 weeks of hands-on onboarding support.

“The teams that stop dealing with recurring duplicate transactions are the ones that changed the feed – not the ones that got better at clearing them.” – Ravi, Finexer

Where Do These Duplicate Sources Appear Most in Practice?

The same five sources show up differently depending on the platform type and how aggressively auto-rules are configured.

Accounting SaaS managing multi-client bank feeds. A practice running feeds for 40 SME clients on a Yodlee-based aggregator typically sees refresh-cycle duplicates spike after period-end – when banks update transaction descriptions in bulk. A single client resetting their bank credentials can trigger a reconnect re-import of 18 months of transactions overnight. The bookkeeper spends the next morning identifying which entries to exclude before the next sync runs.

Payroll SaaS with automated disbursement reconciliation. A payroll manager manually records a failed salary payment to track it for resubmission – standard practice. When the rescheduled payment settles and the feed downloads it, the auto-rule fires and creates a second posted record. The reconciliation report shows double the salary cost for that employee until someone traces it back to the original manual entry.

Insolvency and forensic accounting practice. A reconnect re-import that doubles six months of transactions does not just create extra work for an insolvency practitioner – it creates a materially incorrect financial picture that requires transaction-by-transaction verification before any figure can be used in court documentation. A direct bank API connection with a consent-window delivery record removes the reconnect source entirely.

About the Author

Ravi Ranjan

Ravi Ranjan is Co founder & CEO of Finexer