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

New Issue

GiteaMirror · 2026-04-26T01:24:46-05:00

GiteaMirror commented

2026-04-26 01:24:46 -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-04-26 01:24:46 -05:00

GiteaMirror closed this issue

2026-04-26 01:24:47 -05:00

GiteaMirror commented

2026-04-26 01:24:47 -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-04-26 01:24:47 -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-04-26 01:24:48 -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-04-26 01:24:48 -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-04-26 01:24:49 -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-04-26 01:24:49 -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-04-26 01:24:49 -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-04-26 01:24:50 -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-04-26 01:24:50 -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-04-26 01:24:51 -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-04-26 01:24:51 -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-04-26 01:24:51 -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-04-26 01:24:52 -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-04-26 01:24:53 -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-04-26 01:24:53 -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

claude/hide-default-categories-1cwBZ

matiss/crdt-source-loading

matiss/crdt-protobuf

release/26.5.0

claude/update-issue-template-ykMNn

claude/fix-issue-7667-DPXi3

cursor/formula-feedback-improvements-4223

cursor/resolve-pr-7449-ee11

claude/fix-typescript-build-error-JPtZ5

jfdoming/api-tokens-part-3

jfdoming/api-tokens-part-2

jfdoming/api-tokens-part-1

claude/speed-up-vrt-workflow-ZAyI5

claude/crdt-version-auto-publish-Ph1BH

copilot/add-repository-configs-to-packages

worktree-compressed-drifting-ritchie

worktree-mellow-strolling-dawn

matiss/browser-api

claude/api-consumer-verification-kfz1K

feature/enable-banking

cursor/transaction-table-rewrite-f077

pr-7454

claude/fix-issue-7410-LLLQ4

release/v100.0.0

revert-7350-trim-deps

revert-7220-sankey-report

revert-7242-fix/split-parent-update-corruption

revert-7281-generate-icons

claude/electron-to-tauri-migration-LjBN8

worktree-remotion

release/vv26.4.0-pre

claude/browser-compatible-api-QbhHh

claude/improve-cli-transactions-waTUY

claude/publish-react-native-ios-j8qoT

js-proxy

claude/fix-flaky-ci-job-5gDdz

react-query-rules

react-query-useSchedules

claude/nightly-theme-validation-scan-DzOGD

claude/debug-simplefin-error-ZuKzB

matiss/desktop-client-subpath-imports

claude/fix-simplefin-ssrf-T31gX

claude/release-notes-validation-X7rvR

add-claude-github-actions-1772738270730

cursor/sync-performance-notification-9899

react-query-prefs

matiss/chunked-sync-and-progress-ux

v26.2.1

copilot/sub-pr-6880

fix-react-query-clear-on-close-budget

copilot/sub-pr-6140

feat/auto-note

feat/scoped-bank-sync

cursor/desktop-transactions-react-table-1d0c

fix-exhaustive-deps-App

copilot/fix-find-replace-bug

release/v26.2.0-pre

matiss/browser-tests

mobile-fix-drag-and-drop-across-groups

budget-table-v2

PayeeAutocomplete2

pglite

bugfix/plugins/fix-plugins-sw

feat/plugins/plugins-core-package

prerelease

matiss/unicode-minus-fix

cursor/fix-actual-github-issue-6206-gemini-3-pro-preview-9c37

TransactionFormPage

cursor/implement-mortgage-and-loan-account-type-78ca

tests-update-fill-with-pressSequentially

mobile/link-modal

deps/25.11

cursor/fix-update-vrt-apply-ci-job-dispatch-b324

sync-server-plugins

cursor/propose-patch-for-github-issue-5680-2a18

fix/compiler-preserve-inner-dollar-escapes

cursor/analyze-actual-budget-issue-and-propose-fix-5b70

coderabbitai/docstrings/0c070e5

cursor/add-wip-prefix-and-comment-to-prs-d78d

jfdoming/08-21-auto-focus-on-navigate-in-all-browsers

show-totals-on-mobile-budget-banners

allow-child-transactions-make-transfer

mobile-calculator-keyboard

payee-geolocation

enhance/restore_scroll_position

dm-fix-second-click-on-mobile-new-transaction-2

scrollToLocationBudget

alert-autofix-38

tsconfig-composite

mobile-fix-uncategorized-transactions-on-tracking-budgets

server-budget-handlers

fix-sql-injection-in-cleanup-template

non-chrome-draggable-workaround

mobile-budget-page-swipe-navigation

ts-db-all

stable

dark-theme-with-brand-colors

fix-mobile-delete-group

ts-db-select

UnderKoen/reconcile-context-menu

master-before-server-merge

v25.2.1

ts-runQuery

rename-redux-hooks

UnderKoen/3557-persist-state-in-history

remove-redux-CLOSE_BUDGET

fix-exhaustive-deps-errors-FinancesApp

redux-toolkit-createSlice-backup

accounts-function-component

ts-useSplitsExpanded

loot-core-server-package

useTransactios-in-TransactionEdit

react-aria-input

move-redux-to-desktop-client

QueryState-type

fix-themes-applied-late

mobile-vrts

revert-3295-spendingCardFix

react-aria-button-4

split-payee-on-mobile

twk3/pin-apis-crdt

notes-tag-autocomplete

ts-LoadBackup

dnd-kit

package-upgrades

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/actual#41904