Reinvesting a Return on Capital (Dividend)

Mac

Greetings,

I've reviewed many of the questions/answers regarding ROC but did not see anything specific to Reinveting (automatically) an ROC payment.  I have quite a few Equities that automatically reinvest their dividends.  But when one of those payments is a Return on Capital, Quicken (now 2017 Premium running on Windows 7) can't handle the transaction in one-step.  After all these years, Why Not?!?

Although new to this forum, I've been using Quicken since 1994 (DOS) and have never quite figured out how to make this work (if it ever has or can).  Would greatly appreciate finding out how to properly enter an Auto-Reinvested, ROC payment so it adjusts my Cost Basis figures correctly.

Thank you for your time!

Mac

mshiggins

There is no one step transaction type to record a return of capital and a subsequent buy using the returned funds. You could post an idea here on the forum suggesting it be added and see how many votes it gets.

q_lurker

The only way to enter a RtrnCap transaction where the proceeds are reinvested is to use two transactions - a RtrnCap and a Buy Shares.  There is little difference in the end result of that pair as compared to a ReinvDiv or ReinvInt transaction where the two are built into one.  The primary difference feeds of the fact that Quicken computes an Amount Invested parameter and an Amount Reinvested parameter.   

If you are faced with an end-of-year situation where the dividends paid throughout the year are recategorized from Div to RtrnCap, you have the possibility of entering two transactions at year end - 1)  a RtrnCap which would adjust basis down and put cash in the account, and 2) a MiscExp against the _DivInc category that would remove the cash balance and reduce your total dividends for that security for that year.  All your monthly or quarterly ReinvDiv remain as they were.  

But both these sets balk with your other clause to "adjust my Cost Basis figures correctly".  Since 2013 or 2014 (as best I recall), there have been some issues on how Quicken for WIndows processes RtrnCap adjustments.  In some cases, there may be inconsistencies whereby one part may properly manage the RtrnCap data and another view may not.  These issues may have been partly addressed in subsequent years and may be fully corrected in 2017, but I have not confirmed that to any level of confidence.  My current position is that the user should be very cautious when RtrnCap transactions can be applied to multiple lot holdings.  Quicken may or may not get it right, and that caution is independent of reinvestment considerations.  

Part of the answer to "Why not?" includes lack of demand by the userbase and the existence of a viable alternative (two transactions) for those who are interested.  

HTH

Mac

Sincerely appreciate the detailed reply!  Longer term, as you elude to above, it can and does make a big difference.  I don't see why this can't be an option for when inputting "Income".  Options currently for DIV, INT, Long, Short, etc., why not an option for RtnCap with the calculations done behind the transaction.  But as you also state, apparently they haven't been able to do that correctly for a good number of years now either.  Now that Intuit is no longer involved, maybe the new company can make this work?  Or just maybe a Pipe-dream.  Thank you!

q_lurker

I thought enough of your question to start to write it up as an "Idea" post here that would get more direct flow to the development staff.  As I did so, I realized it might not be as easy and straight forward as I first thought.  

First recognition was the the RtrnCap portion of the deal would need to be processed across all existing lots of the current holding. That would effectively be followed by a 'buy' of the new shares.  Because of the impact on prior lots, that makes the deal different than existing reinvestments for dividends, interest, or cap gains.  

So the next thought became, create it as two transactions, RtrnCap and Buy, just like I said you now need to enter manually.  Fair enough, but that makes it different from other Reinv transactions.  That difference might be confusing to some users.  

One of those areas of confusion would be Amount Invested and Amount Reinvested as I cited previously.  As currently configured, when Quicken gets a Reinv... transaction, Amount Reinvested for that security is likewise incremented up and Amount Invested is left alone.  If you take the approach of Div received and Buy shares, then Amount Reinvested is not changed and Amount invested is incremented upward.  So if there was a ReinvRtrnCap 'transaction' selection or a RtrnCap option on the Enter Transactions button for Reinvest Income, and that action generated independent RtrnCap and Buy transactions, the behavior of the Reinvestment would be different than the behavior of the 'normal' reinvestment.  Thus a source of confusion for some users.  

While I personally have little use for either the Amount Invested or the Amount Reinvested parameters, others do find those metric useful.  

