nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Return of Capital transaction has SERIOUS problem

GA Hiker

In Quicken Premier for Windows, I entered a ROC transaction of about $96 for a mutual fund after receiving my 1099 for 2022. I understand that this should not affect the number of shares held (about 12,550) and should reduce the cost basis of each lot by a proportionate amount, all reductions totaling to the $96. Here's how it went for my earliest 6 lots (numbers rounded for simplicity):

Shares / Cost before ROC / Cost after ROC
144 / $2,460 / $ 1,406 / DOWN > $1000
145 / $2,460 / $-1,738 / NEGATIVE!
166 / $2,459 / $ 82 / NO WORDS
146 / $2,459 / $ 4,209 / UP > $1700
147 / $2,459 / $ 2,458
22 / $ 355 / $ 358 / UP, NOT DOWN

Yes, the change in total cost for the fund was about $96.

The last time I did this was in 2019 for 2018 and all went well. Please help!

Find more posts tagged with

Investments

Comments

q_lurker

Odd. Here's what my test did for a $96 RtrnCap on those 6 lots.

Image: https://us.v-cdn.net/6031128/uploads/editor/p9/fy0cv2r5xi6q.jpg

The day before the RtrnCap, the cost basis for each lot was as shown in your message. As you can see each lot's basis was reduced by

$96 / 770 shares x lot shares = $2.74 for 22 share lot to $20.70 for the 166 share lot.

I would:

BACKUP the file
Delete the RtrnCap you entered.
Make sure there are no placeholders for the security (make sure your preferences are to show hidden transactions)
Validate the file include rebuilding the lots
Exit and restart Quicken. (just in case)
Re-enter the RtrnCap transaction.

Are you by any chance synching your data to the web or mobile app? If so, undo that option.

Hope this leads you somewhere positive.

GA Hiker

Thank you for your response. I followed your directions. (I never had any placeholders and already was set to show hidden transactions, but I checked both.) I have never synched my data to the web or mobile app. The validation notes did not mention anything in the affected account or security. (Of the handful of transactions mentioned, the most recent is from 2004.) Then re-entered RtnCap transaction gave me exactly the same (bad) results as previously. What next?

q_lurker

What release number of Quicken Premier are you using?

Tell me more about this security, how you have built up the shares held, buys, adds, splits. Other prior RtrnCaps? (Noted 2019 reference).

My understanding: The day before this RtrnCap your Holding (or portfolio) view is similar to what I snipped with the values you cited. The day of the RtrnCap, cost basis changes to values as you noted above.

If you enter a RtrnCap for a simpler multi-lot security, does it calculate correctly? That is, is the issue this security (a data issue) or all securities (a program issue).

If you enter a RtrnCap back when you had one or two lots, does it calculate correctly? Can you then establish when things go off the rails.

markus1957

I'm guessing Quicken has an underlying calculation issue allocating a ROC amounting to a fraction of a penny per share ($96/12,550 shares or $0.00764940 per share) across a dozen or more lots.

@q_lurker I wonder if you prorated the ROC transaction amount to 770/12,550 shares * $96 or $5.89 if it would do as well across those 6 lots.

q_lurker

That hypothesis would not begin to explain some increasing and some decreasing by $1000s. But I did it with a 3.85 RtrnCap (0.005/share) to make the math easier. Now a couple were off by a penny, but fundamentally right where they should be. I don't see a less even fractional penny altering that process.

Appreciate the help and thought. This could be a real bear to wrestle with.

GA Hiker

"What release number of Quicken Premier are you using?"

Version R47.15 Build 27.1.47.15

"Tell me more about this security, how you have built up the shares held, buys, adds, splits. Other prior RtrnCaps? (Noted 2019 reference)."

This mutual fund was originally held in a joint account, first 5 lots were purchased with cash, then distributions reinvested. In 2004, half of each lot was transferred to my individual account, all distributions reinvested since then. Over time, several lots were sold, there were 2 ROCs in 2016, 4 in 2017.

"My understanding: The day before this RtrnCap your Holding (or portfolio) view is similar to what I snipped with the values you cited. The day of the RtrnCap, cost basis changes to values as you noted above."

Correct

"If you enter a RtrnCap for a simpler multi-lot security, does it calculate correctly? That is, is the issue this security (a data issue) or all securities (a program issue)."

I will report this in my next comment.

"If you enter a RtrnCap back when you had one or two lots, does it calculate correctly? Can you then establish when things go off the rails."

Haven't tried this yet.

image.png

GA Hiker

