Return of capital

Charlie R
Charlie R Member ✭✭
edited April 2023 in Investing (Windows)
How to correct stock cost that is off because of return of capital is being added to wrong lots

Best Answer

  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭
    Answer ✓

    @Charlie F Another recollection — I have seen cases where editing a transaction from one action-type to another does not produce the same result as a new entry. Suspect behavior is that some nuances of the original transaction carry over to the edited transactions when they are not aplicable. I won't swear that applies here, but it might.

    So if you had a maybe a MiscInc transaction with the Other Income:Non-taxable category applied to it, and then edited that transactions to be a RtrnCap transaction, the original category might have been carried over when it should have been erased. The only way to clear such an erroneous edit carryover was (is) to delete the original and enter a new transaction.

    Plausible in your case?

«1

Answers

  • NotACPA
    NotACPA SuperUser ✭✭✭✭✭

    ROC should have been applied to all lots. How is it wrong?

    Also, what Q product are you running and what BUILD of that product?

    Q user since February, 1990. DOS Version 4
    Now running Quicken Windows Subscription, Business & Personal
    Retired "Certified Information Systems Auditor" & Bank Audit VP

  • Charlie R
    Charlie R Member ✭✭
    There was a lot that I bought X Div and sold it after 1 div/Roc the broker has it right but q is wrong
  • NotACPA
    NotACPA SuperUser ✭✭✭✭✭

    You're too cryptic. ELABORATE. And answer my questions!

    Q user since February, 1990. DOS Version 4
    Now running Quicken Windows Subscription, Business & Personal
    Retired "Certified Information Systems Auditor" & Bank Audit VP

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    I owned 3 lots of 1000 of BRW I bought another lot x Div/ROC so I shouldn't get the next Div/ROC, after the 2nd Div/ROC date, which I rec that Div/ROC I then sold that lot, I should only have the 1 Div/ROC but quicken has a larger Gain for the sale. The broker only added the 1 Div/ROC which is right so Q is now out of Bal with broker. I am using Q Premier R48.9
  • Tom Young
    Tom Young SuperUser ✭✭✭✭✭

    If you only have 4 lots then the way to address this is to do a Remove of all shares of BRW, then do 4 Adds to get the lots reestablished in Quicken, using the correct Acquired date and basis for each lot. Back up before doing this, just in case.

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    I have bought and sold this stock many times starting in 2010 but the ROC didn't start until 2021 the stock was renamed and then rev split 5/21/22, I will take a look but I'm not sure how many lots would be involved. I was thinking move the ROC dates around that 1 trade to force Q to not give it the part of 2 ROC instead of the one it should.
  • Tom Young
    Tom Young SuperUser ✭✭✭✭✭

    " I was thinking move the ROC dates around that 1 trade to force Q to not give it the part of 2 ROC instead of the one it should. "

    That might work too. The reverse split shouldn't be a problem. Even so, back up and you may want to figure, outside of Quicken, what the end results should be and then compare Quicken to that. Of couse another approach is "ive with it" if, overall, your basis and the broker's basis agree and the "miss" on the gain on sale isn't too material. You're going to have the "correct" gain on sale on the 1099 for the income tax return.

  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭

    " I bought another lot x Div/ROC "

    I am not clear on what that terminology means. Are you saying the security made a distribution to you that you reinvested, and then that distribution proved to be part dividend and part ROC?

    If that is the case, I believe you need to be careful with the sequencing and dating. I would record the dividend and ROC a day early. The ROC will adjust the basis of the three original lots. Then on the date of the real distribution, enter the buy shares for the right share count and Div+ROC amount. Repeat as applicable for each Div/ROC distribution. Each additional ROC would adjust all prior lots - original buys and prior ROCs.

    Is that what you see the brokerage doing? At one level it would surprise me becasue that DIv / ROC distinction often does not become available until 1099's get distributed which could be a year after the actual distribution.

    @Tom Young 's approach using Remove and Add Shares is the only other way to bring basis around to the broker's values.

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    @Tom Young, I deleted the trades and reinstalled them, no difference. Thanks
    I am going to try what q_lurker recommended (if I can).
    This is the problem, the Div/ROC is posted monthly so at the end of the year 1st 1099s was corrected for Div/ROC adjustment and then a 2nd corrected 1099 was sent to correct the value of stocks that were sold because the Div/ROC changed the cost of the stock which no longer matches Q value.
    I will let everyone know if if gets fixed. Thanks again to all.
  • Tom Young
    Tom Young SuperUser ✭✭✭✭✭

    "@Tom Young, I deleted the trades and reinstalled them, no difference. Thanks."

    Not sure what you're referring to here. Simply deleting the trades and then putting them back, as they were originally recorded, shouldn't come to a different result, if that's what you are saying you did here.

    There really are only two logical approaches.

    The first is to completely REMOVE the shares using "today's" date, and then do ADD transactions, still using today's date, where you re-establish each lot with a correct date of acquisition and a correct basis. If, as of "today" you only have a fairly small number of lots (you define "small" on your own terms), then this is a straight-forward and fairly easy process.

    The second is to go back and delete each and every trade and then try to duplicate what you think the broker is doing (and maybe is doing) of entering a return of capital transaction and a dividend transaction - each appropriately timed - so that the "correct" lots are affected.

  • Charlie R
    Charlie R Member ✭✭
    To all, I just checked my TD Ameritrade accounts and found that they shows in their Gains Keeper a date for receiving Div/ROC as 1/7/22 and post date in quicken as Rec 1/26/22, my E*T statement shows Div/ROC receieved date as 01/10/22 with pay 01/26/22 do you think if I change the received date it might fix the issue. WOW, this has never been an issue before.
  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭

    Yahoo Finance shows BRW paid a dividend 1/7/22. Seemed to consistently pay 7th, 8th, or 9th last year except for May 23. No idea why your Quicken record would show receiveds that much later. Is it similarly consistent through the year?

    do you think if I change the received date it might fix the issue. 

    Understand. The ROC will adjust the cost basis of every lot owned at the time the ROC is dated in Quicken. If you bought shares on 1/15/22, then an ROC dated 1/26/22 will reduce the basis of that lot. An ROC dated 1/7/22 will not. I can't say what your broker is doing or did.

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    In Quicken I changed the ROC posted date date to the brokers received date and left the brokers Div Income date as the posted date, each individual trade Gain/Loss matches Q & Broker, but when I run a Q - Gain/Loss report it is way off, I think when Q adds the Gain/Loss report something is wrong within Q, also when I run a Q 2023 G/L report for same stock Q now matches my broker.
  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    Have Talked to Q for many hours (GREAT Representatives) but problem is not solved, Q will work on it and hopefully figure it out.

    I think, this is a unique situation because the ROC is posted monthly not quarterly, because the Gains/Losses went out of sync after the Yr End adj of Div to ROC, the Q's report program needs to be looked at, I have never seen this in my many, many years with Q.

    Again thanks to all for your help and support, I am only looking to help.
  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭

    @Charlie R Honestly what I would likely do is recreate the sequence from scratch manually in a test file

    • Buy 1000 shares for $X
    • Buy 1000 shares for $Y
    • Buy 1000 shares for $Z
    • RtrnCap for $___
    • Div for $ ___
    • Buy more shares
    • Sell shares

    Follow through step by step seeing how cost basis per lot and in total change. Compare to brokerage data step by step. That should (could?) lead you to identify where Quicken and the brokerage start diverging, or where Quicken says one thing one place and something else in a different location.

    I don't see why Quicken would behave any differently monthly vs quarterly.

    Quicken does not have a Report named Gain/Loss. That leaves me guessing at what you mean. Maybe that is a Capital Gains report but you might mean something else. Please try to be as exact and clear as possible when making such references.

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    @q_lurker, Your right I was talking about a Cap Gains report. We made a test file and did all that and one thing caused a problem.
    9/16/22 Buy 1000 shares for $Z
    9/30/22 RtrnCap for $___
    9/30/22 Div for $ ___
    10/30/22 RtrnCap for $___
    10/30/22 Div for $ ___
    11/16/22 Sell 200 shares
    11/22/22 Sell 153 shares
    11/16/22 Sell 647 shares
    Sell Trade totals didn't match Broker but Cap Gains report matched the sell trade totals.
    Moved 1st RtrnCap from 9/30/22 to 9/9/22 and then Cap Gains report matched Broker Cap Gains report totals and also matched the sell trade totals.
    But when when we did the same thing in the real file the trade totals matched the Broker but the Cap Gains report totals didn't match the trade totals. This stock pays Div monthly and as you know the RtnCap comes from the 1099 at end of year which is broken down monthly and that's when the report totals went wrong, the trade totals are right.
  • Charlie R
    Charlie R Member ✭✭
    @q_lurker, I have been looking for the reason. Is there a difference between RtrnCap being Posted to Uncategorized or Other Income Non Taxable?
  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭

    Don't know. All mine categorize as Uncatergoried in Investment Transaction Reports. Where are you eeing the Other Income Non-taxable for a RtrnCap transaction?

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    In Investment Transaction Reports, see attached.
  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭

    That seems really odd. Have you tried entering a new transaction for each of those 4 oddballs?

    Is it those 4 oddballs that are not adjusting the cost basis correctly?

  • q_lurker
    q_lurker SuperUser ✭✭✭✭✭
    Answer ✓

    @Charlie F Another recollection — I have seen cases where editing a transaction from one action-type to another does not produce the same result as a new entry. Suspect behavior is that some nuances of the original transaction carry over to the edited transactions when they are not aplicable. I won't swear that applies here, but it might.

    So if you had a maybe a MiscInc transaction with the Other Income:Non-taxable category applied to it, and then edited that transactions to be a RtrnCap transaction, the original category might have been carried over when it should have been erased. The only way to clear such an erroneous edit carryover was (is) to delete the original and enter a new transaction.

    Plausible in your case?

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    @ q_Lurker I did delete and enter it again, although as far as I can see it didn't change any totals, but it did remove it from other income non taxable.
    Thanks, Charlie
  • Charlie R
    Charlie R Member ✭✭
    @NotACPA the trades are right the reports are wrong.
  • Charlie R
    Charlie R Member ✭✭
    @ q_Lurker_This is not about the same account as I posted on 2/27/23 for my Acct 0318 which numbers match for trade post and report.

    Is it normal for a Investment Transaction Report to show the trade post for a stock sale in both RtzdGain and Expenses (Uncategorized) in the same report. This is my Acct 4013 the file which for some reason the post and the reports don't match.

    Just fishing around, still looking for the fix to the BRW issue. see attached
    Thanks
  • Charlie R
    Charlie R Member ✭✭
    @NotACPA sorry I didn't get back to you sooner. I'm using Q Premier R48.15 Build 27.1.48.15 valid until 1/17/2024 if you've been following I talked to Q for hours with no solution, have been trying anything suggested but the Post totals still match my broker and the CapGains report total still don't. Thanks
  • Charlie R
    Charlie R Member ✭✭
    @q_lurker I really believe the issue is the Q Report program. Thanks for all your help
  • NotACPA
    NotACPA SuperUser ✭✭✭✭✭

    Are you selecting the same LOTS for sale as your brokerage? Unless you specify otherwise, at time of sale, they'll almost always choose FIFO

    Q user since February, 1990. DOS Version 4
    Now running Quicken Windows Subscription, Business & Personal
    Retired "Certified Information Systems Auditor" & Bank Audit VP

  • Charlie R
    Charlie R Member ✭✭
    @NotACPA Yes the trades match my broker just the reports are off, I think it has something to do with the return of capital. I give up and Q is working on it.
    Thanks
  • NotACPA
    NotACPA SuperUser ✭✭✭✭✭

    But are you selecting the same TAX LOTS as your broker?

    Q user since February, 1990. DOS Version 4
    Now running Quicken Windows Subscription, Business & Personal
    Retired "Certified Information Systems Auditor" & Bank Audit VP

  • Charlie R
    Charlie R Member ✭✭
    edited March 2023
    @NotACPA Yes same lots. I am 80 years old who has trades for 45 yrs, this has never happened to me before.
    I think it has something with end of year Return of Capital adjustment on a monthly basis????? I was in Balance before end of year Adj from 1099 Div to RtrnCap I give up
This discussion has been closed.