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

[NikxDa]

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

[NikxDa]

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

[NikxDa]

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

[youngcw]

I would think either your second or third option.

[jonasludwig]

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

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.