As q_lurker suggested, I entered a ROC for a "a simpler multi-lot security" and it worked perfectly. It was an $85 ROC on about 12,600 shares in 15 lots. The fund had a large initial investment, distributions were reinvested, and there was one sale prior to the date of the ROC.

I snipped a before and after but was unsuccessful in pasting it into this comment. For future use, can you tell me how to do that?

Tomorrow I will try entering ROCs for the original fund earlier in its history.

GA Hiker

OOPS! I had already posted this message (before my previous one) but it has somehow disappeared.

"What release number of Quicken Premier are you using? "

Version R47.15 Build 27.1.47.15

"Tell me more about this security, how you have built up the shares held, buys, adds, splits. Other prior RtrnCaps? (Noted 2019 reference)."

This fund originally was held in a joint account. There were 5 initial cash purchases, then all distributions reinvested. In 2004, half of each lot was transferred to my individual account, then all distributions reinvested. A few lots have been sold, 2 ROCs in 2016, and 4 in 2018 (entered in 2019).

"My understanding: The day before this RtrnCap your Holding (or portfolio) view is similar to what I snipped with the values you cited. The day of the RtrnCap, cost basis changes to values as you noted above. "

Correct.

"If you enter a RtrnCap for a simpler multi-lot security, does it calculate correctly? That is, is the issue this security (a data issue) or all securities (a program issue). "

See previous message.

"If you enter a RtrnCap back when you had one or two lots, does it calculate correctly? Can you then establish when things go off the rails."

Will try this tomorrow.

Tom Young

Multiple ROCs for the same security seemed to be a constant source of errors for quite a long time with Quicken, though I haven't seen complaints along these lines for the last few years. As a pure guess I'd say that all those ROCs have made the data for the security go bad in some way, shape or form.
Grasping at straws here... When you made your 4 ROC entries in 2019, did you go back and make them as 2018 entries with the appropriate date? Two and then four ROCs in one year seems like a lot of ROCa. What's the name of the security and why 2 and 4 ROCs? I know that some securities do publish ROC information with each distribution and maybe that's what's in play here? Perhaps try only one year end ROC for the same amount at year end?

GA Hiker

I don't find out about the ROCs until I get the 1099 after year-end. I enter them as of the appropriate date and they are to reduce cost only on shares owned prior to that date. For 2022 the 4 ROCs are for dates 3/21, 6/21, 9/19, and 12/20, the same dates as dividends were distributed (and reinvested). When I was about to make the ROC entries for 2018 (in 2019), I read in this community that if I entered the dividends and the ROC on the same date, the ROC would include the shares acquired via reinvestment that day (perhaps it would depend on which transaction I entered first). Therefore, I enter the ROC for the day before the dividend. Waiting until year-end would not give a correct result. For 2022 I have only tried entering one ROC so far with the discussed disastrous results.

markus1957

You might run an Investment Transactions report customized for Include All Dates and limited to the mutual fund in question to confirm there are no odd entries or calculations. You could also verify by looking at the Portfolio tab, Value view for some earlier dates before and after previous ROC entries and verify the cost basis calculated for each lot is correct for those dates.

If that all looks good, you may have run into some internal variables limit to the ROC calculation where it cannot handle the number of lots and ROC entries.

I use ROCs for amortizing bond premiums. I looked my file over but could not find a bad calculation I could blame Quicken for. Then again, I don't have the number of ROCs with multiple lots to make any kind of comparative test. You could create a test account and security in your file like @q_lurker did that matches the structure you see in the investment transactions report and find out when/if and under what conditions the ROC cost basis calculation breaks down.

q_lurker

I've used multiple RtrnCaps for bond amortization as well with no problems -- but those also are single lot holdings.

This fund originally was held in a joint account. There were 5 initial cash purchases, then all distributions reinvested. In 2004, half of each lot was transferred to my individual account, then all distributions reinvested. A few lots have been sold, 2 ROCs in 2016, and 4 in 2018 (entered in 2019).

Initial thought is that is a rather complex history. But then not really. How did you manage the "half of each lot" transfer? I would expect to see a series of Add Shares each for the proper number of shares, the correct acquisition date, and the correct cost basis. That then makes it a pretty simple history, complex only in that you might have 80+ reinvestment transactions, maybe a total of 100+ transactions. But it would have been a similarly large number in 2019 when it worked correctly.

The other caution flag I see is that some of the lots were sold. Entire or partial lot sold?

So I am hypothesizing that one or several of those transactions got dinged somewhere along the way in the last 4-5 years. I'd first be looking at the larger share initial purchase Adds and the Sales. Possibly delete and re-enter those which might also require re-dos of the prior RtrnCaps. So approach that cautiously

