Bug - Portfolio view - Cost basis by lot
This is an obscure bug involving acquiring shares (Buy or Add) in one or more transactions, one or more subsequent stock splits, selling shares after the stock split without specifying lots, and later having a return of capital transaction. The subsequent error is in a portfolio view cost basis column with the view grouped by account and the individual securities expanded to show the basis of each lot.
The error pops up in the simplest case from transactions as shown below. Note that for the Sold transaction no lot specification is specified relying instead on Quicken's programmed default of first in - first out (FIFO).
The subsequent portfolio view cost basis expanded data shows as:
Note that reported cost basis for the security is $2,400, but the value reported for the lot acquired 1/1/24 is $2,450 = a $50 discrepancy. Further note that sale of any number of shares greater than 100 and less than all will demonstrate this bug in varying amounts (the $50 discrepancy will vary). Different amounts for the RtrnCap transaction will also cause the discrepancy to vary. I have not attempted to reconstruct the internal math. I am not aware of this bug affecting anything beyond the portfolio view presentation.
This bug came to my attention from this real-world case which was much more complex:
In my simple test case, if the Sold transaction specifies that the one and only lot should be used for the sale, the error does not occur. In the referenced case, the specifying the lot for all Solds also got around the bug. But particularly because Quicken defaults to a FIFO sale standard and further because there is only one lot for the sold shares to use, requiring the user to specify lots to avoid this error is unreasonable and inconsistent. That is, for this calculation, Quicken is not following the below message. It is doing something different.
A more complex test sequence generates an even more confusing result:
leads to:
The $1,466.67 is in error (should be $1,440) and the -0( is who knows what (should be $960).
Although this is a very obscure and relatively minor bug, I also believe it may be readily identifiable and correctable since it is so specifically located. Perhaps Eric Dunn can address it himself on one of his Coding Wednesdays.
My final speculation is that the coding error may relate to possible checks made that Return of Capital transactions should not take the basis of any lot below $0.
Substantially, this post is so that I can link to it as I use the Report a problem feature to notify the developers about this error.
Comments
-
For the record, I did Report a Problem with a screenshot and sanitized data file.
0 -
See this discussion for another possibly related issue:
0