How Tally catches duplicate transactions

If you import the same statement twice, Tally counts nothing twice. Each transaction gets a fingerprint, and any row whose fingerprint is already stored is skipped. There is one case it cannot match: the same account imported once as CSV and once as OFX.

What is the fingerprint?

A fingerprint is a short code made from the details of a row. Tally builds it one of two ways:

1. If the bank gives the row its own ID, the ID is the fingerprint. Wise does this. Every Wise transaction has a unique ID, so Tally uses it directly.
2. Otherwise, the fingerprint is made from the date, description, amount and running balance, plus a counter. TD’s downloads work this way, because their file has no transaction ID.

The fingerprint does not depend on what you named the account. So renaming “TD (CAD)” to something else will not make old rows look new.

Why is there a counter?

Because two real transactions can sometimes look exactly the same on every detail the file gives. If Tally only compared those details, it would take the second for a repeat and drop it.

The counter fixes that. It counts how many times an identical row has appeared within one file. The first gets 1, the second gets 2, and so on. Both are kept, and each has its own fingerprint.

Import the same file again and all rows are skipped, including both look-alikes. Tally’s test for this imports a sample file twice and gets 0 imported and 28 duplicates the second time.

What does Tally tell you after an import?

An import summary says how many rows were new, how many were duplicates and how many still need a category. If you re-import a file and see 0 new and all duplicates, that is the system working.

Can you download overlapping dates?

Yes, and it is a good habit. Download 30 or 45 days, even if last month’s file already covered half. The overlap is skipped. You do not need to work out the exact start date to avoid double counting.

What is the one case it cannot catch?

Tally cannot match the same real account when it comes in two different formats. If you import last month as a CSV and this month as an OFX file, Tally can end up with two accounts, and rows are not matched between them.

In Tally’s current design, each format creates its own account, so rows are not compared across the two. A person would know they are the same transactions. Tally does not.

What should you do about it?

Import each account from one format. Pick the format on the first import and stay with it. It is the simplest rule in the app. If you already have the problem, you will see two accounts for the same bank account in your list, and you can stop importing into one of them.

Why not just match on date and amount?

Because that would sometimes drop real transactions. Two payments of the same amount on the same day are common, such as transit fares or a split bill. A fingerprint that includes the running balance, and a counter for exact repeats, keeps the cases apart.

A quick check you can do

After an import, compare the number of new rows to your bank’s list. If the file covered 30 days, you expect about 30 days of new rows on the first import, and mostly duplicates after that.

If a row seems missing, check the file first. Then check whether the bank gave the row to you with a clear direction, if it was a PDF. Tally skips PDF rows without a direction marker and reports them. See statement file formats explained.

Tally is in development with no public sign-up. This guide describes how its import works today.