github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-03-10 04:02:38 -05:00
Code Issues 250 Packages Projects Releases 53 Wiki Activity

[Bug]: Importing via API silently matches with existing split transactions #2046

New Issue
Open
opened 2026-02-28 20:01:59 -06:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-02-28 20:01:59 -06:00
Owner
Copy Link

Originally created by @NikxDa on GitHub (Apr 14, 2025).

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

When importing with the Actual API, I see some transactions are randomly not imported. Looking through the source code, I noticed that some matching with existing transactions happens for non-bank-sync accounts (which have strict ID checking enabled). Notably, this matching also considers split transactions.

Example: I have a transaction worth -18.00 with imported_id equal to A. I split it into two with amount -9.00 each (both of which will have imported_id set to null) . I then try to import a new transaction with imported_id = B a couple days later, worth -9.00. Actual will match it with one of the previous split transactions, which is clearly wrong.

Expected: I see a few solutions

  • Split transactions should not be considered for matches
  • Split transactions should only be considered for matches if the parent has no imported_id
  • Strict ID checking should be able to be enforced via the API (which will still not work since this is a split transaction, I believe)

How can we reproduce the issue?

Please see above.

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome

Operating System

Mac OSX

Originally created by @NikxDa on GitHub (Apr 14, 2025). ### Verified issue does not already exist? - [x] I have searched and found no existing issue ### What happened? When importing with the Actual API, I see some transactions are randomly not imported. Looking through the source code, I noticed that some matching with existing transactions happens for non-bank-sync accounts (which have strict ID checking enabled). Notably, this matching also considers split transactions. Example: I have a transaction worth `-18.00` with `imported_id` equal to `A`. I split it into two with amount `-9.00` each (both of which will have `imported_id` set to `null`) . I then try to import a new transaction with `imported_id = B` a couple days later, worth `-9.00`. Actual will match it with one of the previous split transactions, which is clearly wrong. Expected: I see a few solutions - Split transactions should not be considered for matches - Split transactions should only be considered for matches if the parent has no imported_id - Strict ID checking should be able to be enforced via the API (which will still not work since this is a split transaction, I believe) ### How can we reproduce the issue? Please see above. ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome ### Operating System Mac OSX
GiteaMirror added the transactionsbugAPI labels 2026-02-28 20:01:59 -06:00
GiteaMirror commented 2026-02-28 20:02:00 -06:00
Author
Owner
Copy Link

@NikxDa commented on GitHub (Apr 14, 2025):

If somebody can recommend a solution, I am happy to implement it (though probably not very quickly)

@NikxDa commented on GitHub (Apr 14, 2025): If somebody can recommend a solution, I am happy to implement it (though probably not very quickly)
GiteaMirror commented 2026-02-28 20:02:00 -06:00
Author
Owner
Copy Link

@NikxDa commented on GitHub (May 14, 2025):

@youngcw Could I get your eyes on this one please, or can you recommend the right person to look at this? Like I said, happy to proceed with fixing this as long as I can get a second pair of eyes on it.

@NikxDa commented on GitHub (May 14, 2025): @youngcw Could I get your eyes on this one please, or can you recommend the right person to look at this? Like I said, happy to proceed with fixing this as long as I can get a second pair of eyes on it.
GiteaMirror commented 2026-02-28 20:02:00 -06:00
Author
Owner
Copy Link

@youngcw commented on GitHub (May 14, 2025):

I would think either your second or third option.

@youngcw commented on GitHub (May 14, 2025): I would think either your second or third option.
GiteaMirror commented 2026-02-28 20:02:00 -06:00
Author
Owner
Copy Link

@jonasludwig commented on GitHub (Jul 14, 2025):

@youngcw I just encountered the same issue when running my bank sync. The flow that led to the issue is as follows:

  • Bank sync creates a transaction with a value of -10. I create a split transaction for it because it falls into different budget categories and assign the values -4 and -6
  • Bank sync again. It contains a new transaction with value -4 which now gets matched to the split transaction created in the step before.
  • This leads to a difference of -4 in the cleared total, since the second transaction was included into the first, which is not correct. Instead, a new transaction should have been created.

To resolve this issue, I recommend to only consider split transactions ("child transactions") for matching on imports/bank syncs, when the transaction that is being matched has a parent transaction. If not, child transactions may not be considered for matching. This would resolve this issue.

@jonasludwig commented on GitHub (Jul 14, 2025): @youngcw I just encountered the same issue when running my bank sync. The flow that led to the issue is as follows: - Bank sync creates a transaction with a value of `-10`. I create a split transaction for it because it falls into different budget categories and assign the values `-4` and `-6` - Bank sync again. It contains a new transaction with value `-4` which now gets matched to the split transaction created in the step before. - This leads to a difference of `-4` in the cleared total, since the second transaction was included into the first, which is not correct. Instead, a new transaction should have been created. To resolve this issue, I recommend to only consider split transactions ("child transactions") for matching on imports/bank syncs, when the transaction that is being matched has a parent transaction. If not, child transactions may not be considered for matching. This would resolve this issue.
GiteaMirror commented 2026-02-28 20:02:00 -06:00
Author
Owner
Copy Link

@jonasludwig commented on GitHub (Sep 1, 2025):

I would like to bump up this issue since I encountered the bug again today. This is very confusing behaviour when trying to budget. The bug appeared in a similar fashion as described in my last comment. A transaction got created by my bank sync, I split it to multiple budgets and on a new bank sync another transaction got matched to one of the child transactions, which is not correct.

I suggest to not match to child transactions to avoid this bug.

@jonasludwig commented on GitHub (Sep 1, 2025): I would like to bump up this issue since I encountered the bug again today. This is very confusing behaviour when trying to budget. The bug appeared in a similar fashion as described in my last comment. A transaction got created by my bank sync, I split it to multiple budgets and on a new bank sync another transaction got matched to one of the child transactions, which is not correct. I suggest to not match to child transactions to avoid this bug.
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 API bug transactions
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#2046
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?