github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 07:04:23 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #2668] [Bug]: New transaction merging with unrelated older transactions on CSV import #115436

New Issue
Closed
opened 2026-06-11 06:51:59 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-06-11 06:51:59 -05:00
Owner
Copy Link

Originally created by @dugite-code on GitHub (Apr 26, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/2668

Verified issue does not already exist?

  • I have searched and found no existing issue
  • I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

What happened?

When importing a CSV file some of the transactions are being incorrectly merged with existing transactions.
This appears to happen if:

  • The transactions are within about week of each other.
  • The transaction dollar amount matches.

I would have expected having differing transaction dates and payee information would be enough to prevent the merging. These two data points appear not to be taken into account?

There appears to be no way to disable this functionality or to approve/disapprove merging transactions.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Firefox, Chrome, Microsoft Edge

Operating System

Windows 11

Originally created by @dugite-code on GitHub (Apr 26, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/2668 ### Verified issue does not already exist? - [X] I have searched and found no existing issue - [X] I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file) ### What happened? When importing a CSV file some of the transactions are being incorrectly merged with existing transactions. This appears to happen if: * The transactions are within about week of each other. * The transaction dollar amount matches. I would have expected having differing transaction dates and payee information would be enough to prevent the merging. These two data points appear not to be taken into account? There appears to be no way to disable this functionality or to approve/disapprove merging transactions. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Firefox, Chrome, Microsoft Edge ### Operating System Windows 11
GiteaMirror added the bug label 2026-06-11 06:51:59 -05:00
GiteaMirror commented 2026-06-11 06:52:02 -05:00
Author
Owner
Copy Link

@youngcw commented on GitHub (Apr 26, 2024):

Have you tried using the edge build? I believe the ability to disable matching was added recently. You can try the edge build using demo.actualbudget.org

<!-- gh-comment-id:2078591190 --> @youngcw commented on GitHub (Apr 26, 2024): Have you tried using the edge build? I believe the ability to disable matching was added recently. You can try the edge build using demo.actualbudget.org
GiteaMirror commented 2026-06-11 06:52:03 -05:00
Author
Owner
Copy Link

@dugite-code commented on GitHub (Apr 26, 2024):

Ah no I hadn't, I can confirm that solves the main issue. Thanks for that.

<!-- gh-comment-id:2078596176 --> @dugite-code commented on GitHub (Apr 26, 2024): Ah no I hadn't, I can confirm that solves the main issue. Thanks for that.
GiteaMirror commented 2026-06-11 06:52:04 -05:00
Author
Owner
Copy Link

@dugite-code commented on GitHub (Apr 26, 2024):

Actually now there is the issue that existing older transactions are added on import.

e.g. I get the last Months transactions from my bank even though I might have imported the csv file slightly more recently.

So really the Date and Payees really need to be considered during import to fix my issue.

<!-- gh-comment-id:2078599083 --> @dugite-code commented on GitHub (Apr 26, 2024): Actually now there is the issue that existing older transactions are added on import. e.g. I get the last Months transactions from my bank even though I might have imported the csv file slightly more recently. So really the Date and Payees really need to be considered during import to fix my issue.
GiteaMirror commented 2026-06-11 06:52:04 -05:00
Author
Owner
Copy Link

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

I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

👋 Where's the reproduction steps?

<!-- gh-comment-id:2081173391 --> @MatissJanis commented on GitHub (Apr 27, 2024): > I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file) 👋 Where's the reproduction steps?
GiteaMirror commented 2026-06-11 06:52:05 -05:00
Author
Owner
Copy Link

@dugite-code commented on GitHub (Apr 28, 2024):

👋 Where's the reproduction steps?

There aren't many reproduction steps, Just upload a CSV file where:

  1. The transactions are within about week of each other.
  2. The transaction dollar amount matches.

Note: CSV File Dates are in DD/MM/YYYY format and the Payee information is labeled Description
ExampleBudget.zip
init.csv - Initial transaction
example.csv -New unrelated transaction that gets reconciled with the initial transaction.

As mentioned disabling the reconciliation as in the latest edge release isn't really a fix as it shouldn't be unexpected you might encounter a transaction within a week of each other between import actions that has matching amounts.

Examples:

  • Go to the same cafe for the same coffee in the morning.
  • Weekly rent payments
<!-- gh-comment-id:2081316772 --> @dugite-code commented on GitHub (Apr 28, 2024): > 👋 Where's the reproduction steps? There aren't many reproduction steps, Just upload a CSV file where: 1. The transactions are within about week of each other. 2. The transaction dollar amount matches. Note: CSV File Dates are in DD/MM/YYYY format and the Payee information is labeled Description [ExampleBudget.zip](https://github.com/actualbudget/actual/files/15140689/ExampleBudget.zip) [init.csv](https://github.com/actualbudget/actual/files/15140690/init.csv) - Initial transaction [example.csv](https://github.com/actualbudget/actual/files/15140691/example.csv) -New unrelated transaction that gets reconciled with the initial transaction. As mentioned disabling the reconciliation as in the latest edge release isn't really a fix as it shouldn't be unexpected you might encounter a transaction within a week of each other between import actions that has matching amounts. Examples: * Go to the same cafe for the same coffee in the morning. * Weekly rent payments
GiteaMirror commented 2026-06-11 06:52:06 -05:00
Author
Owner
Copy Link

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

Thanks, that's very helpful.

As @youngcw already mentioned: the latest edge version has the ability to disable the transaction dedupe logic. If that still doesn't work for you - my other alternative is to import larger time ranges (i.e. a month instead of a week).

If that still doesn't satisfy you: my only remaining recommendation is to create a feature request with a description of how we could solve this problem better. Then we can discuss it and see where we can go from there.

Transaction dates and payees are intentionally not taken into account as they have proven to be unreliable. Especially for credit-card transactions.

But since this is not a bug, but rather an intended functionality (at least for now) - I'll close the bug report.

Hope you understand.

<!-- gh-comment-id:2081623464 --> @MatissJanis commented on GitHub (Apr 28, 2024): Thanks, that's very helpful. As @youngcw already mentioned: the latest edge version has the ability to disable the transaction dedupe logic. If that still doesn't work for you - my other alternative is to import larger time ranges (i.e. a month instead of a week). If that still doesn't satisfy you: my only remaining recommendation is to create a feature request with a description of how we could solve this problem better. Then we can discuss it and see where we can go from there. Transaction dates and payees are intentionally **not** taken into account as they have proven to be unreliable. Especially for credit-card transactions. But since this is not a _bug_, but rather an intended functionality (at least for now) - I'll close the bug report. Hope you understand.
GiteaMirror commented 2026-06-11 06:52:07 -05:00
Author
Owner
Copy Link

@dugite-code commented on GitHub (Apr 29, 2024):

my other alternative is to import larger time ranges (i.e. a month instead of a week).

Unfortunately as mentioned I already do this, this issue affects the tail end of the import making it difficult to identify the issue when the balances are thrown out of wack.

Transaction dates and payees are intentionally not taken into account as they have proven to be unreliable.

Well that is unfortunate, my bank never adjusts these so it's not something I was even aware of.

an intended functionality (at least for now)

One of the main reasons I noticed was a mortgage payment got merged with something else, so clearly not ideal for data integrity.

If that still doesn't satisfy you: my only remaining recommendation is to create a feature request with a description of how we could solve this problem better. Then we can discuss it and see where we can go from there.

Fair enough, I do have an idea, I'll give it some thought so I can put something understandable together as a request.

<!-- gh-comment-id:2081770783 --> @dugite-code commented on GitHub (Apr 29, 2024): > my other alternative is to import larger time ranges (i.e. a month instead of a week). Unfortunately as mentioned I already do this, this issue affects the tail end of the import making it difficult to identify the issue when the balances are thrown out of wack. > Transaction dates and payees are intentionally not taken into account as they have proven to be unreliable. Well that is unfortunate, my bank never adjusts these so it's not something I was even aware of. > an intended functionality (at least for now) One of the main reasons I noticed was a mortgage payment got merged with something else, so clearly not ideal for data integrity. > If that still doesn't satisfy you: my only remaining recommendation is to create a feature request with a description of how we could solve this problem better. Then we can discuss it and see where we can go from there. Fair enough, I do have an idea, I'll give it some thought so I can put something understandable together as a request.
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
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug
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#115436
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?