Totals in "Portfolio Value" report do not foot

dave344

"Portfolio Value" report does not accurately sum the "gain/loss" and "balance" (market value) columns for all of the positions in the one of the accounts.

The attached screenshots illustrate the problem.

Here is additional background:

• The report is generated from the "Portfolio Value" template under the "Investing" section of "Reports and Graphs"
• The report is run directly from the template; it is not one of my saved reports
• The only customizations to the report are the date and subtotal by account
• Only the "gain/loss" and "balance" column totals are incorrect
• Only one account of several in the report appears to be affected
• I have not encountered the issue with this report previously
• After encountering the issue, I performed a super validation (w/o price history correction), closed Quicken, rebooted the computer then relaunched Quicken and ran the report again. The problem persists.
• The account data is correctly reported in the "Holdings" section of the account register; this information agrees to the brokerage statement.
• Quicken Classic PREMIER; Version R63.21; Build 27.1.63.21; Windows 11 Enterprise

I do not believe this is a "data corruption" problem. The data reported for the individual positions is correct. This appears to be a data aggregation problem within the report. The report has the correct data, it's just not summing it properly.

How can I resolve this issue?

dave344

Here is the report for a different year. Same account but this time, no open positions, cash only. The report is not aggregating the data properly.

Jim_Harman

Thanks for your detailed description of the problem.

Since the steps you have tried do not fix the problem, I would start by backing up your data file in case something goes wrong.

Then set the ending date of the report and the As of date in the Portfolio view back in time, comparing the Market Value in the Holdings view to the Balance in the Portfolio Value report.

Go back in time until they agree, then forward until they first disagree. Look for an unusual transaction on that date - it might be a Placeholder, a Split, a Spinoff, etc. - and correct or if necessary delete and re-enter the transaction.

When the balances agree, back up again and continue going forward in time looking for transaction(s) that cause the report and the Holdings view to disagree.

Please let us know what you find.

CaliQkn

@dave344 just a wild thought. Have you tried doing a data file validate with the "Rebuild investing lots" selected? You didn't indicate that you tried this in your list of troubleshooting steps you have taken.

dave344

https://community.quicken.com/discussion/comment/20497240#Comment_20497240

Excellent approach Jim! Thank you so much.

You were correct, it was an offending transaction that prevented the report from summing the totals for that account correctly. Interestingly, the total for the report, which included the transactions for the account with the bad subtotal, was correct.

The offending transactions had to do with short sales that were opened and closed on the same day (a day trade). In this case there were two covered calls. These were initiated with a short sale (ShtSell) and then closed with a buy (CvrShrt). This is the reverse order of a "normal" (long) transaction.

A problem arises because there is no time stamp on the trade date. So when the broker feed comes into Quicken, the transactions can be mis-ordered (i.e., the CvrShrt precedes the ShtSell in the register). This is not a problem for accepting the transactions into the account register. However, it is a big problem for reconciliation. When you try to reconcile a short trade that was closed on the same day it was opened, and the CvrShrt precedes the ShtSell in the register, you will get an error, something to the effect of "Cover with no associated short. Converting to a buy transaction." This is because Quicken does not look forward in the register to find a ShtSell that occurred on the same day as the CvrShrt; apparently it only looks backward to find a match. Not finding one, Quicken wants to convert the CvrShrt into a Buy, which will leave you with two open transactions, the ShtSell and the Buy, when both should be closed. The work around is to go into the register and change the trade date on the ShtSell transaction to the proceeding day. This way the proper order (sequence) is maintained in the register and Quicken will be able to reconcile the transactions.

However, given the problem with the "Portfolio View" report, it apparently is not sufficient to merely change the date on the ShtSell transaction. Doing so is what I believe created the problem with summing the account data. Instead, I needed to delete both the CvrShrt and ShtSell transactions and then recreate them, making sure the ShtSell preceded the CvrShrt. I did this by creating the ShtSell with a trade date on the day before the trade date of the CvrShrt. I think I might have been able to achieve the same result, and maintain the same trade date for both transactions, by simply creating the ShtSell transaction first so that it proceeded the CvrShrt in the register. However, I did not try this option.

The bottom line is that I think there are two problems here: 1) how Quicken reconciles short day trades; and 2) why simply changing the date on a transaction in the register is ineffective and a full delete and re-enter is required. Anyway, the immediate problem is solved. Thank you. We'll have to wait to see if Quicken pursues the other issues.

Jim_Harman

It's good to hear that you were able to resolve the problem.

If you review your downloaded transactions carefully and accept them in the correct order, that should also avoid the CvrShrt before ShtSell issue.