[moneydance] Matching downloaded transactions

[Uday Reddy]

I am one of the people that would like to switch from Quicken to 
Moneydance, but haven't yet done so because I am not yet confident that 
the payoff is there.

One of the key problems is the matching of downloaded transactions. 
Moneydance uses a different algorithm to match the transactions from 
Quicken, and it appears to me that Moneydance's algorithm requires 
considerably more time for manual matching than Quicken does.  Marcelo 
LeFleur raised the issue in 2005 and Sean Reilly explained how 
Moneydance does its matching:

"Moneydance currently matches downloaded transactions based on a 
combination of factors:
  1) Amount (most heavily weighted)
  2) Date (within a certain range)
  3) Check number (if there is a check number, it should match exactly)
  4) Payee/Memo fields (fuzzy match)

The amount is the best way for Moneydance to match downloaded 
transactions with those that are already in the register.... Existing 
transactions that are outside of a certain date range will not be 
proposed as possible matches.  Also, transactions that have already been 
matched with a downloaded transaction will not be proposed as a possible 
match."

Marcelo objected saying that giving the highest weighting to the amount 
field gives undesirable results, but other users disagreed.  No 
resolution was reached.

I would like to reopen the discussion by adding some more detail and 
proposing some alternatives.

1. At the moment (build 605), the last sentence of Sean Reilly's reply 
is not true.  Moneydance is indeed matching transactions that have 
already been matched (either in the current round of previous matching 
as well as those matched in previous rounds).  I hope that this is 
simply a bug, and will be rectified soon.

2. Date range:  The best I can make out is that Moneydance is happy to 
match transactions that have taken place up to 3 months in the past, and 
perhaps less than a month in the future.  In other words, if you have a 
downloaded transaction for 4th April, 2008, it is happy to match any 
transactions in the register between 4th January - 4th April.  Its 
preference for transactions in the future doesn't seem to extend beyond 
4th May, but I haven't checked this carefully.

On the other hand, Quicken seems to match transactions within about a 
week of the downloaded transaction.

At least for me, Quicken's algorithm works a lot better.  It is 
incredibly rare that I have a transaction in my register which is 
farther than a week away from the date of the downloaded transaction. 
On the other hand, there are very often transactions in the previous 
months with the same amounts (loan payments, insurance payments, utility 
bills, parking bills, parking tickets, train tickets, cash withdrawals, 
salary deposits etc.) which are candidate matches, but they are almost 
always the wrong matches.  Moneydance is consistently preferring wrong 
matches, which adds to my workload in rejecting the matches suggested by 
Moneydance and manually entering new transactions.

3. I have never seen a case where Moneydance preferred "new transaction" 
or "repeat payee" to a possible match.  In this respect, Moneydance 
comes across as being naive and overconfident.  It suggests matches that 
are quite clearly wrong in preference to creating new transactions.  (In 
a sense, Moneydance seems to think it has failed in its job if it 
doesn't suggest a match, however wrong it might be, rather than create a 
new transaction.)

In a sense, none of this is a serious problem because all the possible 
matches as well as "no matches" are provided as options, and one can 
select the appropriate option.  However, the fact that Moneydance shows 
wrong and inappropriate matches and even prefers them to "no match" 
options means that the users are having to do unnecessary extra work. 
It is a serious annoyance.

Cheers,
Uday Reddy