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

New Issue

2026-02-28T20:01:59-06:00

GiteaMirror commented

2026-02-28 20:01:59 -06:00

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 transactions bug API labels 2026-02-28 20:01:59 -06:00

GiteaMirror commented

2026-02-28 20:02:00 -06:00

@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

@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

@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

@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

@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.