Troubleshoot missing or duplicate transactions
Work through the most common causes of transaction gaps and doubles in banking data.
Missing or duplicate transactions are among the most common issues raised with banking data. Most cases trace back to one of the causes below.
Missing transactions
Check these in order:
- Sync not yet complete. After a new consent is created, the initial sync takes time to finish. Don't query immediately after the consent is created — wait for the
banking.transactions.basic.sync.completedwebhook before pulling data. See the webhooks guide. - Wrong webhook event.
banking.transactions.sync.completedcovers detailed transaction data, which some institutions don't return — if you wait on that event, it may never arrive. Subscribe tobanking.transactions.basic.sync.completedinstead. - Date range filters. A
fromparameter may exclude the transactions you expect. Also note that date filters exclude transactions with no posting or execution datetime. Retry withoutfromto verify. - Status filter. If you query only
POSTEDtransactions, recently processed items may still bePENDING. Retry without thestatusfilter. - Data holder delay. Some institutions only surface new transactions after 24–48 hours. This is a limitation at the institution, not something a re-sync can fix.
- Institution not syncing. If an institution has a known incident, data won't update until it's resolved — see Institution outages and sync delays.
Duplicate transactions
- Pending followed by posted. Many institutions return a transaction as
PENDINGand later as a separatePOSTEDrecord — and thetransaction_idis not guaranteed to survive that transition. These represent one transaction's lifecycle, not true duplicates. See Filtering by status. - Multiple active consents. If a user holds two active consents covering the same accounts at the same institution, responses are de-duplicated so you receive unique transactions — but there's no guarantee which consent a transaction is attributed to. Revoke superseded consents to keep things simple.
- Re-sync after reconnection. If a user revokes and re-creates a consent, historical transactions sync again. Upsert on transaction ID rather than inserting blindly.
Deduplicate on transaction ID
Always de-duplicate on transaction_id, never on amount, description, or datetime.
Still stuck?
Contact support with the end_user_id, the consent ID, the institution name, the date range you expected data for, and any transactions you can confirm exist in the institution's own app. Support can check sync logs to confirm what the institution returned.