github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 07:01:45 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #6678] [Bug]: Merging transactions does not prevent reimport as duplicate #17065

New Issue
Closed
opened 2026-04-14 20:01:23 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-14 20:01:23 -05:00
Owner
Copy Link

Originally created by @junalmeida on GitHub (Jan 16, 2026).
Original GitHub issue: https://github.com/actualbudget/actual/issues/6678

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

If I have a duplicated transaction imported via Actual API, given one of them is already marked as a transfer, if I merge the duplicated with the transfer one, once I reimport it duplicates again.

It seems like Actual does not save the imported_id when a merge operation happens, allowing it to come back.

How can we reproduce the issue?

Note

Imports are being run using the latest npm actual api, using importTransactions method.
The issue also happens when importing a QFX through the UI.
OFX extension is blocked in GitHub, uploaded as txt.

It happens occasionally that the bank removes the transaction, and add another, sometimes even with a different date - bank is sending 1234 on day 1 while transaction is still pending, then post it with a different id on day 2.

Simulating a day 1 import: have a transaction imported with imported_id set to 1234.
On the UI, mark it as a transfer to another account.

On day 2, have the same transaction above reimported now with imported_id=12345, with the same amount. Date posted could be different.

See the duplicated transaction on the UI, merge it with the first one that is already a transfer.

Import the day 2 again - same transaction with imported_id=12345

See the duplicated transaction coming back instead of being ignored because it was merged.

test-day1.txt
test-day2.txt

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Linux

Originally created by @junalmeida on GitHub (Jan 16, 2026). Original GitHub issue: https://github.com/actualbudget/actual/issues/6678 ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? If I have a duplicated transaction imported via Actual API, given one of them is already marked as a transfer, if I merge the duplicated with the transfer one, once I reimport it duplicates again. It seems like Actual does not save the `imported_id` when a merge operation happens, allowing it to come back. ### How can we reproduce the issue? > [!NOTE] > Imports are being run using the latest npm actual api, using `importTransactions` method. > The issue also happens when importing a QFX through the UI. > OFX extension is blocked in GitHub, uploaded as txt. > > It happens occasionally that the bank removes the transaction, and add another, sometimes even with a different date - bank is sending `1234` on day 1 while transaction is still pending, then post it with a different id on day 2. Simulating a day 1 import: have a transaction imported with `imported_id` set to `1234`. On the UI, mark it as a transfer to another account. On day 2, have the same transaction above reimported now with `imported_id`=`12345`, with the same amount. Date posted could be different. See the duplicated transaction on the UI, merge it with the first one that is already a transfer. Import the day 2 again - same transaction with `imported_id`=`12345` See the duplicated transaction coming back instead of being ignored because it was merged. [test-day1.txt](https://github.com/user-attachments/files/24680271/test-day1.txt) [test-day2.txt](https://github.com/user-attachments/files/24680270/test-day2.txt) ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Linux
GiteaMirror added the transaction importbug labels 2026-04-14 20:01:24 -05:00
GiteaMirror commented 2026-04-14 20:01:24 -05:00
Author
Owner
Copy Link

@totallynotjon commented on GitHub (Jan 17, 2026):

I am encountering a similar issue, which I would venture is related. Occasionally, using bank sync, tranfers won't properly deduplicate when changing payees with rules . Merging the transfers won't stick and the import/resync will recreate the duplicate. I am going to take a looksy and will update if I think I can make the merge stick

<!-- gh-comment-id:3764322568 --> @totallynotjon commented on GitHub (Jan 17, 2026): I am encountering a similar issue, which I would venture is related. Occasionally, using bank sync, tranfers won't properly deduplicate when changing payees with rules . Merging the transfers won't stick and the import/resync will recreate the duplicate. I am going to take a looksy and will update if I think I can make the merge stick
GiteaMirror commented 2026-04-14 20:01:25 -05:00
Author
Owner
Copy Link

@totallynotjon commented on GitHub (Jan 17, 2026):

@junalmeida, as a workaround, you can likely disable the setting "Reimport deleted transactions" within bank sync settings, if you are close to reconciled.

Since the merged item is "deleted", if you do this then on re-sync or reimport the item shouldn't be brought in again. This approach also fixed my issue.

Image

Though I do see this as a potential issue with local accounts that do not have a bank sync.

For a local account, I was able to link a bank sync to an unrelated account, toggle the setting, and then unlink the account. After this the preference to not Reimport deleted transactions stuck for file import.

This is cumbersome, and there should probably be some change to make this easier to manage for local accounts.

Separately, while this workaround address this issue for me. I can see the upside in having a separate mechanism to track merged transactions beyond standard delete 'tombstone' column. As surely some people won't want no-reimport enabled for bank sync accounts, and will want their merges to stick.

<!-- gh-comment-id:3764456244 --> @totallynotjon commented on GitHub (Jan 17, 2026): @junalmeida, as a workaround, you can likely disable the setting "Reimport deleted transactions" within bank sync settings, if you are close to reconciled. Since the merged item is "deleted", if you do this then on re-sync or reimport the item shouldn't be brought in again. This approach also fixed my issue. <img width="1489" height="747" alt="Image" src="https://github.com/user-attachments/assets/779ea1bd-c019-41b8-81a5-db44155bedbd" /> Though I do see this as a potential issue with local accounts that do not have a bank sync. For a local account, I was able to link a bank sync to an unrelated account, toggle the setting, and then unlink the account. After this the preference to not Reimport deleted transactions stuck for file import. This is cumbersome, and there should probably be some change to make this easier to manage for local accounts. Separately, while this workaround address this issue for me. I can see the upside in having a separate mechanism to track merged transactions beyond standard delete 'tombstone' column. As surely some people won't want no-reimport enabled for bank sync accounts, and will want their merges to stick.
GiteaMirror commented 2026-04-14 20:01:25 -05:00
Author
Owner
Copy Link

@junalmeida commented on GitHub (Jan 20, 2026):

@totallynotjon I'm not using bank sync, I don't have it to enable this UI I guess

<!-- gh-comment-id:3775011189 --> @junalmeida commented on GitHub (Jan 20, 2026): @totallynotjon I'm not using bank sync, I don't have it to enable this UI I guess
GiteaMirror commented 2026-04-14 20:01:25 -05:00
Author
Owner
Copy Link

@totallynotjon commented on GitHub (Feb 10, 2026):

@junalmeida try out the pr I linked and let me know if that doesn't address your issue.

<!-- gh-comment-id:3875350887 --> @totallynotjon commented on GitHub (Feb 10, 2026): @junalmeida try out the pr I linked and let me know if that doesn't address your issue.
GiteaMirror commented 2026-04-14 20:01:25 -05:00
Author
Owner
Copy Link

@junalmeida commented on GitHub (Feb 20, 2026):

@totallynotjon I just tested the DEMO of your PR and it seems the setting in the import dialog box works as expected.

<!-- gh-comment-id:3936439204 --> @junalmeida commented on GitHub (Feb 20, 2026): @totallynotjon I just tested the DEMO of your PR and it seems the setting in the import dialog box works as expected.
GiteaMirror commented 2026-04-14 20:01:26 -05:00
Author
Owner
Copy Link

@totallynotjon commented on GitHub (Mar 17, 2026):

@junalmeida this has been merged into edge release and should be available in the next version

<!-- gh-comment-id:4077693282 --> @totallynotjon commented on GitHub (Mar 17, 2026): @junalmeida this has been merged into edge release and should be available in the next version
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug transaction import
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#17065
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?