I snipped a before and after but was unsuccessful in pasting it into this comment. For future use, can you tell me how to do that?

You should be able to drag the file into the text box area and it will transfer as an attachment. If you have enough participation points in this community, there are Attachment icons and a formatting tool bar made available.

GA Hiker

markus1957 I ran the Investment Transactions report and see nothing unexpected. I've compared Cost Basis values in the Portfolio tab, Value view with my broker's statement showing cost basis per lot and, while they are not precisely the same, they are close enough to know that the previous ROC entries worked okay.

I have more than 100 lots in this security. I would hate to spend the time entering all the history into a test account only to find that it didn't fail there. After all, ROC worked in 2018. Since then, I've sold one block of shares and reinvested dividend and capital gain distributions.

If I have in fact "run into some internal variables limit," like a table with a maximum size, I find it not acceptable for Quicken to generate absurd results instead of displaying a message such as, "Sorry, we cannot process a ROC transaction for a security with more than xxx lots." I have been a Quicken user for an enormous number of years and I've held some securities for a very long time. I use Quicken to make trading decisions such as, most recently, tax loss sales. I regularly review the gains/losses for my securities.

Am I really supposed to accept that I can not enter ROC transactions for this security? If it is an internal variables limit, is it possible that Quicken will fix that problem if it's reported to them?

GA Hiker

q_lurker Per your suggestion, I entered a ROC transaction with a date between my 2nd and 3rd lots, in 1996. Nothing happened! No change in costs at all.

GA Hiker

> @q_lurker said:

> But then not really. How did you manage the "half of each lot" transfer? I would expect to see a series of Add Shares each for the proper number of shares, the correct acquisition date, and the correct cost basis. That then makes it a pretty simple history, complex only in that you might have 80+ reinvestment transactions, maybe a total of 100+ transactions. But it would have been a similarly large number in 2019 when it worked correctly.
>

I don't really remember how I did the transfer of half of each lot but yes, there is a series of "Added" transactions. Currently, there are more than 100 lots.

>
> The other caution flag I see is that some of the lots were sold. Entire or partial lot sold?
>

I made one sale, after the last ROC, of several lots and one partial lot.

> So I am hypothesizing that one or several of those transactions got dinged somewhere along the way in the last 4-5 years. I'd first be looking at the larger share initial purchase Adds and the Sales. Possibly delete and re-enter those which might also require re-dos of the prior RtrnCaps. So approach that cautiously
>

That is SCARY! How does a transaction get "dinged"? Program bug?

markus1957

GA Hiker said:

q_lurker Per your suggestion, I entered a ROC transaction with a date between my 2nd and 3rd lots, in 1996. Nothing happened! No change in costs at all.

Not unexpected that Quicken would choke on a new ROC with a date prior to existing ROCs. There should be a warning but I doubt the programming is good enough to deal with that nasty calculation curveball. I'm assuming you deleted that ROC and you are back to the initial condition.

Grasping for ways to find the breaking point. What if you delete the recent problem ROC. Verify the first 6 lots are good. Then incrementally edit the most recent good ROC date closer to the present to see if your first 6 lots ever blow up. If they do, that may identify a corrupted transaction. If the date edits do not blow up the first 6, put the ROC back to the right date and enter a fictitious ROC shortly after the last working ROC and before a subsequent sell or buy to see if it computes correctly? If so, keep editing that ROC date closer to the present to see when it blows up. Again, looking for a transaction to blame.

If you find a transaction to blame, I'd delete it and reenter it with a date one-day later than the original date to make sure it makes its own new record and doesn't try rewriting a potentially corrupted one. If it corrects the issue, then you can correct the date. (I suggest this because I also have an old file and can recall this happening a time or two)

You could try to delete all of the ROCs as it doesn't seem like you have that many. Reenter them with dates 2 days before the div reinvestment to avoid the re-write versus new record potential problem. Reenter in the order from the oldest to most recent.

A point of clarification that may not be relevant regarding the reinvestment of the ROC proceeds. Originally they were downloaded as reinvested dividends or was it a Div and a Buy? The divs that were recharacterized should be entered as Div, ROC, Buy to keep price history correct, not a reinvested div transaction?

GA Hiker

markus1957 Yes, I immediately delete all bad ROC attempts. I appreciate the methodology you suggest for possibly finding a corrupt transaction or a date beyond which ROC attempts go bad. I may not have the time to do this for a couple of days.

Re your last paragraph: Distributions were originally entered as ReinvDiv (not knowing that they were partially ROC). After the end of the year, when I learned about the ROCs from my 1099-Div, I entered a RtrnCap and a matching Div, the Div having a negative amount equal to the ROC. Anything you see wrong with that?

