[moneydance] Matching downloaded transactions

[Katahdin]

Uday,

Instead of focusing on the d/l matching issue, I wish you'd use your
expertise on the issue re: locking down MD to follow standard accounting
practices,  and  giving a couple  the  ability to easily report their income
expense separately from the other. Or any other identity that wants to use a
single app to report overall financial status, but have the option to
selective report on individual account activity.  Hope thais makes some
sense..


On Sun, Apr 6, 2008 at 7:48 PM, Uday Reddy <u.s.reddy at cs.bham.ac.uk> wrote:

> 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
>
> _______________________________________________
> moneydance-info mailing list
> moneydance-info at moneydance.com
> http://moneydance.com/mailman/listinfo/moneydance-info
>




PoBox 446
Patten, Me 04765