[GH-ISSUE #608] Importing transactions from OFX removes previously imported transactions #69985

New Issue

GiteaMirror · 2026-05-16T07:31:37-05:00

GiteaMirror commented

2026-05-16 07:31:37 -05:00

Originally created by @caseymullineaux on GitHub (Jan 28, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/608

I'm a new user trying to import several months of previous transactions so I have some data to play around with. I've exported the last three months (Nov 22, Oct 22, Dec 22) of transactions from my bank in OFX format in three separate files--1 file per month.

Starting at December and working backwards, I import the transactions for that month into a fresh install without any issues. I can see all 123 transactions in my account. Note the dates span the entire month from the 1st to the 31st (important later).

When I move onto importing the November transactions, the import dialog appears to be reading the November OFX file correctly. There's 107 transactions and all dates are showing for November as you can see below.

When I complete the import of those transactions from November, the previously imported ones from December go missing from the account. All the November ones are there, but any transactions after December 5 are gone.

If I continue and import transactions from October, the same thing happens to the November transactions just imported. October ones will import fine, but most of the November and December transactions are no longer there.

Originally created by @caseymullineaux on GitHub (Jan 28, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/608 I'm a new user trying to import several months of previous transactions so I have some data to play around with. I've exported the last three months (Nov 22, Oct 22, Dec 22) of transactions from my bank in OFX format in three separate files--1 file per month. Starting at December and working backwards, I import the transactions for that month into a fresh install without any issues. I can see all 123 transactions in my account. Note the dates span the entire month from the 1st to the 31st (important later). <img width="785" alt="image" src="https://user-images.githubusercontent.com/25874787/215295279-db541b7c-9cf6-4c92-803f-cd34f24d2158.png"> <img width="1088" alt="image" src="https://user-images.githubusercontent.com/25874787/215295332-c5264fdb-81f5-462a-b311-3b9658464e00.png"> When I move onto importing the November transactions, the import dialog appears to be reading the November OFX file correctly. There's 107 transactions and all dates are showing for November as you can see below. <img width="782" alt="image" src="https://user-images.githubusercontent.com/25874787/215295200-e547b93c-f22b-4db0-8eb7-2e70400cdd6c.png"> When I complete the import of those transactions from November, the previously imported ones from December go missing from the account. All the November ones are there, but any transactions after December 5 are gone. <img width="1081" alt="image" src="https://user-images.githubusercontent.com/25874787/215295450-74f703fb-3dcf-4f5c-88fb-3798aa724481.png"> If I continue and import transactions from October, the same thing happens to the November transactions just imported. October ones will import fine, but most of the November and December transactions are no longer there. <img width="803" alt="image" src="https://user-images.githubusercontent.com/25874787/215295678-57efe182-b7f3-412f-8c8f-a91efc1b1097.png">

GiteaMirror added the transaction import bug labels 2026-05-16 07:31:37 -05:00

GiteaMirror closed this issue

2026-05-16 07:31:39 -05:00

GiteaMirror commented

2026-05-16 07:31:40 -05:00

@MatissJanis commented on GitHub (Jan 31, 2023):

👋 Would you mind sharing an example OFX file and giving me the reproduction steps to better understand the issue?

Thanks!

@MatissJanis commented on GitHub (Jan 31, 2023): 👋 Would you mind sharing an example OFX file and giving me the reproduction steps to better understand the issue? Thanks!

GiteaMirror commented

2026-05-16 07:31:40 -05:00

@caseymullineaux commented on GitHub (Feb 2, 2023):

I'm not comfortable with sharing my banking information. Is there something else we can try?
Perhaps you have a few example OFX that you could provide to me that I could try import to see if it's a localised issue, or some additional troubleshooting steps that might generate some logs of some sort?
I'm a tech guy, so I've got no issues getting my hands dirty if it helps 👍

@caseymullineaux commented on GitHub (Feb 2, 2023): I'm not comfortable with sharing my banking information. Is there something else we can try? Perhaps you have a few example OFX that you could provide to me that I could try import to see if it's a localised issue, or some additional troubleshooting steps that might generate some logs of some sort? I'm a tech guy, so I've got no issues getting my hands dirty if it helps 👍

GiteaMirror commented

2026-05-16 07:31:41 -05:00

@MatissJanis commented on GitHub (Feb 2, 2023):

@caseymullineaux sadly we don't have an example OFX file. Which is exactly why I'm asking it from you. It doesn't need to have your real transaction data. Some fake data in it would be sufficient as long as it showcases the problem you're experiencing.

Another alternative is you try and debug the issue yourself. We're open to all PRs from the community (although the PR will still require sending an example OFX file so people would be able to actually test it).

@MatissJanis commented on GitHub (Feb 2, 2023): @caseymullineaux sadly we don't have an example OFX file. Which is exactly why I'm asking it from you. It doesn't need to have your real transaction data. Some fake data in it would be sufficient as long as it showcases the problem you're experiencing. Another alternative is you try and debug the issue yourself. We're open to all PRs from the community (although the PR will still require sending an example OFX file so people would be able to actually test it).

GiteaMirror commented

2026-05-16 07:31:42 -05:00

@j-f1 commented on GitHub (Feb 2, 2023):

Here’s one we do have from the test set: https://github.com/actualbudget/actual/blob/master/packages/loot-core/src/mocks/files/data.ofx. That said, there’s likely something specific about your file that‘s causing the issue. Maybe your bank is duplicating transaction IDs or something?

@j-f1 commented on GitHub (Feb 2, 2023): Here’s one we do have from the test set: https://github.com/actualbudget/actual/blob/master/packages/loot-core/src/mocks/files/data.ofx. That said, there’s likely something specific about your file that‘s causing the issue. Maybe your bank is duplicating transaction IDs or something?

GiteaMirror commented

2026-05-16 07:31:42 -05:00

@caseymullineaux commented on GitHub (Feb 3, 2023):

I've written a little python script to quickly parse and sanitize the transaction details of the export from my bank. The file structure and dates remain unmodified.

To reproduce the issue:

Download the three sample files below and remove the .txt extension.
Create a new account
Click Import and select 2022-12_clean.ofx
- 👀 Note that 123 transactions have been detected.
Click Import 123 transactions
- ✅ Confirm that all 123 transactions for December starting from 01/12/2022 and ending on 31/12/2022 are visible in the account
Click Import and select 2022-11_clean.ofx
- 👀 Note that 107 transactions have been detected
Click Import 107 transactions
- ✅ Confirm that all 107 transactions for November starting from 01/11/2022 and ending on 30/11/2022 are visible in the account
- ❗Note that all previously imported transactions for December after 05/12/2022 have been removed from the account. There are now only 16 total transactions for December (was 123).
Click Import and select 2022-10_clean.ofx
- 👀 Note that 105 transactions have been detected
Click Import 105 transactions
- ✅ Confirm that all 105 transactions for October starting from 01/10/2022 and ending on 31/10/2022 are visible in the account
- ❗Note that all previously imported transactions for December are still missing
- ❗Note that all previously imported transactions for November after 01/11/22 have been removed from the account. There are only now 2 total transactions for November (was 107).

@caseymullineaux commented on GitHub (Feb 3, 2023): I've written a little python script to quickly parse and sanitize the transaction details of the export from my bank. The file structure and dates remain unmodified. To reproduce the issue: 1. Download the three sample files below and remove the `.txt` extension. - [2022-10_clean.ofx.txt](https://github.com/actualbudget/actual/files/10574829/2022-10_clean.ofx.txt) - [2022-11_clean.ofx.txt](https://github.com/actualbudget/actual/files/10574831/2022-11_clean.ofx.txt) - [2022-12_clean.ofx.txt](https://github.com/actualbudget/actual/files/10574832/2022-12_clean.ofx.txt) 1. Create a new account 1. Click Import and select `2022-12_clean.ofx` - 👀 Note that 123 transactions have been detected. 1. Click `Import 123 transactions` - ✅ Confirm that all 123 transactions for December starting from 01/12/2022 and ending on 31/12/2022 are visible in the account 1. Click Import and select `2022-11_clean.ofx` - 👀 Note that 107 transactions have been detected 1. Click `Import 107 transactions` - ✅ Confirm that all 107 transactions for November starting from 01/11/2022 and ending on 30/11/2022 are visible in the account - ❗Note that all previously imported transactions for December after 05/12/2022 have been removed from the account. There are now only 16 total transactions for December (was 123). 1. Click Import and select `2022-10_clean.ofx` - 👀 Note that 105 transactions have been detected 1. Click `Import 105 transactions` - ✅ Confirm that all 105 transactions for October starting from 01/10/2022 and ending on 31/10/2022 are visible in the account - ❗Note that all previously imported transactions for December are still missing - ❗Note that all previously imported transactions for November after 01/11/22 have been removed from the account. There are only now 2 total transactions for November (was 107).

GiteaMirror commented

2026-05-16 07:31:43 -05:00

@Shazib commented on GitHub (Oct 25, 2023):

@caseymullineaux old thread but I think this is because your bank is duplicating the FITID tag.

According to the OFX specification <FITID> should be unique within the scope of an account to uniquely identify a transaction., but if you review your files, each month starts numbering them at 1.

So I suspect the parser is overwriting the transactions as they have the same ID.

You could try using your script to remove this tag entirely asn see what happens

@Shazib commented on GitHub (Oct 25, 2023): @caseymullineaux old thread but I think this is because your bank is duplicating the `FITID` tag. According to the OFX specification `<FITID>` should be unique within the scope of an account to uniquely identify a transaction., but if you review your files, each month starts numbering them at 1. So I suspect the parser is overwriting the transactions as they have the same ID. You could try using your script to remove this tag entirely asn see what happens

GiteaMirror commented

2026-05-16 07:31:43 -05:00

@rsi2m commented on GitHub (Jan 7, 2024):

I was able to reproduce this issue locally with latest versions. And in my case FITID were different. Here's the scenario:

Import ofx file for August with one transaction. All fine, one TX is displayed in UI:
Import ofx file for September with two transactions. Not fine, Two transactions are displayed. Both have september date, but one of them has August memo:

Attaching both ofx files here. Managed to reproduce this issue on a clean DB.
ofx-issue.zip

@rsi2m commented on GitHub (Jan 7, 2024): I was able to reproduce this issue locally with latest versions. And in my case FITID were different. Here's the scenario: 1. Import ofx file for August with one transaction. All fine, one TX is displayed in UI: ![image](https://github.com/actualbudget/actual/assets/1085942/39e06d7b-39f9-4951-a03c-b3ec1cafab2f) 3. Import ofx file for September with two transactions. Not fine, Two transactions are displayed. Both have september date, but one of them has August memo: ![image](https://github.com/actualbudget/actual/assets/1085942/2fc6fab7-6fbf-4764-83ad-8ea8b070c0b3) Attaching both ofx files here. Managed to reproduce this issue on a clean DB. [ofx-issue.zip](https://github.com/actualbudget/actual/files/13852822/ofx-issue.zip)

GiteaMirror commented

2026-05-16 07:31:44 -05:00

@MatissJanis commented on GitHub (Mar 26, 2024):

This might now be patched in the latest edge. I improved the transaction matching logic for imports.

Could someone please verify if the issue is resolved?

@MatissJanis commented on GitHub (Mar 26, 2024): This might now be patched in the latest `edge`. I improved the transaction matching logic for imports. Could someone please verify if the issue is resolved?

GiteaMirror commented

2026-05-16 07:31:44 -05:00

@rsi2m commented on GitHub (Apr 6, 2024):

@MatissJanis , Thanks for checking out this issue!
I've checked with Client version: v24.4.0 Server version: v24.4.0 - sadly, issue is still there.

@rsi2m commented on GitHub (Apr 6, 2024): @MatissJanis , Thanks for checking out this issue! I've checked with **Client version: v24.4.0** **Server version: v24.4.0** - sadly, issue is still there.

GiteaMirror commented

2026-05-16 07:31:45 -05:00

@rsi2m commented on GitHub (Apr 6, 2024):

I can reproduce the issue for .csv import as well:

aug.csv:

Date,Amount
20230830,-1.50

sep.csv:

Date,Amount
20230901,-1.50
20230901,-1.50

Result is the same: September transaction overwrite the one in August

@rsi2m commented on GitHub (Apr 6, 2024): I can reproduce the issue for .csv import as well: aug.csv: ``` Date,Amount 20230830,-1.50 ``` sep.csv: ``` Date,Amount 20230901,-1.50 20230901,-1.50 ``` Result is the same: September transaction overwrite the one in August

GiteaMirror commented

2026-05-16 07:31:46 -05:00

@MatissJanis commented on GitHub (Apr 6, 2024):

Ok, so this is the same issue as this one.

I've opened a feature request here that would address it: https://github.com/actualbudget/actual/issues/2561

PRs are welcome!

@MatissJanis commented on GitHub (Apr 6, 2024): Ok, so this is the same issue as [this one](https://github.com/actualbudget/actual/issues/2420). I've opened a feature request here that would address it: https://github.com/actualbudget/actual/issues/2561 PRs are welcome!

GiteaMirror commented

2026-05-16 07:31:46 -05:00

@Wizmaster commented on GitHub (Apr 18, 2024):

Hello @MatissJanis

I think it's not the same issue as in #2420 that is fixed in #2561. (at least the initial reported issue by @caseymullineaux)

I was hit by it also (my bank can generate OFX file that have inconsistent and sometimes re-used FITID) and my investigation leads me to believe the fuzzy matching in reconcileTransactions() is not at fault but rather the test made in the beginning of the function: if a transaction exists with the same FITID, it is merged with the incoming OFX transaction having that FITID, even if it's not the same amount, date or payee. This leads to disappearing transactions that were imported previously that share the same FITID and are replaced by new transactions.

I'm not sure what would be the best way to resolve the issue: add a new option in the OFX import screen to disable matching by FITID and only match by transaction details? I think it would solve the issue, at least for my OFX imports. (even better would be a way to configure a FITID pattern to ignore,in my case the wrong ids are using a date-like format that could be identified, but this is maybe way too niche as an option 😄 )

I can propose a PR with that

@Wizmaster commented on GitHub (Apr 18, 2024): Hello @MatissJanis I think it's not the same issue as in #2420 that is fixed in #2561. (at least the initial reported issue by @caseymullineaux) I was hit by it also (my bank can generate OFX file that have inconsistent and sometimes re-used FITID) and my investigation leads me to believe the fuzzy matching in reconcileTransactions() is not at fault but rather the test made in the beginning of the function: if a transaction exists with the same FITID, it is merged with the incoming OFX transaction having that FITID, even if it's not the same amount, date or payee. This leads to disappearing transactions that were imported previously that share the same FITID and are replaced by new transactions. I'm not sure what would be the best way to resolve the issue: add a new option in the OFX import screen to disable matching by FITID and only match by transaction details? I think it would solve the issue, at least for my OFX imports. (even better would be a way to configure a FITID pattern to ignore,in my case the wrong ids are using a date-like format that could be identified, but this is maybe way too niche as an option 😄 ) I can propose a PR with that

GiteaMirror commented

2026-05-16 07:31:47 -05:00

@MatissJanis commented on GitHub (Apr 19, 2024):

@Wizmaster Thanks for the explanation. But I really don't have ideas what to do in this case.. I mean - unique transaction IDs should be.. unique.

In this case I would actually recommend patching the incoming data (i.e. you could open up the OFX file and manually edit it to delete duplicated transaction IDs, or perhaps write a script that merges the transaction date + the ID (which should make them more unique)). Or perhaps even reaching out to the bank to get the data patched.

OFX spec on FITID:

An FI (or its Service Provider) assigns an to uniquely identify a financial transaction that can appear in an account statement. Its primary purpose is to allow a client to detect duplicate responses. Open Financial Exchange intends for use in statement download applications, where every transaction (not just those that are client-originated or server-originated) requires a unique ID.

@MatissJanis commented on GitHub (Apr 19, 2024): @Wizmaster Thanks for the explanation. But I really don't have ideas what to do in this case.. I mean - unique transaction IDs should be.. unique. In this case I would actually recommend patching the incoming data (i.e. you could open up the OFX file and manually edit it to delete duplicated transaction IDs, or perhaps write a script that merges the transaction date + the ID (which should make them more _unique_)). Or perhaps even reaching out to the bank to get the data patched. ---- [OFX spec](https://financialdataexchange.org/common/Uploaded%20files/OFX%20files/OFX%20Banking%20Specification%20v2.3.pdf) on `FITID`: > An FI (or its Service Provider) assigns an <FITID> to **uniquely identify a financial transaction** that can appear in an account statement. Its primary purpose is to allow a client to detect duplicate responses. Open Financial Exchange intends <FITID> for use in statement download applications, where every transaction (not just those that are client-originated or server-originated) requires a **unique ID**.

GiteaMirror commented

2026-05-16 07:31:47 -05:00

@Wizmaster commented on GitHub (Apr 19, 2024):

@MatissJanis It's unfortunate that some banks can export non-unique FITID in their OFX files. I read about another bank having the same kind of issue since at least 2016 and still not fixing it (https://akretion.com/fr/blog/lcl-ne-respecte-pas-la-norme-ofx - in french)

I thought a bit more about the situation and I believe that an update should be done to the FITID check at the beginning of reconcileTransactions(). Even if manually fixing the FITID before importing the OFX file is obviously possible, the import process should not lose existing transactions due to banks badly implementing the OFX spec.

I can update the query to match with the FITID and also the date and amount. If a transaction FITID becomes re-used, it would then not match and be matched with the correct transaction through the fuzzy matching happening after that.

It's not foolproof. If two transactions have the same date, amount and somehow exchanged FITID, it could still merge the wrong transactions. But I think overall it would still behave in a better way for most of the wrong OFX files.
It also should not modify the process for correctly formatted OFX files. Transactions with a stable FITID would have the correct date and amount and would be matched with the correct transaction accordingly.

It also means that it could result in several transactions using the same FITID. As far as I can see in the code, it should not have any adverse effects.

What do you think of this proposal?

@Wizmaster commented on GitHub (Apr 19, 2024): @MatissJanis It's unfortunate that some banks can export non-unique FITID in their OFX files. I read about another bank having the same kind of issue since at least 2016 and still not fixing it (https://akretion.com/fr/blog/lcl-ne-respecte-pas-la-norme-ofx - in french) I thought a bit more about the situation and I believe that an update should be done to the FITID check at the beginning of reconcileTransactions(). Even if manually fixing the FITID before importing the OFX file is obviously possible, the import process should not lose existing transactions due to banks badly implementing the OFX spec. I can update the query to match with the FITID and also the date and amount. If a transaction FITID becomes re-used, it would then not match and be matched with the correct transaction through the fuzzy matching happening after that. It's not foolproof. If two transactions have the same date, amount and somehow exchanged FITID, it could still merge the wrong transactions. But I think overall it would still behave in a better way for most of the wrong OFX files. It also should not modify the process for correctly formatted OFX files. Transactions with a stable FITID would have the correct date and amount and would be matched with the correct transaction accordingly. It also means that it could result in several transactions using the same FITID. As far as I can see in the code, it should not have any adverse effects. What do you think of this proposal?

GiteaMirror commented

2026-05-16 07:31:48 -05:00

@MatissJanis commented on GitHub (Apr 20, 2024):

Left a comment on the PR with my thoughts.

TLDR: I think the issue should be patched upstream instead of introducing a workaround in Actual that has the potential to break other workflows.

@MatissJanis commented on GitHub (Apr 20, 2024): Left a comment on the PR with my thoughts. TLDR: I think the issue should be patched upstream instead of introducing a workaround in Actual that has the potential to break other workflows.

Sign in to join this conversation.

Branches Tags

master

enforce-append-only-migrations-ci

delay-initial-sync-until-loaded

jfdoming/mobile-app-build

claude/error-codes-worker-boundary-26i5uu

jfdoming/api-tokens-part-1

jfdoming/api-tokens-part-2

jfdoming/api-tokens-part-3

jfdoming/mobile-app-updates

ai/simplify-categories-get-api

api-browser-custom-data-dir

claude/budget-version-migration-compat-151jlr

claude/worker-error-serialization-9iqtl7

claude/react-table-library-research-afx83z

claude/issue-8401-regression-test-9nw9l3

jfdoming/mobile-app-foundation-part-1

jfdoming/mobile-app-scaffold

release

ai-fix-cleanup-def-8290

claude/relaxed-shannon-jusywa

claude/fervent-keller-s6f2fq

claude/determined-feynman-st1y9z

claude/wizardly-einstein-vi2wce

claude/sweet-albattani-7nseio

feat/bank-sync-per-budget-file

claude/affectionate-cannon-y0kc82

claude/dependabot-findings-m9pgmb

claude/mac-app-ios-publish-zjs1lz

claude/vigilant-tesla-aiiyos

depot-migrate-secrets-1781296330308

claude/quirky-cerf-v5qck7

claude/animation-removal-alternative-2etfh1

claude/netlify-preview-comments-consolidate-9XPYa

osc/7391-error-boundaries-reports

claude/pensive-dijkstra-7DYui

claude/server-app-version-mismatch-HTCGv

claude/pr-8027-review-feedback-mELuO

claude/zealous-wozniak-e5pO0

claude/intelligent-heisenberg-BSHJq

claude/translation-download-refactor-jFRsO

claude/mobile-performance-ideas-G9PAO

claude/github-issue-7988-5A5ly

blacksmith-migration-ff70d2d

claude/great-mayer-KRvOk

claude/react-native-ios-compilation-fcJh5

claude/serene-goldberg-58xv0

claude/kind-euler-LVG3K

release-automation/edge-nightly

7710-bundle-migrations

claude/fix-docker-build-error-WMfed

claude/llm-compatible-release-notes-t20Nr

7710-tests-tdd

cursor/transaction-table-rewrite-f077

claude/plan-ci-secure-context-OtEe1

claude/fix-issue-7667-DPXi3

cursor/resolve-pr-7449-ee11

claude/fix-typescript-build-error-JPtZ5

copilot/add-repository-configs-to-packages

worktree-compressed-drifting-ritchie

claude/api-consumer-verification-kfz1K

pr-7454

claude/fix-issue-7410-LLLQ4

revert-7281-generate-icons

react-query-useSchedules

copilot/sub-pr-6140

package-upgrades

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/actual#69985