From that position and my seat at this keyboard, I think the best approach is the current status quo - specific entry of two distinct transactions.  If you still have a different perspective, creating an Idea post to that effect would be the next step.  (Just don't count on any direct feedback from Quicken, Inc.  It is rare.)

M C Crockett

This thread caught my attention as I have invested in mutual funds that invest, primarily, in Master Limited Partnerships where all dividends are a Return of Capital.

Due to long-standing bug in the Return of Capital transaction logic both Quicken Premier and Quicken for Mac calculate the change in cost basis incorrectly and apply the changes to the wrong lots.

I discovered this after splitting a Reinvest Dividend transaction into separate Return of Capital and Buy transactions.  The problem is that the Return of Capital transactions uses the total number of shares held at the end of the day that the Return of Capital transaction is recorded.

Let's say that you received a dividend of $50.00 based on your owning 500 shares of a security and the dividend was reinvested and you acquired 10 additional shares.  The Quicken Return of Capital transaction will divide the $50.00 by 510 shares to calculate the per share adjustment of $0.098039.
This adjustment factor will be multiplied by the number of shares in each lot and subtracted from the lots cost basis.

I'm sure you see the fundamental flaw in the logic.  The dividend that was classified as a Return of Capital was earned on the shares held prior to the dividend distribution.  The per share adjustment should have been calculated to be $0.10 ($50.00 / 500).

Also, the 10 shares acquired with the dividend should have their cost basis set to $50.00 instead of the $49.01961 calculated by the current Return of Capital transaction logic.

As Quicken hasn't gotten around to correcting the logic error, the user needs to record the Return of Capital the day before it was received.

q_lurker

M C Crockett said:

This thread caught my attention as I have invested in mutual funds that invest, primarily, in Master Limited Partnerships where all dividends are a Return of Capital.

Due to long-standing bug in the Return of Capital transaction logic both Quicken Premier and Quicken for Mac calculate the change in cost basis incorrectly and apply the changes to the wrong lots.

I discovered this after splitting a Reinvest Dividend transaction into separate Return of Capital and Buy transactions.  The problem is that the Return of Capital transactions uses the total number of shares held at the end of the day that the Return of Capital transaction is recorded.

Let's say that you received a dividend of $50.00 based on your owning 500 shares of a security and the dividend was reinvested and you acquired 10 additional shares.  The Quicken Return of Capital transaction will divide the $50.00 by 510 shares to calculate the per share adjustment of $0.098039.
This adjustment factor will be multiplied by the number of shares in each lot and subtracted from the lots cost basis.

I'm sure you see the fundamental flaw in the logic.  The dividend that was classified as a Return of Capital was earned on the shares held prior to the dividend distribution.  The per share adjustment should have been calculated to be $0.10 ($50.00 / 500).

Also, the 10 shares acquired with the dividend should have their cost basis set to $50.00 instead of the $49.01961 calculated by the current Return of Capital transaction logic.

As Quicken hasn't gotten around to correcting the logic error, the user needs to record the Return of Capital the day before it was received.

I can't comment on the Mac program, but I so not see that behavior in the QW2017 H&B version.  

What I do see in the QW version, is that the sequence of the two transactions is relevant.  If you enter as RtrnCap then Buy, the RtrnCap adjusts the cost basis of the pre-existing shares.  If the Buy is first, then the RtrnCap applies to pre-esxisting shares and the newly acquired shares.  

If you took the steps as original ReinvDiv, new RtrnCap, new Buy Shares, delete original ReinvDiv, that might explain your observations.  Not I have not checked that sequencing.  

Footnote:  Several prior QW version were miscalcutating the cost basis adjustment by applying the RtrnCap dollars to the first lot until that cost basis became $0, then the subsequent lots.  That error has been corrected in QW2017 which now allocates the cost basis across all lots in proportion to the share count.  I am not sure is that correction came about in 2016 or 2017, buy I think it was QW2017,  This is independent and separate from the behavior MC Crockett is reporting. 

M C Crockett

M C Crockett said:

This thread caught my attention as I have invested in mutual funds that invest, primarily, in Master Limited Partnerships where all dividends are a Return of Capital.

Due to long-standing bug in the Return of Capital transaction logic both Quicken Premier and Quicken for Mac calculate the change in cost basis incorrectly and apply the changes to the wrong lots.

I discovered this after splitting a Reinvest Dividend transaction into separate Return of Capital and Buy transactions.  The problem is that the Return of Capital transactions uses the total number of shares held at the end of the day that the Return of Capital transaction is recorded.

Let's say that you received a dividend of $50.00 based on your owning 500 shares of a security and the dividend was reinvested and you acquired 10 additional shares.  The Quicken Return of Capital transaction will divide the $50.00 by 510 shares to calculate the per share adjustment of $0.098039.
This adjustment factor will be multiplied by the number of shares in each lot and subtracted from the lots cost basis.

I'm sure you see the fundamental flaw in the logic.  The dividend that was classified as a Return of Capital was earned on the shares held prior to the dividend distribution.  The per share adjustment should have been calculated to be $0.10 ($50.00 / 500).

Also, the 10 shares acquired with the dividend should have their cost basis set to $50.00 instead of the $49.01961 calculated by the current Return of Capital transaction logic.

As Quicken hasn't gotten around to correcting the logic error, the user needs to record the Return of Capital the day before it was received.

Both Quicken Premier 2017 and Quicken for Mac 2017 exhibit the same behavior.

If a Return of Capital transaction is recorded on the same day that additional shares are acquired the adjustments will include the newly acquired shares when computing the adjustment.  In addition the cost basis of the newly acquired shares will be adjusted.  The order in which the transactions are recorded is inconsequential.

I discovered this last year when I sold shares to harvest capital losses in an investment.

I do recall the time when the Return of Capital amount was simply subtracted from the oldest lot until the cost basis went to $0.00.  This is a valid approach if you use the average cost method of valuing your holdings.

q_lurker

M C Crockett said:

This thread caught my attention as I have invested in mutual funds that invest, primarily, in Master Limited Partnerships where all dividends are a Return of Capital.

Due to long-standing bug in the Return of Capital transaction logic both Quicken Premier and Quicken for Mac calculate the change in cost basis incorrectly and apply the changes to the wrong lots.

I discovered this after splitting a Reinvest Dividend transaction into separate Return of Capital and Buy transactions.  The problem is that the Return of Capital transactions uses the total number of shares held at the end of the day that the Return of Capital transaction is recorded.

Let's say that you received a dividend of $50.00 based on your owning 500 shares of a security and the dividend was reinvested and you acquired 10 additional shares.  The Quicken Return of Capital transaction will divide the $50.00 by 510 shares to calculate the per share adjustment of $0.098039.
This adjustment factor will be multiplied by the number of shares in each lot and subtracted from the lots cost basis.

I'm sure you see the fundamental flaw in the logic.  The dividend that was classified as a Return of Capital was earned on the shares held prior to the dividend distribution.  The per share adjustment should have been calculated to be $0.10 ($50.00 / 500).

Also, the 10 shares acquired with the dividend should have their cost basis set to $50.00 instead of the $49.01961 calculated by the current Return of Capital transaction logic.

As Quicken hasn't gotten around to correcting the logic error, the user needs to record the Return of Capital the day before it was received.

I was looking at the cost basis presented in portfolio views. Is there a chance that the actual sale transaction and related cap gains report are behaving differently than the portfolio view data? Don't have time to check that right now.

M C Crockett

M C Crockett said:

This thread caught my attention as I have invested in mutual funds that invest, primarily, in Master Limited Partnerships where all dividends are a Return of Capital.

Due to long-standing bug in the Return of Capital transaction logic both Quicken Premier and Quicken for Mac calculate the change in cost basis incorrectly and apply the changes to the wrong lots.

I discovered this after splitting a Reinvest Dividend transaction into separate Return of Capital and Buy transactions.  The problem is that the Return of Capital transactions uses the total number of shares held at the end of the day that the Return of Capital transaction is recorded.

Let's say that you received a dividend of $50.00 based on your owning 500 shares of a security and the dividend was reinvested and you acquired 10 additional shares.  The Quicken Return of Capital transaction will divide the $50.00 by 510 shares to calculate the per share adjustment of $0.098039.
This adjustment factor will be multiplied by the number of shares in each lot and subtracted from the lots cost basis.

I'm sure you see the fundamental flaw in the logic.  The dividend that was classified as a Return of Capital was earned on the shares held prior to the dividend distribution.  The per share adjustment should have been calculated to be $0.10 ($50.00 / 500).

Also, the 10 shares acquired with the dividend should have their cost basis set to $50.00 instead of the $49.01961 calculated by the current Return of Capital transaction logic.

As Quicken hasn't gotten around to correcting the logic error, the user needs to record the Return of Capital the day before it was received.

I discovered the Return of Capital bug in the Quicken for Mac Portfolio View.  I found that the cost basis for the last lot that was purchased did not match the price in the transaction register.  In addition, I noticed that none of the lots that I was going to sell had the expected cost basis.  Some lots had gains where there should have been losses and vice versa.

To investigate the cost basis discrepancies, I created a NeoOffice spreadsheet.  I entered each Return of Capital dividend, calculated the per share adjustment, and applied it to each lot on which the dividend was earned.  This led to the discovery that Quicken was using the shares held and acquired on the day the Return of Capital dividend was paid in calculating the per share adjustment.

As Quicken for Mac doesn't support all the investment transaction types that I need, I have to import my Quicken Premier database after using an unsupported transaction type.  I looked at my Quicken Premier database and found that it had the same cost basis errors as Quicken for Mac.

The "quick and dirty" solution to this Return of Capital dividend bug is to record the Return of Capital dividend the day before it was actually received and change the reinvest transaction to a buy transaction on the actual day the dividend was distributed.

The Return of Capital dividend bug only occurs when dividends are reinvested or when new shares of an equity are acquired on the day the Return of Capital dividend is recorded.

Another part of the problem is that the erroneous gains/losses appear in the Tax Schedule report and in the .txf file that is created when you export the report for use with TurboTax or other tax preparation software.