RtrnCap Strangeness

Geobrick

After entering a RtrnCap transaction for a stock with a single lot, the basis was wrong at the lot level in the holding overview. The subtotal level is correct, but the lot level (when you click the '+') is wrong. I tried changing the RtrnCap to $100 to help troubleshoot but it didn't help me identify what's going wrong.

Maybe someone on this forum will recognize what's happening.

I'll make the example generic so I'm not throwing a bunch of noise into the discussion, but I may need to add more detail later to help with troubleshooting. Just know the cost basis on the day before the RtrnCap for this single lot was correct through all its history of previous corporate events.

On Jan 3, 2023, 31 shares of XXX has a cost basis of $2,133.20
On Jan 4, 2023 I entered a RtrnCap of $100 with $0 market value (quick adjusts that to $100).
The Holdings Overview shows the following:
Jan 3 - Cost Basis $2,133.20 at both the lot level and the subtotal level.
Jan 4 - Cost Basis shows $2,027.21 at the lot level but has the correct $2,033.20 at the subtotal level.
Just to clarify, there is only the single lot feeding the subtotal and the numbers are different.
What's up with that?

(I'm using Premier for windows version: R53.16)

Geobrick

Just to follow-up: I just set up a test file with a single brokerage and a single stock and can't duplicate the problem.

I'll run a validate and repair to see if that helps.

Geobrick

Thought I fixed the problem by deleting the original buy transaction in 2009 then reentered the exact same thing. Everything matched up until I changed the RtrnCap and the problem came back.

It's tied to a reverse split event prior to entering the return of capital. I may just do a remove/add shares as a way to force the fix.

Still could be related to the damaged block reported when I validated the file but I'm not sure.

Quicken Kristina

Hello @Geobrick,

To assist with this issue, I would recommend looking into that damaged data block first. If the problem is being directly caused by that issue, then resolving one may also resolve the other. Additionally, since troubleshooting data file issues may involved restoring backup files and/or making a copy of a file, it makes sense to wait until you know which file you'll be going forward with before investing a lot of time troubleshooting other issues.

I hope this helps!

Geobrick

I agree is could be related but I'm finding some interesting things about it.

In a backed up version, I copied all the transactions to a new account. The problem followed through to the new account.

I experimented to see how I could affect the reported basis error. With a $100 RtrnCap, the deference in reported cost basis was $5.99. If I doubled the RtrnCap, the difference in the reported basis doubled as well. This indicates the reported difference is in direct proportion to the amount of the RtrnCap.

I suspect the RtrnCap transaction is somehow being messed up by a previous CIL where a fractional share left over from a reverse split was sold. The sale of the fractional share correctly reduces the basis in the lot but months later, after the RtrnCap transaction is when the problem with the reported basis difference comes in. When I remove that past CIL transaction, the RtrnCap works as expected with no difference in the reported basis. I'm going to play with it some more in a separate test file. This may all be because it's a retirement account and maybe Quicken handles this situation differently by design (or possibly in error).

Quicken Kristina

Thank you for the follow up,

Is this happening in a connected account, or is this happening in an account you manually update?

Thank you.

Geobrick

Both. For my main account, the problem happens in a connected account but for the test account I setup in separate file for the purpose of recreating the problem, it's not a connected account.

Geobrick

Quicken Kristina, Do you know where my detailed post went? The one outlining the problem with screenshots?

I tried reposting it but an error says "Body is 1478070 characters too long". That doesn't seem possible.

Geobrick

I'm now confident this cost basis error is a Quicken problem. I was able to consistently repeat the problem using a new Quicken file with a single brokerage account. It seems to only effect the cost basis of the individual lots reported in the Account Holdings Overview screen, but it makes it seem like the numbers aren't adding up properly.

If you want to try recreating the problem, enter these 5 transactions.

1/1/2009 deposit $10,000
2/24/2009 buy 100 shares of XXX for $100/share
8/2/2021 enter a 1 for 8 (reverse) split
8/5/2021 sell the 0.5 fractional share for $500 ($1000/share)
1/4/2023 enter a Return of Capital for $100

Open the Account's Holdings Overview and expand the holding XXX (click the '+' next to XXX). If you don't see the cost basis mismatch error at first, close and reopen Quicken then look at the account holdings overview again. You will see what's in the following screenshots of the Account's Register and Holdings Overview.

The Error. Note the difference between the lot cost basis and the sum of the cost basis.

Here are all the entries for the steps I outlined above shown in the account register.

The remaining screenshots show the account overview after each step.
The account holdings overview after the buy. All good.

The account holdings overview after the 1 for 8 split. All still good.

The account holdings overview after the sale of the fractional share. All still good (0.5 share had a $400 basis).

The account holdings overview after the RtrnCap. (this is when the error shows up).

q_lurker

All I can offer is that your directed sample test case worked correctly in R48.8.

What does the Cap Gains Report show? (Should be Proceeds of $500 off Basis of $400 equals realized gain of $100.)

What does Portfolio Value and Cost Basis Report show? (Only the total for the security will show which obviously should be the $9,500)

If you sell the remaining 12 shares, what does the Cap Gains Report show? (That is, is this only an error in the portfolio view and similar holdings view presentations.)

Geobrick

https://community.quicken.com/discussion/comment/20398851#Comment_20398851

q_lurker, Thanks for testing it. It could very well be that it's just R53.16 since this is the first time I'm seeing something like this. Did you happen to see my post about how the Account Holdings Overview doesn't include commissions and fees in the per/share cost but the total cost basis are correct? Maybe it's a related reporting error.

I know you are typically thorough, but did you try closing and reopening quicken to see if the Account Holdings Overview cost basis changed?

You are correct about the cap gains reports. For 2021 the Sched D report shows $500 proceeds with the $400 Basis. A Capital Gains report covering 2021 shows the same.

The Portfolio Value and Cost Basis Report also shows $9,500 as the basis with a $12,500 balance.

Selling the remaining shares for $1,200/share on 1 OCT 2023 produces this:

As you suspected, it seems to only effect the holdings view at the lot level. I discovered it when I was entering the GEHC spinoff from GE. I was comparing the results with my brokerage's numbers and when they didn't match, I realized it's not me. It was something in Quicken. I created this similar scenario in a clean file to test it. At first all looked good in the clean file but the next time I opened it, I saw the problem in the clean file too.

Quicken Kristina

Thank you for your reply,

I followed the directions you provided, but wasn't able to replicate the issue in my Quicken. I recommend that you contact Quicken Support directly for further assistance as they can walk you through troubleshooting steps in real-time and escalate the situation as needed.  The Quicken Support phone number can be found through this link here. Phone support is available from 5:00 am PT to 5:00 pm PT, Monday through Friday.

I apologize that I could not be of more assistance!

Geobrick

https://community.quicken.com/discussion/comment/20399034#Comment_20399034

Thanks. I have submitted a report under the help menu but I will try calling support too.

Geobrick

Here are a few other interesting observations from running the same scenario in Quicken R48.8 installed on a different computer. My conclusion is this reporting error seems to follow the file to R48.8. Read my results and see if you agree.

Using Quicken R48.8, I opened the .qdf file from initial test under R53.16 and got the same results as above. That didn't not match q_lurker's or Kristina's experience so I deleted all the entries in the register and deleted the security XXX. In the same file and same account, I re-entered all the transactions but changed the security to YYY.
The results were identical to my original results (and this from R48.8).

Next, I added a new brokerage account within the same .qdf file as above. I entered the same transactions but with security ZZZ. Same results.

Next, I created a new Quicken file within R48.8 and added a brokerage account with the same transaction (with XXX as the security).
This worked! Everything is as expected.

That's odd. A file created in 53.16 has a reporting problem and when opened in R48.8, still has the problem even after deleting all the transactions and recreating them in a new account. But when a new .qdf file is created under R48.8, the problem is gone.

I then opened the file created in R48.8, with R53.16. And the result was also good.

For my last experiment, within R53.16, using the same file as above, I entered the same transactions again in the same account for a different security (BBB). This result confuses me. It's good and I was expecting a mismatch. I'm not sure what to make of this result.

Geobrick

I promise. This is my last post on the subject unless I need to answer questions or it gets fixed.

I ran one more test within R53.16 using the .qdf test file I created in R48.8. I added a new brokerage account with the same transactions (security PPP), and the mismatch problem is there (but only for the shares in the new account the other account is still reporting correctly in the holdings view).

markus1957

In one of your test files that displays the mismatch, try running a file validation with the rebuild lots option. Just wondering if that would resolve the mismatch?

Also, you should try the file copy, template option to work around the bad data block. If the file won't copy, you should consider starting a new file.

Geobrick

Thanks Markus. The files I used for these test scenarios, started as new quicken data files. Since it's possible R53 created data corruption in new files, I ran the file validation with the rebuild lots option as you suggested. No errors reported and the mismatch is still there.

I actually fixed my damaged .qdf files a few days ago. In a separate thread, UKR suggested I make a copy of the corrupted files using the 'create a copy or template' method. I was amazed how well it worked. I had to relink all my accounts afterwards but it was easy. Now both my critcle .qdf pass the super validate test with no problems reported.