Return of Capital

Unknown
Unknown Member
edited November 2018 in Investing (Windows)

Re:  Return of Capital
Transactions (ROC)

After many years of using Quicken, I’ve just upgraded to the
newest, Quicken Deluxe 2017 for Windows on Windows 10.  Frankly, I
am very disappointed to see that Quicken’s handling of the Return of Capital
ROC investment transaction is still in error. 
It’s a real shame that a great product like Quicken exposes its
reputation to such a simple transaction. 

I’ll say again what I and other Quicken users have said and
documented before:  For us, the
recipients of Returns of Capital, a ROC transaction is an increase (debit) to cash (for the
particular investment account), and a decrease (credit) to the original cost
basis of the specific security involved (applied to the oldest lot first – See
IRS Publication 550).  There is NO income
and NO impact on Market Value. 
NONE.  Think of a ROC transaction
as a retroactive reduction of original purchase price which included NO
expense;  cash flow, yes, but NO expense,
and conversely NO income when that security pays out a ROC.  It doesn’t matter if this transaction is
accompanied by an amount reinvested (BUY) transaction. 

Early last year (2016 and earlier?) Quicken was correctly
increasing cash in the specific investment account, and correctly decreasing
the cost of the security affected.  BUT,
in addition to those correct actions, the ROC transaction was also incorrectly
spinning out an income item, albeit an Uncategorized Income item. 

Then later last year (sometime after 04/15/16), ROC
transactions started to be Categorized as, and included with Dividend
Income.  At that point, we’ve gone from
bad to worse.  (Note:  The impacts on Cash and Cost were still being
handled correctly, but income?  No). 

Most recently, in addition to being erroneously included
with Dividend Income, the amount of ROC transactions has also been incorrectly subtracted
from, of all things, Market Value on the 12/31/16 beginning balance of
2017’s Net Worth report, but oddly, and correctly, not on the 12/31/16 ending
balance of 2016’s Net Worth report; 
and the Investment window shows the correct balance for that security as
of 12/31/16.  Now we’ve gone from bad, to
worse, to WORSER. 

Can you please correct/eliminate these attempted income items
and impacts on market values for the ROC transactions?  It would help if the corrections could be
made retroactively to the beginning of 2017. 

For quality control purposes, an Income Statement for any
period reveals how Net Worth has changed over that period of time.  Therefore, a basic principle of accounting
states that Net Income/Loss for a period SHOULD be equal to the change in that
period’s Net Worth.  The Quicken Net
Income and the change in Net Worth do NOT agree, necessitating a lengthy
process of identifying variances and generating reconciling items in order to
create useful reports outside of Quicken. 
The ROC transactions are not the only reconciling factors, but appear to
be a major factor. 

