[Bug]: New transaction merging with unrelated older transactions on CSV import

[dugite-code]

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

[youngcw]

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

[dugite-code]

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

[dugite-code]

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.

[MatissJanis]

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?

[dugite-code]

👋 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

[MatissJanis]

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.

[dugite-code]

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.