cost basis not matching up?

exigent's Avatar


05 Jul, 2018 03:49 PM

Hey all, this has been driving me crazy. I have a money market mutual fund in one account that has always traded at a stable $1/share value. Thus, the cost basis of this holding should exactly match the current value, but it doesn't... It's off by $0.02 and I can't find the discrepancy anywhere.

The main thing that I've done to troubleshoot this has been to open up the Securities Detail page and scroll through the entire list of transactions. I was hoping to find a typo where I'd entered an amount that doesn't equal the number of shares transacted. No luck... In every case, the number of shares and the amount match each other perfectly, as they should since it's *always* $1/share.

I also went into the Register and searched for the security name and checked every single transaction. As above, the numebr of shares transacted *always* matched the dollar value of the transaction, so it seems that the cost basis and value should match up perfectly. And yet they don't... The cost basis is $0.02 low...

So now I'm stuck hunting for a $0.02 discrepancy *somewhere* in this account's history, but I really don't know where else to look. This is driving me nuts, so I was hoping that someone might have a suggestion.


  1. Support Staff 1 Posted by Sean Reilly on 05 Jul, 2018 09:15 PM

    Sean Reilly's Avatar


    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

    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.


    Sean Reilly
    Developer, The Infinite Kind

  2. 2 Posted by exigent on 05 Jul, 2018 10:03 PM

    exigent's Avatar

    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 [1686]), the "Gains" column reports $0.00 for every single transaction, as it should.

  3. 3 Posted by exigent on 05 Jul, 2018 10:10 PM

    exigent's Avatar

    Not sure if this is relevant, but when I attempt to generate a "Cost Basis" report using the "By Security" option, this security is in the list but greyed out so I can't select it. Not sure why.

  4. 4 Posted by exigent on 05 Jul, 2018 10:19 PM

    exigent's Avatar

    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.

    Thanks again for following up on this.

  5. 5 Posted by exigent on 03 Aug, 2018 03:37 PM

    exigent's Avatar

    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?

  6. 6 Posted by -Kevin N. on 03 Aug, 2018 03:50 PM

    -Kevin N.'s Avatar

    Hi exigent,

    Just tossing this out there...

    If you haven't done so already, have you tried using Lot Matching for the Cost Basis?

    I've seen Lot Matching vs. Avg. Cost provide some contrasting results in the Capital Gains report.

    I'm not sure that Lot Matching would play any part in the discrepancy that you are seeing but like I said, just tossing it out there.

    -Kevin N. (not a member of MD support)

  7. 7 Posted by exigent on 03 Aug, 2018 04:35 PM

    exigent's Avatar

    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.

  8. 8 Posted by -Kevin N. on 03 Aug, 2018 04:40 PM

    -Kevin N.'s Avatar

    Hi exigent,'s impossible for them to give different answers.

    And yet, in the Cap Gains report, one can get different answers dependent on the choice of Avg. Cost vs. Lot Matching.

    Might be worth a try.

    -Kevin N. (not a member of MD support)

  9. 9 Posted by exigent on 03 Aug, 2018 05:23 PM

    exigent's Avatar

    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.

  10. 10 Posted by exigent on 07 Aug, 2018 01:42 PM

    exigent's Avatar

    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).

  11. 11 Posted by exigent on 22 Aug, 2018 07:06 PM

    exigent's Avatar

    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.

    So what's going on?

  12. Support Staff 12 Posted by Sean Reilly on 22 Aug, 2018 07:17 PM

    Sean Reilly's Avatar

    Hi there,

    Sorry again for not following through with this yet. Would your data file be stripped down enough for me to get a copy of it to run in the debugger to see where the calculation is going wrong?


    Sean Reilly
    Developer, The Infinite Kind

  13. 13 Posted by exigent on 28 Aug, 2018 01:55 PM

    exigent's Avatar

    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.

  14. System closed this discussion on 27 Nov, 2018 02:00 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac