Investment Transaction Matching - New vs. Near Match issues
When new investment transactions are downloaded, Quicken is inappropriately flagging them as "near match". Typically, these are weekly or bi-weekly automatic investment transactions. Each transaction is for the same security, but the price and share count are different. Quicken is matching them to transactions from the previous week (or two weeks prior).
This was an issue in June 2024. The issue went away but returned as of about a week ago. My only workaround is to un-match every transaction before processing them, but that gets old.
Footnote: The account is a Vanguard account, where I had to manually download transactions for several weeks in late February, until their connection issue was corrected. They're all marked as "cleared", but maybe something different about them that makes look like manual entries.
I wish Quicken would consider 1) Adjusting the algorithm that does matching (make it "smarter") or 2) Add an option to turn off matching completely, because it is seriously unhelpful right now.
Comments
-
Presumably this Near Match is to a transaction that is already in your transaction list (register). Is it really finding a near match to a transaction that is already marked as Cleared? That does not sound right.
How often do you normally download transactions from Vanguard? If you do it often enough that there will only be one set of transactions to match to, that should avoid this problem.
How do you think the algorithm might be adjusted to make it "smarter"?
QWin Premier subscription0 -
Depending on how you are doing this, you can set yourself up for endless false matching.
I'm not 100% sure that it works this way, but in non-investment accounts it does, so I assume it works the same in the investment accounts too.
"Possible matches" are transactions entered into the register that have yet to be matched to a downloaded transaction.
So, let's say you enter a transaction. Later you download and Quicken says that is a match (or near match), and you unmatch it and delete the downloaded transactions (because you feel the one in you entered is right, and the downloaded one is wrong). Well, you now have a transaction that has never been matched to a downloaded transaction, and so it will remain as a "possible match". Needless to say, this can lead to an endless cycle of doing the same thing.
Also, one thing about Quicken's matching is that it doesn't use the date to decide which to match to (other than I think there is a limit of how far back it will look). It will "match the first/oldest" not the one that is closest date wise if there is more than one transaction that can be matched.
And BTW for "Near Matches" I have found that usually when that happens to me it is because of the fact that the "calculation" is slightly different, maybe out to several digits. For instance, the price that it really sold for (or at least was downloaded as) is slightly different than what you have entered.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
So "has been matched to a downloaded transaction" is hidden and different from "is Cleared"? That sounds like a problem.
What I see for banking transactions is that it declares a match if the amount in the register is the same as the downloaded amount and the date in the register is between 15 days before and 1 day after the downloaded transaction.
For investing transactions it appears that the dates must match exactly, which makes sense to me.
QWin Premier subscription0 -
I will definitely admit that I haven't tested in any way (other than the fact that I have encountered the near match a few times). So, the part like if the date has to be exact or some limited time or such I don't know for sure. But I do doubt that it has to be the exact same date, in fact if being a different date, might be exactly what makes it a "Near Match" instead of a "Match".
After all, if it had to be the exact date or even within a day or two would I don't think @Fred Coale would be having a problem.
But one thing I know for sure just because a transaction is marked cleared or even reconciled doesn't take it off of the list of transactions that Quicken tries to match to. It is fact that a manually entered transaction has been matched to a downloaded one, that takes it off the list.
Signature:
This is my website: http://www.quicknperlwiz.com/0 -
@Chris_QPW I think you are right about Match vs. Near match. What I do when I get a Near Match is to edit the transaction in the Transaction List to agree with the download before accepting the downloaded transaction. That makes it a Match, which I accept.
QWin Premier subscription-1 -
Yes, that would be one of the "right ways" to do it. The wrong way would be to delete the downloaded transaction, since that would leave your manually entered transaction without being matched to the downloaded one.
I believe in my case; I just accepted the Near Match. One of the things that always hit me about this that I found it hard to even see what was different.
My general policy is not to manually enter transactions in the first place, but every once in a while I have done it because I wanted to see the affect of the buy/sell and the financial institution wouldn't download it until it cleared. Near Matches are a double problem if you use automatic transaction entry mode since they show up in the hidden Downloaded Transactions tab, and one has to know to turn it back on to see this Near Match (this bug might have been fixed recently, but I'm not sure). But in the case of Chase, it is almost real time, so I don't do that anymore. It isn't "real time" because of the Quicken server refusing to do an update without waiting several hours past the last time One Step Update is run.
Signature:
This is my website: http://www.quicknperlwiz.com/1 -
It sounds like the mark as matched to a downloaded transaction that occurs with Web Connect downloads is not recognized by the matching from Direct Connect. If so, after enough time passes to be out of the possible match range, the Near Match issue should stop.
Quicken user since Q1999. Currently using QW2017.
Questions? Check out the Quicken Windows FAQ list1 -
So "has been matched to a downloaded transaction" is hidden and different from "is Cleared"? That sounds like a problem.
I don’t see that as a flaw. Yes, ‘has been matched …’ is hidden in investment accounts (IIRC) but is effectively visible for banking accounts with the posted date column.
In my view, the Clr status is wholly independent. The user is in complete control of that status via manual entries, partial reconciliations, or full reconciliations. User can do a full reconciliation getting the status to R and then do a download. The downloaded transactions should match or not match independent of Clr status.
I do think the investment accounts should have a visible indicator of being matched or not to a downloaded transaction.
In the OP’s case, it does appear that a downloaded transaction by QFX file is being treated differently than a direct connect download. That should not be the case -FITID error(?). That may be a flaw on Vanguard’s side.
0 -
I agree on this point, if the transactions were imported with Web Connect/QFX that isn't a manually entered transaction and as such these shouldn't have been on the list to match other downloaded transactions, no matter what the connection type is. This part seems like some kind of bug.
I noticed that, but didn't comment on it, I was just talking about how Near Match such work "normally".
Signature:
This is my website: http://www.quicknperlwiz.com/1 -
Here's an example from this morning's download: A new transaction (3/19) was flagged as a Near Match to an existing transaction (3/5). Share count, price, and amount are all vastly different — only the Security name and Action would make it a possible match.
The only pattern I see is that every Near Match (via Direct Connect) is to a transaction downloaded during Vanguard's outage (via Web Connect). Thankfully, some transactions are correctly processed as New.
Per the documentation, I should eventually "roll out" of the date limit used in the matching algorithm (14 days), but there's definitely a flaw.
0 -
As per the documentation, I did eventually "roll out" of the date limit used in the matching algorithm (14 days), but there's definitely a flaw.
1
