Find duplicate transactions

Why duplicates appear, how every import flags likely repeats before they land, and what merging a flagged draft into its match actually does.

Where duplicates come from

A duplicate is rarely typed in twice. It arrives twice: the same statement imported again, two exports whose dates overlap, or a receipt photographed for a purchase the bank statement also lists.

So SavingStat checks at the door. During every import, each incoming row is compared against your recent transactions in the wallet you are importing into, and a row that appears to repeat one of them is flagged before it can land. The flag sits on the draft, and drafts touch nothing until published, so a duplicate costs you a decision rather than a wrong balance.

What counts as a likely duplicate

A row is flagged when it matches a recorded transaction on amount, falls within a week of its date, does not conflict with it on currency or direction, and carries a description resembling the transaction's comment. The week of slack is deliberate: banks often book a purchase days after it happened.

A transfer between your own wallets is recognised too. The receiving wallet's statement shows a transfer as a plain credit, and that row is flagged against the transfer you already recorded instead of arriving as new income.

The check leans toward not flagging. A wrong flag risks you discarding a genuinely new transaction, so an uncertain match is left alone, and one recorded transaction is never offered as the match for two different rows.

Reviewing a flagged row

In the import's draft list a flagged row is marked Possible duplicate, and the mark is a link to the transaction it is compared with. The filters can narrow the list to just the flagged rows.

If the flag is right, choose Merge into existing. The draft is removed, its attached file and its link back to the import move onto the transaction you already had, and you choose whether the description and the date come from the existing transaction or from the draft. The existing amounts are not changed.

If the flag is wrong, publish the row like any other. A flag is a suggestion, not a decision made for you.

Duplicates already in your records

The comparison runs at import time against your recent history. It is not a sweep over everything you have ever recorded, so a duplicate that was published long ago will not be flagged now.

For those, the transaction list is the tool: narrow it to one wallet and read it in date order, and two records of the same purchase sit next to each other at the same amount. Find a transaction covers the narrowing. Deleting the copy you do not want puts the wallet's balance back where it should be.