Thank you so much.

GA Hiker

Tom Young The security is American Funds Capital World Bond Fund, CWBFX. I think I explained earlier why year-end entry of multiple ROC won't give correct results.

q_lurker

@“GA Hiker”.

Another exploratory exercise I might try:
With the bad RtrnCap not in play, sell all shares of the fund. Then see if anything odd appears in a Capital Gains report. Does the shares and cost basis of each lot appear correct? That might point to something problematic to start with.

If that looked ok, I might repeat with the bad RtrnCap in place. Might that subsequent CG report also look ok even some other view shows wacky cost basis?

markus1957

GA Hiker said:

Re your last paragraph: Distributions were originally entered as ReinvDiv (not knowing that they were partially ROC). After the end of the year, when I learned about the ROCs from my 1099-Div, I entered a RtrnCap and a matching Div, the Div having a negative amount equal to the ROC. Anything you see wrong with that?

Thank you so much.

For clarification the ReinvDiv transaction was deleted (or edited to a Buy). A RtrnCap transaction (dated one day prior to div) and a Div transaction (original date), the sum of which matched the original ReinvDiv amount were entered. Then a Buy was entered (or the ReinvDiv edited as mentioned) with a cost equal to the original ReinvDiv amount and shares (original date). The ROCs were all entered in order of the oldest to most recent transactions. I think order of entry is important as you have demonstrated when you tried to insert a new ROC between two existing ROCs.

If you do decide to delete and reenter all of the ROCs, I would not worry about any negative cash balance that might be generated by deleting the ROCs. Quicken can still do simple addition and subtraction; it's a bust in complex algebra or a corrupted transaction we're trying to identify. In fact, if the cash balance does not go negative to an amount equal to the sum of the deleted ROCs, then there has to be a corrupt transaction causing this mess.

GA Hiker

WHEW!!!! It has been a long and difficult battle but I have won! I couldn’t have done it without you guys. Thank you!

I will summarize.

I determined that RtnCaps worked up until the only Sold transaction in this fund, which occurred shortly after the last previous successful RtnCap, and did not work after that. That sale had 26 specified lots, including one partial lot.

I wondered: Will just any sale “poison” future RtnCaps? Or only sales with specific lots, or only if they include a sale of a partial lot? Or none of the above and my sale is just corrupt, whatever that means?

I entered a simplified version of my sale – 3 lots including one partial – followed by a RtnCap that worked!

I had no choice – I had to delete and reenter my sale, all 26 lots, each with 5-6 digit shares (3 decimals). Ugh. After that, RtnCaps worked! I entered the 4 RtnCaps for 2022. For each I entered the RtnCap the day before the original dividend, followed the next day by the Div and a Buy for the combined amount. The total shares and cost basis now match my 1/31/23 broker statement (earliest statement to reflect RtnCaps) about as closely as they matched before this nightmare.

I learned a lot from this, about Quicken and how to drill down to find the problem. I am impressed that Quicken allows me to delete complicated transactions, that affect many lots, and it is as if they had never been there.

Questions: How do transactions become corrupt? A bad spot on my hard drive? An unexplainable Quicken burp? Did the sale I entered today work better with a Quicken version that is 5 years newer?

I am grateful to have this Community.

q_lurker

Questions: How do transactions become corrupt? A bad spot on my hard drive? An unexplainable Quicken burp? Did the sale I entered today work better with a Quicken version that is 5 years newer?

No definitive answer. Just my opinions.
Bad spot on the drive? Perhaps possible, but unlikely.
Burp? More likely, but just what is a Quicken burp?
Better now? Sure. Maybe. Maybe not. It is similarly possible that some program upgrade over the last 5 years misread a complicated transaction and then miswrote it to the newer file.
Or an intentional change like how many digits the program carries had an unintended consequence.
Again, just my not-very-knowledgeable opinions.

GA Hiker

@q_lurker Thank you. It's been a nightmare. I've spent 2 whole days...
.

Jim_Harman

I haven't had this particular problem, but a few times a transaction, usually a partial sale, has messed up the data for the remaining tax lots.

The technique that you used to find the problem also worked for met: narrow down the accounts and securities to find the one(s) affected and then adjust the eding date for a report or the As of date for a Portfolio view to find the problem transaction(s). Once a bad transaction has been located, deleting and re-entering it often fixes the problem.

GA Hiker

@Jim_Harman Interesting that a transaction with a partial sale was an issue for you too. If deleting and reentering had not worked, I was thinking of dividing the acquisition transaction for the lot into 2 parts so I could sell one of the lots whole.