QuickBooks and Quicken both have good duplicate detection. It depends entirely on one field, and converters get that field wrong more often than they get it right.
What it is
FITID stands for Financial Institution Transaction ID. In the OFX specification it is a text value of up to 255 characters that the institution assigns to each transaction, unique within the account and never changed once issued. Every transaction in an OFX, QBO or QFX file carries one, inside its STMTTRN block.
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20260315
<TRNAMT>-45.20
<FITID>4f9c2a71e0b3d815 <- this transaction’s identity
<NAME>SHELL OIL
</STMTTRN>
<STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20260316
<TRNAMT>1250.00
<FITID>a07d5be19c44f260
<NAME>ACME LTD
</STMTTRN>On import, QuickBooks and Quicken check whether they have already seen that FITID on that account. If they have, the transaction is skipped. That is the entire duplicate detection mechanism: it does not compare dates, amounts or descriptions. Two transactions with the same FITID are the same transaction; two with different FITIDs are different transactions, however identical they look.
A converter that derives each identifier from the transaction itself produces the same file every time from the same statement, which is the property duplicate detection actually needs.
Which formats have one
| Format | Per-transaction ID | What a re-import does |
|---|---|---|
| QBO (QuickBooks) | FITID | Repeats recognised and skipped |
| QFX (Quicken) | FITID | Repeats recognised and skipped |
| OFX | FITID | Depends on the importer; many use it |
| QIF | None | Every row imported again |
| CSV | None (a reference column is not treated as one) | Every row imported again, or matched on date and amount |
| IIF | None | Written to the register again, no warning |
| Tally XML | None for imported vouchers | A second set of vouchers |
This is the real argument for the OFX family over CSV and QIF. The data is the same; what differs is whether the software can tell a transaction it already holds from a new one. Not every importer uses the FITID the same way, and Xero, for example, points people at matching on date and amount when lines have doubled, but QuickBooks and Quicken lean on it entirely.
Why converted files duplicate and bank files do not
A bank generating its own file has a natural FITID: its internal reference for that transaction, stable forever. A converter reading a PDF has no such thing, because statements do not print it, and must invent one. Whether re-importing is safe comes down entirely to how.
| Scheme | Same statement, converted twice | Verdict |
|---|---|---|
| Timestamp or random number | Every ID different | Duplicates every time |
| Row counter (1, 2, 3 ...) | Same only if the row count and order are identical | Duplicates after any correction; collides across files |
| Hash of account, date, amount and description | Every ID identical | Works |
| Hash plus an occurrence counter within the day | Every ID identical, twins kept apart | Works, including identical transactions |
The row counter deserves a word, because it looks reasonable. Number the transactions 1 to 40 and the IDs are stable, until a re-conversion picks up one extra row near the top and every identifier after it shifts by one. Worse, the next month’s file also starts at 1, so its first transaction now claims to be last month’s first transaction and is silently skipped.
The two-minute test
Convert the same statement twice. Open both files in a text editor and compare the FITID values. If they differ, that converter will duplicate every time you re-import, and nothing you do at the QuickBooks end will prevent it. Then check that the first FITID in two different months’ files is not the same value.
The other duplicate source: two feeds
If an account is also connected to your bank directly, the live connection and your imported file are two separate sources for the same transactions, with two separate sets of identifiers. The bank’s own FITIDs will never match a converter’s, so both sets land.
Import files only for periods the connection does not cover. Many connections reach back around ninety days when first set up, though some go further; anything older is where a converted statement earns its place. The safest habit is to look up the earliest transaction the feed brought in and end your imported file the day before it.
What a stable FITID cannot fix
Two genuinely identical transactions on the same day, such as a pair of matching fees or two identical transfers, will hash to the same content and therefore the same FITID if nothing else is added, and the second will be skipped as a duplicate when it is not one.
A good implementation disambiguates by adding an occurrence counter within the day, so the first and second identical transactions differ while remaining stable across conversions. It is worth checking your converter handles this if your statements contain repeated identical amounts: count the rows in QuickBooks against the statement for a day that has twins.
A stable FITID also cannot rescue a statement that was read wrongly. If an amount was misread, the identifier is stable and wrong, and fixing the amount later produces a new identifier for what QuickBooks then treats as a new transaction. Checking the conversion against the statement’s running balance before the first import is what keeps that from happening.
Matched is not the same as accepted
A transaction that reaches the banking feed and sits there unaccepted has still been recorded as seen. Its FITID is remembered, so re-importing the same file will not bring it back a second time, which surprises people who excluded a batch intending to re-import it more carefully.
Excluding from the feed and deleting from the register are different operations with different consequences, and only one of them is easily reversed. Work in the feed while you still can.
Changing converter mid-year
Two converters will not produce the same identifiers for the same transactions, because there is no standard for deriving one: each picks its own scheme. So switching tools partway through a year makes every subsequent import look entirely new to QuickBooks, including any period that overlaps what you already imported.
This is not a reason to avoid switching. It is a reason to switch at a period boundary, and to check the date range of the first file from the new tool before importing rather than after.
Reading FITIDs when something has already doubled
- 1Find one duplicated pair in the register and note its date and amount.
- 2Open each file you imported for that period in a text editor and search for the date in YYYYMMDD form.
- 3Compare the FITID lines for the matching amount. Different values in two files explain the duplicate; the same value means the doubling came from somewhere else, usually a bank feed.
- 4Remove the extra set from the feed or register, then re-import only from a converter whose IDs survive the two-minute test.