duplicate transactions imported: "already imported" error missing from the Chase bank feed
Fixes duplicate transactions imported from the Chase feed when the already imported guard never fired: dedupe by bank transaction id, void the copies, and repair the feed dedupe key. Use when Chase items appear twice in the ERP. Not for two genuinely separate identical payments.
TL;DR
Chase feed duplicates slip in when the import dedupes on amount and date instead of the bank transaction id, so a re-sent file or a feed retry creates fresh copies. Group the imported transactions by amount, date, and memo to find the duplicate sets, prove each copy shares one bank id, void the extras, and switch the import rule to dedupe on the bank transaction id so a resend cannot recreate them.
duplicate transactions imported: "already imported" error missing from the Chase bank feedUse this when
- The same Chase transactions appear twice in the ERP with identical amount, date, and memo.
- A feed interruption, retry, or manual file upload happened in the import window.
- Bank-side, each transaction exists once; only the ERP side doubled.
Not for this skill when
- Two identical payments were genuinely made, for example a rent payment sent twice. Both exist at the bank; that is a payment recovery issue.
- Duplicates come from a user manually entering items the feed also imports. That is a process fix, handled in feed rules training.
Steps
- Export imported Chase transactions for the window with bank transaction id, amount, date, and ERP record id. Verify: every row carries the bank id so duplicates can be proved, not guessed
- Group by bank transaction id and list every id with more than one ERP record. Verify: the duplicate set count and total are quantified
- For each set, confirm the bank shows the transaction once and pick the ERP record already matched or reconciled as the keeper. Verify: the keeper choice never deletes a reconciled record
- Void or delete the extra records with a memo citing the keeper record id. Verify: each bank id now has exactly one ERP record and the cash balance moves by the duplicate total
- Change the feed import rule to dedupe on bank transaction id and test with a re-sent file segment. Verify: the test resend imports zero new records
Variant phrasings
Chase bank feed duplicate transactions imported twice
The bank-specific duplicate phrasing.
bank feed dedupe transaction id not working
When fixing the rule, not just the data.
Compatibility: Chase bank feeds via Plaid, direct bank connections, and file import into QuickBooks, Xero, and NetSuite.
Why it happens
Bank feeds are at-least-once systems: retries and file resends are normal, so the importer must recognise a transaction it has already seen. Amount-plus-date matching fails on legitimately repeated amounts and on resends alike, and some connections regenerate internal ids per session, breaking naive dedupe. The bank transaction id is the only stable key; when the import ignores it, every transport hiccup becomes duplicate books.
Edge cases / pitfalls
- Pending then posted versions of one Chase transaction can import as two records with different ids. Match those by amount and memo within a few days before voiding.
- If duplicates were already reconciled, unreconcile carefully: voiding a reconciled record reopens a closed rec period.
- A manual CSV upload overlapping the automatic feed window is the other classic source. Note upload dates in the import log before blaming the feed.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstDUIf5Ojz19t5Ychr9LZdA