Comments

  • mshiggins
    mshiggins SuperUser ✭✭✭✭✭
    edited March 2017
    Are you downloading these ROC transactions from your financial institution?

    Quicken user since Q1999. Currently using QW2017.
    Questions? Check out the Quicken Windows FAQ list

  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭
    edited May 2018
    I’ll say again what I and other Quicken users have said and documented before:  For us, the recipients of Returns of Capital, a ROC transaction is an increase (debit) to cash (for the particular investment account), and a decrease (credit) to the original cost basis of the specific security involved (applied to the oldest lot first – See IRS Publication 550).  
    Your parenthetical comment is incorrect, or at best incomplete.  

    IRS Pub 550

    Basis adjustment.   A nondividend distribution reduces the basis of your stock. It is not taxed until your basis in the stock is fully recovered. This nontaxable portion also is called a return of capital; it is a return of your investment in the stock of the company. If you buy stock in a corporation in different lots at different times, and you cannot definitely identify the shares subject to the nondividend distribution, reduce the basis of your earliest purchases first.  (Emphasis added)
    The Publication 550 statement includes the qualifying clause I emphasized.  In every case I can recall when I received a RtrnCal distribution, it was on a per-share basis and thus I could identify the specific shares subject to the nondividend distribution.  Thus it was not applicable to apply the distribution to the first (earliest lot).  Quicken has the data to properly allocate such RtrnCap distributions.  It is my opinion, that applying the entire distribution to the first (oldest lot) is improper.  There are exceptions such as when the cost basis of any particular lot has already been reduced to zero.  The IRS is clear that the basis of a lot cannot be reduced to less than zero.  If the user is managing a mutual fund security on an average cost basis, that might create an exception.  But a basic statement that the IRS requires the entire RtrnCap to be applied first to the oldest lot is not valid.  I believe Quicken fell into that trap with the 2013 or 2014 Win program.  Someone reported it had been fixed in the 2017 version but I have not confirmed that.  Other than takeing exception to that parenthetical statement, I have no issue with your broader explanation of the RtrnCap transaction.  
    BUT, in addition to those correct actions, the ROC transaction was also incorrectly spinning out an income item, albeit an Uncategorized Income item. 
    You have not been specific as to how and where you are seeing this Uncategorized Income presentation.  I see that in an Investment Income report among others.  As such a report can be construed to be Cash Flow as much as anything else, I don't have a real problem with that inclusion.  Those transactions (RtrnCap) can be excluded from that report is necessary.  I do not see those RtrnCap transactions appearing on any taxable income presentations.  
    Then later last year (sometime after 04/15/16), ROC transactions started to be Categorized as, and included with Dividend Income.  At that point, we’ve gone from bad to worse.  
    I have recently noticed (QW2014) that if I edit a Div transaction to make it a RtrnCap transaction, then the transaction retains its original _Div status.  This is an error on Quicken's part.  My workaround has been delete the original Div transaction and enter a new RtrnCap transactions.  This type of circumstance is applicable when a security has recharacterized all or part of their distribution through the year as RtrnCap rather than as Dividends reportable as 1099-Div income.  I don't know if my observation might relate to your comment, but it is the only case I have noted of RtrnCap data appearing as Div-related.    

    At this point, I have not made any attempts at assessing your Market Value or net Worth report comments, so I have nothing to say at this time in those respects.  
  • Unknown
    Unknown Member
    edited May 2017
    q.lurker said:

    I’ll say again what I and other Quicken users have said and documented before:  For us, the recipients of Returns of Capital, a ROC transaction is an increase (debit) to cash (for the particular investment account), and a decrease (credit) to the original cost basis of the specific security involved (applied to the oldest lot first – See IRS Publication 550).  
    Your parenthetical comment is incorrect, or at best incomplete.  

    IRS Pub 550

    Basis adjustment.   A nondividend distribution reduces the basis of your stock. It is not taxed until your basis in the stock is fully recovered. This nontaxable portion also is called a return of capital; it is a return of your investment in the stock of the company. If you buy stock in a corporation in different lots at different times, and you cannot definitely identify the shares subject to the nondividend distribution, reduce the basis of your earliest purchases first.  (Emphasis added)
    The Publication 550 statement includes the qualifying clause I emphasized.  In every case I can recall when I received a RtrnCal distribution, it was on a per-share basis and thus I could identify the specific shares subject to the nondividend distribution.  Thus it was not applicable to apply the distribution to the first (earliest lot).  Quicken has the data to properly allocate such RtrnCap distributions.  It is my opinion, that applying the entire distribution to the first (oldest lot) is improper.  There are exceptions such as when the cost basis of any particular lot has already been reduced to zero.  The IRS is clear that the basis of a lot cannot be reduced to less than zero.  If the user is managing a mutual fund security on an average cost basis, that might create an exception.  But a basic statement that the IRS requires the entire RtrnCap to be applied first to the oldest lot is not valid.  I believe Quicken fell into that trap with the 2013 or 2014 Win program.  Someone reported it had been fixed in the 2017 version but I have not confirmed that.  Other than takeing exception to that parenthetical statement, I have no issue with your broader explanation of the RtrnCap transaction.  
    BUT, in addition to those correct actions, the ROC transaction was also incorrectly spinning out an income item, albeit an Uncategorized Income item. 
    You have not been specific as to how and where you are seeing this Uncategorized Income presentation.  I see that in an Investment Income report among others.  As such a report can be construed to be Cash Flow as much as anything else, I don't have a real problem with that inclusion.  Those transactions (RtrnCap) can be excluded from that report is necessary.  I do not see those RtrnCap transactions appearing on any taxable income presentations.  
    Then later last year (sometime after 04/15/16), ROC transactions started to be Categorized as, and included with Dividend Income.  At that point, we’ve gone from bad to worse.  
    I have recently noticed (QW2014) that if I edit a Div transaction to make it a RtrnCap transaction, then the transaction retains its original _Div status.  This is an error on Quicken's part.  My workaround has been delete the original Div transaction and enter a new RtrnCap transactions.  This type of circumstance is applicable when a security has recharacterized all or part of their distribution through the year as RtrnCap rather than as Dividends reportable as 1099-Div income.  I don't know if my observation might relate to your comment, but it is the only case I have noted of RtrnCap data appearing as Div-related.    

    At this point, I have not made any attempts at assessing your Market Value or net Worth report comments, so I have nothing to say at this time in those respects.  I agree with Walt.  When I receive a return of capital (cash in my brokerage account) I need to reduce my Cost basis of that security.  Instead, Quicken creates an income statement amount that is called 'uncategorized' income.  This means that when I sell the underlying security, my cost basis will be incorrect.
  • JBDubhe
    JBDubhe Member ✭✭
    edited February 2018
    The calculation is unbelievably straightforward.  The return of capital, in addition to increasing cash in the account, reduces basis.  If you have purchased multiple lots, the reduction is applied to each lot in proportion to the number of shares in the lot compared to the total number of shares owned.  It is not rocket science.  The program has all the information it needs to make the adjustment.  If it is not going to do so, the return of capital transaction should NOT ask that you identify the stock to which the return is related.  Instead, you should get an instruction to manually adjust the cost basis of each lot to distribute the basis reduction appropriately.  It is disappointing, sad even, that the program doesn't do the calculation, but by collecting all the data needed (the name of the security involved) when the Return of Capital transaction is entered, one is misled into thinking that the information will be put to good use.  
  • TMac
    TMac Member ✭✭✭
    edited October 2018
    Does this issue still exist in 2018 Premier?  I currently use 2015 Premier and extensively use RtrnCap txns in multiple investment accounts. Been using Quicken for 25+ years and haven't seen RtrnCap txns appear as uncategorized income in reporting/tracking. So this issue may have been introduced with the 2016 version. I'm preparing to upgrade to 2018 due to sunset of 2015 in April. Are 2018 users seeing this issue?
    Quicken user since 1991 - Premier Subscription, Windows 7
  • Unknown
    Unknown Member
    edited March 2018
    yes it does.  I am waiting on a chat to ask for the solutions.  Here is my situation:

    There were spin off
    transactions recorded for 3 securities in one brokerage account.

    The Account Balances
    report: The difference between the report and the brokerage statement is
    $5,911.93.

    The Portfolio Value
    and Cost Basis:  The balance for the 3
    securities which have the return of capital transactions totals $5,911.93.  The cost basis for these 3 securities is zero.
  • Unknown
    Unknown Member
    edited March 2018
    Sounds like there are two issues here.  One is the proper adjustment of cost basis when there is a return of capital (ROC).  The other is the much less complicated matter that unless you do it just right, a ROC can get reported by Quicken as dividend income.  The cost basis issue is a major headache, and I know I'll have to face it one of these days when I sell a security that has ROC.  But today I've had an unpleasant encounter with the reporting issue.

    When my broker's 1099 reports arrived, I noticed that three of my mutual funds had reclassified dividends as ROC ("non-dividend distributions").  So, using my Quicken 2016 Premier version R14.12, I proceeded to make the corrections in my Quicken account register.  Two of the funds had reclassified only a portion of their dividends.  So for those I corrected the amount of the dividend transactions and then inserted new transactions for the ROC.  But one of the funds reclassified all of its dividends as ROC.  So for each of those dividend transactions, I clicked on the edit button, changed the action for the transaction from dividend income to ROC, and inserted the appropriate amount.  It all looked perfect in the register when I was finished.

    But when I printed out my Quicken Tax Summary report, there among the _DivInc transactions were the four ROC transactions for the fund where all of the dividends were reclassified.  They stuck out like a sore thumb because after the account name was "RtrnCap."  And these ROCs were added into the total dividend income for the year on the Tax Summary report.  q.lurker is exactly right when he reports:
    I have recently noticed (QW2014) that if I edit a Div transaction to
    make it a RtrnCap transaction, then the transaction retains its original
    _Div status.  This is an error on Quicken's part.  My workaround has
    been delete the original Div transaction and enter a new RtrnCap
    transactions.
    So I tried q.lurker's workaround.  I entered new ROC transactions identical to the ones that were already there and then deleted the original transactions.  Worked like a charm.  Now my Tax Summary is correct.

    But what a Mickey Mouse way to run a railroad!  Come on, Quicken, you can fix this!  If you write the software so that "Actions" are entered on investment transactions, but "Categories" are not shown, then you have an obligation to make sure that when a user edits one of these transactions by changing the Action, that produces the correct change in the Category as well.  Give us a break!  Preparing a tax return is stressful enough when all goes well; we don't need ridiculous software bugs like this one making it even worse!
  • Unknown
    Unknown Member
    edited November 2018
    Just as a point of reference, I am using Quicken 2017 Premier for Windows, and have encountered the same problem of a discrepancy between ending account balances and Net Worth reported balances caused by Return of Capital transactions. The workaround that I just recently discovered was that if I re-create the Return of Capital transaction, and then simply delete the original one, then this transaction is correctly handled (in terms of Net Worth reporting).

    My ROC transactions were as old as 2005 and as recent as 2015. So, it would seem that old recorded ROC transactions had this problem, but that newly entered ones do not. Unfortunately, this does mean re-creating all "old" ROC transactions to rectify the problem :-\.
This discussion has been closed.