Downloaded transaction matches one that's already cleared

Jeff Kowalski

I have a recurring transaction that executes every week at my bank. When I update quicken and the transaction is downloaded, it very often matches one of the earlier transactions in the register that is already cleared. This is particularly odd because there's an uncleared transaction also in the register with same payee and amount and more appropriate date (and uncleared status).
Why is quicken preferentially matching the older cleared transactions?
version R25.21
build 27.1.25.21

Frankx

HI @Jeff Kowalski,

I can't really answer your "why" question, however have you tried clicking the "edit" button for the transaction and  selecting "unmatch"?  If you do, i believe that it will select the next (dated) transaction of your "recurring transactions".  And maybe that will also put you back in synch going forward.  [I can't test or simulate this, but I seem to recall having a similar problem some time ago and I think this is how it may have been corrected.]

Frankx

Frankx

HI @Jeff Kowalski,

I can't really answer your "why" question, however have you tried clicking the "edit" button for the transaction and  selecting "unmatch"?  If you do, i believe that it will select the next (dated) transaction of your "recurring transactions".  And maybe that will also put you back in synch going forward.  [I can't test or simulate this, but I seem to recall having a similar problem some time ago and I think this is how it may have been corrected.]

Frankx

Jeff Kowalski

Interesting, @Frankx. Thanks for the suggestion. I will try it next Saturday when the next batch of automatic transactions will be downloaded for reconciliation. I have some skepticism that the "unmatch" will advance the matching algorithm to the correct transaction and reset it thereafter, but I am certainly willing to give it a go. Will post results here.

Jeff Kowalski

@Frankx, today I had an instance of the downloaded transaction matching an already-cleared one. In fact, it matched the earliest non-reconciled one. Taking your suggestion, I selected "edit/unmatch" and it moved to the next non-reconciled, already-cleared one. Another "edit/unmatch" and it skipped to the one I expected, a non-cleared recent transaction.
So far, your remedy addresses the issue of the current match. I'll see next week if that has re-synched the transaction matching going forward. I will report back with that result.

Frankx

Hi @Jeff Kowalski

Well, that's very encouraging.  And at least you know how to get it to unmatch and then get to the correct match.

Let us know if the "fix" holds going forward.

Take care & stay safe!

Frankx

Chris_QPW

I can give a bit of insight why Quicken is matching the older one.

Quicken can't use the "exact date" for the very fact that you don't know it. In other words when you entered the transaction in the register you might have put in say 3/21/2020, but it posted on 3/22/2020. So clearly Quicken can't rely on the date you put in. The match has to be "fuzzy" as far as the date goes.

So when there is a case where you have two unmatched transactions with the same amount (and I think payee, because they do seem to take the payee into account) they choose to match oldest first.

Now one might argue that they should do a "closest match", but they don't and even that isn't "exact". As in you might have entered the transaction as 3/23/2020 and still expect it to match with 3/22/2020. And if you have multiple transactions that would match with the exception of the date then it might hard/impossible to say which is "closer".

Personally I think they should still try, but the developers have clearly decided that they don't want to do it that way.

Jeff Kowalski

@Chris_QPW, the puzzle isn't so much why it's not matching the date, it's why is it preferring to match an already-cleared transaction when there's an uncleared, unreconciled transaction also available? I understand what you mean by fuzzy matching for getting close matches. In my case, the match to uncleared item would be spot-on and most reasonable.

Chris_QPW

Quicken doesn't look at the cleared status at all to determine if to match or not.

I think the main reason for this is for the use case where someone is switching from manual entry to downloading transactions.

Quicken looks at the "Downloaded Posted Date" field (actually a hidden one) to determine if the transactions has ever been matched to a downloaded transaction of not. This is what it uses to decide if it valid to try to match to this transaction or not.

Jeff Kowalski

Thanks for the clarification, @Chris_QPW. It's hard for me to understand why it's preferable to match cleared transactions. One would imagine *that* would be the edge case, and matching the next available uncleared one would be the more reasonable default. Or, allow for a optional preference (e.g. "Match cleared transactions").
With @Frankx 's help, I can now correct a single match, and hopefully things are resynched as discussed above.

Chris_QPW

@""Jeff Kowalski"
I agree with you it doesn't seem right, and there have been other problems caused by their decision, but of course I can dictate to them what they should do.

The "other problem" is for the manual match list. Since it used this hidden field for the posting date and build the manual match based on it there have been many complaints that there are transactions "stuck" on that list and the user can't get them off it.

PeteTheGolfer

I have a related issue, so I think it's appropriate to mention it here. I have one transaction that refuses to match with any transaction, including the uncleared one that it's supposed to match with. Every month, I have to manually match that one transaction.

The only thing that's unique about it is that I pay this bill using "Bill-Pay" from my credit union, instead of sending a check or using my credit card.

I wonder if anyone has any thoughts about this situation.

Jeff Kowalski

@Frankx, last week I was able to unmatch the falsely-matched transaction and then ultimately accept the proper match. I was hoping that would "resync" the matching. Regrettably, it did not. This week's downloads are still matching the same already-cleared transactions. Unmatching until I get to the correct one does work, but I had hoped to not be stuck in the gravity well of cleared transactions.
As far as I can say, the matching algorithm is just "broken". I can't see why anyone would want the current behaviour by default.

Frankx

Hi @Jeff Kowalski,

Sorry to hear that the "fix" didn't hold going forward.  I believe that you are correct about the "broken" algorithm, and hope that the technical folks have this on their list of things to correct.

Take care & be safe!

Frankx