Duplicate Transaction
A duplicate transaction is an imported row that matches one already stored for the same bank account, date, amount, and description, and it is skipped rather than inserted a second time.
In short
Re-importing the same statement is safe — matching rows are recognized and skipped, not duplicated. The one real gotcha: splitting one statement across multiple import calls can make genuinely repeated same-day charges, like two separate coffees, get misread as duplicates and silently dropped.
Also called: duplicate charge, duplicate import
A duplicate transaction is a row that matches one already stored for the same book, bank account, date, amount, and description. BalanceMCP detects this through a content hash computed from those fields, so re-importing a statement that's already been brought in inserts nothing new — every row is recognized and skipped rather than duplicated.
This makes re-importing the same statement completely safe, which matters in practice: if there's ever doubt about whether a statement was already imported, importing it again does no harm. The tool reports how many rows were duplicates and skipped alongside how many were genuinely new.
The real gotcha is the opposite direction: two genuinely distinct transactions that happen to share the same date, amount, and description — two separate $9.99 subscription charges on the same day, say — are told apart by their position within a single import call, not by anything else. Splitting one statement across multiple import calls breaks that positional tracking, so a group of truly identical, repeated charges straddling the split can be misread as duplicates and silently dropped, even though they were real, distinct transactions.
The practical rule this leads to is simple: import an entire statement in a single call. Find_anomalies also looks for duplicate-looking charges, but from a different angle — same vendor and amount charged more than once within five days — as a pattern worth a human's attention, not as the same mechanical dedup check applied at import.
What people get wrong
- Splitting one statement across multiple import calls — genuinely repeated same-day charges near the split point can be misread as duplicates and dropped.
- Hesitating to re-import a statement out of fear of duplicating it — matching rows are recognized and skipped automatically.
- Confusing import-time duplicate detection (exact match on account, date, amount, description) with find_anomalies' duplicate check (same vendor and amount within five days, a different, looser pattern).
Common questions
- Is it safe to re-import a statement I've already imported?
- Yes — matching rows are recognized and skipped automatically, and nothing gets duplicated.
- Why did some of my genuinely repeated charges get dropped as duplicates?
- Likely because the statement was split across multiple import calls. Genuinely identical, repeated transactions near a split point can be misread as duplicates — import the whole statement in one call instead.
Machine-readable: /api/knowledge/concept:duplicate-transaction