Transaction matching on import

[andrew-hill]

My bank doesn't offer OFX, only CSV and QIF so I don't get the nice auto matching of transactions in the import window. But I don't really see why not...

Each time I import, I download the last N days from my bank, always with some overlap with the last import (sometimes a huge overlap).

I find it odd that the import window shows only the Unreconciled transactions from the existing data. For me it means i never see much/any history so have to go back to the main window to see where I last imported to.

Yet it should be dead simple to do this automatically, and auto select only the transactions that are new.

1. The most recently imported transaction for the account could be recorded, and only newer transactions selected by default in the import window
2. The date and amount in the import data should be identical if there's an existing transaction, and it's likely the description and payee will either match or partially match (even if I was forced to only append notes to the description, not change it entirely, for CSV/QIF auto matching). It should be easy to detect the prior transactions.

At the very least, there should be an option to show reconciled transactions too, and maybe enable/disable the "guessing" methods of matching non-OFX transactions.

[hsoft]

I've always been suspicious of the auto-matching feature in other money management software. You're never too sure how they do it, and you don't trust it, and then you're never sure that your data imports correctly. That's probably why implementing such a feature was never high in my priority list.

But yes, I agree, it can be a time save in some situation. I'd see it as a manual option though. Something like "auto match selected entries". If you entirely trust the matching algorithm, you select everything and click on the button. If you're more suspicious, you can do it one entry at a time (and, with time, gain trust).

As for seeing reconciled entries, I agree with you. The "unreconciled" filter was because I didn't want the list to be too big and I didn't think it was possible to match entries with already reconciled entries, but I've encountered situations where this wasn't the case, so I'm with you here.

We can limit the number of shown transactions with something like "X days before the earliest imported transaction".

[andrew-hill]

Sounds good

I'd also think you could estimate how likely the matches are. Eg if you don't get perfect 1;1 matching for a contiguous chunk of the new/import data from start up to the end of the existing data, then don't auto match. Or highlight all discrepancies in bright red so the user can see if any entries are unmatched or the match isn't perfect, and decide if that's because they edited/added entries or if it's because the matching failed.

[brownnrl]

Can we turn this to accepted?

In #26, I actually have this mostly implemented. Before I worked on the intelligent import autofill of the transfer column, I wanted to break out the existing import actions and binding logic into plugins. The reference matching (existing code) was broken out into one binding plugin, and then the transaction matching (which was a use case of mine) was broken out into another.

The binding plugins return match suggestions in the form of a tuple with the existing entry (whether or not reconciled), the imported entry, and a weight factor (right now between 0 and 1 called probability which is a fast and loose term in this context). The core code combines the best matches together, then ensures that user hand selected binds / unbinds are honored.

The added binding plugin is, for the most part, a word-for-word implementation of this ticket without the contiguous transaction checking (though that can be put into the logic).

I didn't read this ticket beforehand. I don't know why I did the added work in #26, I guess I was considering the entire import process. Even with the upcoming design changes (potentially removing the Document subclassing from the implementation), I'm willing to take this ticket and #26 to completion as part of the same effort.