Quicken's algorithm for detecting "Matches" vs. "New" transactions needs work
in [Quicken]
|
Prev: Only one User ID and Password allowed per FI for OSU in Quicken?
Next: Quicken's algorithm for detecting "Matches" vs. "New" transactions needs work
From: Bob Wang on 7 Aug 2010 18:28 Quicken matches my manually entered transactions almost flawlessly. I can't remember the last time a transaction was mismatched.
From: XS11E on 7 Aug 2010 18:32 "Bob Wang" <BobWangBlog(a)Gmail.com> wrote: > Quicken matches my manually entered transactions almost flawlessly. > I can't remember the last time a transaction was mismatched. I can, it was today. Only one today, several hundreds in the past. -- XS11E, Killing all posts from Google Groups The Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
From: TomYoung on 7 Aug 2010 19:20 On Aug 7, 3:28 pm, "Bob Wang" <BobWangB...(a)Gmail.com> wrote: > Quicken matches my manually entered transactions almost flawlessly. > I can't remember the last time a transaction was mismatched. Looking more closely at the transaction I *thought* Quicken was matching to - the 8/1/2009 transaction - vs. the transaction Quicken actually was matching to - the 8/1/2010 transaction - I noticed that the 8/1/2009 transaction had an "R" in the Clr column while the 8/1/2010 transaction had a "c" there. (I log onto my account manually and change each check's status as it clears the bank.) Obviously the Quicken program gives much more "weight" to a "c" in the Clr column vs. an "R", even though it can actually result in a bigger miss when it comes to declaring a Match. Probably a blank in the Clr column carries even more weight. That would explain XS11E's comment about several hundred mis-matches in the past; once you get past the initial download with all its misses subsequent downloads would have a better chance of getting properly matched as the program probably zeros in on the blank and "c" transactions. You would think the match algorithm would give highest weight to date, payee and amount and maybe use the Clr column as some sort of tie breaker (you issue two checks on the same day in the same amount to one payee and one check clears before the other) but it doesn't appear to work that way. Tom Young
From: John Pollard on 7 Aug 2010 21:20 TomYoung wrote: > On Aug 7, 3:28 pm, "Bob Wang" <BobWangB...(a)Gmail.com> wrote: >> Quicken matches my manually entered transactions almost flawlessly. >> I can't remember the last time a transaction was mismatched. > > Looking more closely at the transaction I *thought* Quicken was > matching to - the 8/1/2009 transaction - vs. the transaction Quicken > actually was matching to - the 8/1/2010 transaction - I noticed that > the 8/1/2009 transaction had an "R" in the Clr column while the > 8/1/2010 transaction had a "c" there. (I log onto my account manually > and change each check's status as it clears the bank.) Obviously the > Quicken program gives much more "weight" to a "c" in the Clr column > vs. an "R", even though it can actually result in a bigger miss when > it comes to declaring a Match. Probably a blank in the Clr column > carries even more weight. That would explain XS11E's comment about > several hundred mis-matches in the past; once you get past the initial > download with all its misses subsequent downloads would have a better > chance of getting properly matched as the program probably zeros in on > the blank and "c" transactions. > > You would think the match algorithm would give highest weight to date, > payee and amount and maybe use the Clr column as some sort of tie > breaker (you issue two checks on the same day in the same amount to > one payee and one check clears before the other) but it doesn't appear > to work that way. [Talking about non-investment accounts.] No it doesn't work that way. And the fact that you think the cleared status should play a part in the process shows that you don't understand what the "match" process is all about. First: The match process is *only* about matching downloaded transactions with transactions that have not been downloaded**. Cleared status is not a valid indicator of whether a transaction has been downloaded. Cleared status can be set without regard to whether a transaction has ever been downloaded. Second: the downloaded date is NOT a "transaction" date; it is a "cleared" date. But the date of a manually entered transaction in your Quicken register - especially for check transactions - is the transaction date ... the date you wrote the check. Checks written two weeks ago can easily clear before checks written 2 days ago. Comparing "cleared date" to "transaction date" is an unreliable comparison. Your date comparison theory fails miserably. Third: in many cases, the user can prevent Quicken from matching to an incorrect transaction, by "telling" Quicken that the existing transaction has been downloaded before ... even though it may not have been. You can do this by right-clicking the register transaction, then holding down CTRL while left-clicking "Copy transaction(s)". Then putting a check mark in "Downloaded Transaction" and selecting a "Posting Date". Doing that should exclude that transaction from ever being a candidate for matching*. Fourth: Actually, I believe the match process does give weight to the "date". But, you don't seem to understand that downloaded transactions can represent transactions whose Quicken "transaction date" was well in the past (see #2). And there can have been, and often are, many other transactions for the same payee, which also have not been downloaded before ... the fact that they have newer "dates" doesn't insure that they are the "right" transaction to match to (generally speaking; it's better to have older transactions legitimately cleared, than newer transactions). I do believe that Intuit might be able to tweak the matching process and improve it *very* slightly (at some questionable cost) ... but it will never be able to be what you seem to expect it to be. Can you provide evidence that some other product has done a measurably better job? Remembering that the product must produce results that provide equal benefits to other customers besides yourself? [** If a transaction marked as already downloaded, is treated as a match candidate ... I suspect it is a file corruption problem. It has never happened to me; and I've never read any proof that this happened to anyone else ... where corruption could not be the problem.] -- John Pollard news://<YOUR-NNTP-NEWSERVER-HERE>/alt.comp.software.financial.quicken Your source of user-to-user Quicken help
From: TomYoung on 8 Aug 2010 10:42
On Aug 8, 6:28 am, "John Pollard" <8plus7...(a)gmail.com> wrote: > TomYoung wrote: > > However, going back to my monthly Blue Shield payment; every month I > > schedule that EFT to go out on the 1st of the month; the payment has > > been exactly the same for all that time; if the 1st isn't a business > > day the payment gets made on the next business day following. > > Any > > human being looking at the downloaded information would have very > > confidently lined up the Blue Shield payments with the correct > > register dates, resulting in 24 or 25 proposed "matches." As it was, > > Quicken gave me one "match" that didn't make a lick of sense and 23 or > > 24 "new" transactions that it wanted me to match manually. > > A human being can look at another human being whose face they've seen > before and easily recognize the face ... writing software to do facial > recognition is not a trivial exercise. C'mon John, you're going to hurt yourself straining that hard for an analogy, trying to shoot down my argument. Writing facial recognition software vs. writing software for check matching? At the very least you'd have to admit that matching a payment that cleared the bank in August 2008 with a payment issued in August 2010 is a little silly and isn't a fantastically difficult programming problem to solve. Wouldn't you? > I'm saying that if you make a claim - such as that it is economically > feasible to provide a significantly better matching algorithm - you need > to provide verifiable evidence of that claim. Pointing to some other > product that does a better job would be one way to demonstrate your point.. OK, I've got it now. Before I suggest Quicken can improve in any way - in ANY way - I have to find a better product in the market, one selling at the same price point, that's doing what I want Quicken to do. A high bar, indeed. Tom Young |