OFX FITID: transaction IDs and duplicate imports

An identifier answers which record, not whether it is correct

The OFX specification describes the Financial Institution Transaction ID, FITID, for identifying transactions in statement downloads. Its uniqueness is scoped to the financial institution and account; applications need that context when storing or comparing it.

The identifier does not establish that a date, amount or description is correct. Keep account and source information with it. A record with a unique ID can still contain an extraction mistake, and a receiving application decides how to use the identifier during import.

Two equal purchases still need separate identities

Imagine two genuine $12 parking charges on October 4, one in the morning and one in the evening. Their dates, amounts and short descriptions may be identical. They are still two transactions and should not be collapsed merely because those fields match.

By contrast, importing the same record from the same file again should not be treated as a third parking charge if the destination recognizes it as a repeat. This is why a date-plus-amount shortcut is an unsafe substitute for an identity strategy that distinguishes genuine repeated activity.

How Fulla writes the value

Fulla’s OFX exporter writes the persisted approved row’s transaction ID into FITID. Re-exporting that same saved approved revision retains those row IDs. The public sample OFX demonstrates this field using authored fictional rows.

Newly saved review revisions receive new persisted transaction IDs in the current implementation. Re-uploading or processing a statement separately also does not promise the same IDs. Do not describe Fulla’s identifiers as bank-issued values or assume they remain stable across separate uploads and review revisions. These distinctions are based on the current export and review code, not an observed third-party import test.

A stable ID does not settle an import overlap

Suppose you already imported revision A, then corrected a description and saved revision B. Even if most amounts are unchanged, revision B is a new persisted row set. Treat its overlap with the earlier import as a review task; do not rely on identical FITIDs to suppress every duplicate.

The same caution applies when a bank feed later delivers a transaction originally imported from a converted PDF. The two systems may identify the record differently. Compare account, dates, amount, references and destination state before deciding which copy to keep.

A useful file-inspection checklist

Inspect identifiers together with the surrounding transaction and account fields. Preserve the original export while you investigate, rather than editing IDs to force an import to pass.

• Confirm the OFX account and currency correspond to the intended destination.
• Check that separate transaction rows have separate IDs in the file.
• Distinguish a re-download of one approved revision from a new revision or separate upload.
• Review any overlap with earlier imports or bank-feed coverage.
• Keep the destination preview and final result as the evidence of what was accepted.

Specification version and export version are separate

The linked Financial Data Exchange reference is the OFX Banking 2.3 specification and explains identifier semantics. Fulla currently exports OFX 1.0.2 SGML, as shown by VERSION:102 in its sample file. Citing a newer reference does not mean Fulla emits that newer version.

Use the general OFX export guide for producing a file and the API guide for approved-revision handling. This reference focuses on the identity assumptions that matter when comparing records.