Sean Reilly on 05 Jul, 2018 09:15 PM
Can you let me know which build of Moneydance you are using from the "About Moneydance" window? Also, are you seeing the discrepancy in the Capital Gains report, the portfolio panel for the investment account, or on the security detail panel?
I've recently re-implemented the capital gains calculation code that is used in the report, and those changes are in the current preview build at https://infinitekind.com/preview
They still need a bit of work to take into account fees on buys and expense transactions, but I'm in that code now so it'd be great to find out the details of this problem.
Hi. I have seen this behavior on (at least) 2017.7.1, 2017.7.3, and on 2017.8 (1686). Fwiw, I'm running this on MacOS X Sierra (10.2.6).
I see the discrepancy in the Portfolio View and in the Securities Detail panel. When I view a Capital Gains Report (in 2017.8 ), the "Gains" column reports $0.00 for every single transaction, as it should.
Okay, I was able to generate the Cost Basis report for the entire account even though I wasn't able to do it by security. I then saved the report, opened it in an external editor, and moved all of the transactions from the report output into Excel. From there, I confirmed that all transactions match up as they should.
The dollar value is *always* equal to the share number for every transaction. Thus, there should be no way for the cost basis and the total value to have diverged. I have also double-checked the price history. It is *never* different from $1.00/share.
So, based on all of the above, I don't think it's a problem with my data. I would be happy to be proven wrong, but I just can't find anything on my end that would explain this behavior.
Just updating this since the problem persists... I've updated to the latest preview version (v1691) and the problem persists. I have 350 transactions (284 buy, 66 sell) for this security and I have verified every single one of them.
In *every* case, buy or sell, the share # matches the dollar value exactly, as it should for a security with a stable $1 share value. And yet the cost basis is showing as being $0.02 less than the current value. As far as I can tell, this is mathematically impossible and yet it's still happening.
Is it possible that there is a transaction in another account that could be affecting the numbers?
Hi Kevin. No, I haven't messed with the cost basis methods at all. Keep in mind that this is a security with a fixed share value of $1. It is *always* bought an sold for exactly $1/share (it's a money market mutual fund). Since the share value never changes, the two tracking methods are equivalent and it's impossible for them to give different answers. Thanks.
Yes, it's worth exploring, but if it gives different answers in this case then the underlying code is fundamentally flawed and probably can't be trusted... That would be good information to know, but it's not a solution.
Okay, I've played around with the Lot Matching method and have come to a conclusion:
I'm not entirely sure whether or not that will fix it, but if that's the only "solution," then I will stop using Moneydance. There is simply no way that I'm going to spend the time doing lot matching on a money market mutual fund. It a dollar per share. Always. This isn't complicated. The cost basis can *never* diverge from the share balance, and it would be ridiculous to have to track it via lot matching.
The other bit of info that I can offer is that if I do a mass sale of all shares and then re-buy them, the problem goes away. So there must be something funky in one of the transactions, but it's invisible to the user because I have verified that every single transaction (there are hundreds) in this account balances out perfectly. The dollar amount always equals the number of shares, as it should.
This is very frustrating. It would be nice to get some official guidance on the problem...
P.S. As I noted in an earlier message, when I try to do a cost basis report, this particular holding is greyed out for some reason. I don't understand why, and am not sure if it's related. I can do a cost basis report for the entire brokerage account in which this is held, but not for this holding in particular (even though all other holdings in the account show up without being greyed out).
Another followup... I created a copy of my Moneydance file and went through systematically deleting transactions until I found the on that has created this problem with the cost basis mis-matching the balance.
I was able to pin it down to a single transaction in June 2015. This is a large sale in which I sold XXXXXX shares for XXXXXX dollars ($1/share) and everything checks out EXACTLY right. But it causes this mathematically impossible $0.02 deviation in cost basis. I have tried deleting and re-creating the transaction, and the problem remains.
This makes no sense, and has to be due to a flaw in the software because the problem IS NOT with any of the transactions. They all balance out perfectly, and the point at which the problem appears is a perfectly valid (albeit large), dollar-for-dollar transaction. I can thus say with certainty that this isn't due to an error in data entry, but rather with some sort of weird, under-the-hood calculation that messes things up.
Just wanted to confirm that Sean has identified the problem and fixed it in v1695, which is available on the Preview page. It was apparently a floating point error associated with particularly large transactions in one of the views. Cost basis is calc'd at least two different ways depending on where you are in the app, so the problem was affecting one view but not the others.