Why is the cost basis wrong?

johnlebas

I have a small lot of Cigna (CI) stock purchased on 4/1/2019. I had previously owned CI in multiple lots bought and sold between 8/17/2018 and 3/1/2019. Quicken correctly shows that the balance of CI shares in the account on 3/31/2019 is zero. But once the shares are "bought" on 4/1/2019, the basis is incorrectly reported as the purchase price for these shares plus the sum of all previous bought and sold amounts, resulting in a reported basis that is $830 greater than the purchase price of the 4/1/2019 lot. I've validated and repaired the data file as well as rebuilt the investing lots (File -> File Operations -> Validate and Repair). I am pretty sure this error has only recently emerged. Any suggestions?

I am running Windows 10 Pro and Quicken Home, Business and Rental Property, 2020, Version R26.23, Build 27.1.26.23.

q_lurker

johnlebas said:

I have a small lot of Cigna (CI) stock purchased on 4/1/2019. I had previously owned CI in multiple lots bought and sold between 8/17/2018 and 3/1/2019. Quicken correctly shows that the balance of CI shares in the account on 3/31/2019 is zero. But once the shares are "bought" on 4/1/2019, the basis is incorrectly reported as the purchase price for these shares plus the sum of all previous bought and sold amounts, resulting in a reported basis that is $830 greater than the purchase price of the 4/1/2019 lot. I've validated and repaired the data file as well as rebuilt the investing lots (File -> File Operations -> Validate and Repair). I am pretty sure this error has only recently emerged. Any suggestions?

I am running Windows 10 Pro and Quicken Home, Business and Rental Property, 2020, Version R26.23, Build 27.1.26.23.

I believe you have a problem with one or more of the prior sales not properly registering as a sale of actually held securities.  I would:
a)  Create a backup so you a have a fallback position.
b)  Starting with the latest sale, delete and re-enter the sale specifying the lot sold in that sale.  Make sure that specified lot 'makes sense'.  (There is also a rationale for starting with the oldest sale and working forward, or for deleting all sales and then re-entering them.)  I believe you will find that some sale had somehow been misapplied to which shares were actually sold. 

Also, just to make sure -- you are talking about Cost Basis as reported by Quicken and not Amount Invested, a different Quicken parameter.  Correct?

  

Frankx

Hi @johnlebas,

It looks like you've tripped the dreaded IRS "wash sale" rule.  If you are not familiar with that - it is a rule that prevents taxpayers from taking a loss on the sale of security and them buying the same security back within 30 days.  So that's probably why Quicken continued to carry over your basis in the old holdings.

Frankx

johnlebas

No, that's not the problem (I have run into that before). The online brokerage records for open/closed positions does not show this as a wash sale -- although it is close, March 1 sale, April 1 purchase. To further test this, I changed the purchase date in Quicken to 4/3/19 in case Quicken was using a "31-day" rule. But, this did not change anything. I then changed the purchase date to 5/1/2019. There was no balance for CI on Quicken reports for 4/30/2019, but the basis error returned for dates later in May. I also tied to copy the file as I have heard that sometimes finds and repairs errors not found with the Validate and Repair action. That did not work either.

Quicken support, any suggestions?

Jim_Harman

Are you sure there are no hidden Placeholders that might be confusing things? Go to Edit > Preferences > Investing Transactions and make sure the Show Hidden transactions box is checked.

Also click on Holdings for the account in question then click the little plus sign next to Cigna to show the individual tax lots. Adjust the As of date to just before and after your 4/1/2019 Bought. Do Cigna and the old lots come and go as expected? Do the old lots actually reappear after 4/1/2019?

You might try deleting and re-entering the 3/1/19 Sold transaction to see if that fixes things.

Frankx

@johnlebas,

I understand that you've run the different "test" scenarios, and based on what you've said I cannot explain why this is happening, per your facts.  But you can't argue that Quicken isn't treating it as a wash sale, because in spite of the various iterations you've tried, the Quicken results indicate that it is (correctly or incorrectly) applying the wash sale rules.

Anyway, while some Quicken employees do monitor this forum, they don't always weigh in on discussions.  So I suggest that you contact Quicken Support via this link for additional assistance https://www.quicken.com/support#windows

Good luck.

Frankx

Jim_Harman

@Frankx,

Searching the in-product Help for wash sale yields the following:

• Quicken doesn't distinguish wash sales from other sales. (A wash sale is a sale at a loss within 30 days of acquiring the same security. Special tax rules apply.)

so I would guess that this problem is not wash sale related.

Frankx

@Jim_Harman,

You are correct - I just reviewed the Help info.  The really crazy part is that I know I got a pop-up or some kind of notification about a wash sale in Quicken, but according to Help, as you note above, I must have been mistaken.

Thanks.

Frankx

Frankx

Hi again @Jim_Harman,

I just realized what I was thinking of re: the Wash Sale - Quicken gives a warning when you attempt to enter a transaction that will result in a wash sale, which I had remembered.  I guess I just assumed that it would also compute the new basis after such a sale, but I guess not.

Frankx

q_lurker

johnlebas said:

I have a small lot of Cigna (CI) stock purchased on 4/1/2019. I had previously owned CI in multiple lots bought and sold between 8/17/2018 and 3/1/2019. Quicken correctly shows that the balance of CI shares in the account on 3/31/2019 is zero. But once the shares are "bought" on 4/1/2019, the basis is incorrectly reported as the purchase price for these shares plus the sum of all previous bought and sold amounts, resulting in a reported basis that is $830 greater than the purchase price of the 4/1/2019 lot. I've validated and repaired the data file as well as rebuilt the investing lots (File -> File Operations -> Validate and Repair). I am pretty sure this error has only recently emerged. Any suggestions?

I am running Windows 10 Pro and Quicken Home, Business and Rental Property, 2020, Version R26.23, Build 27.1.26.23.

I believe you have a problem with one or more of the prior sales not properly registering as a sale of actually held securities.  I would:
a)  Create a backup so you a have a fallback position.
b)  Starting with the latest sale, delete and re-enter the sale specifying the lot sold in that sale.  Make sure that specified lot 'makes sense'.  (There is also a rationale for starting with the oldest sale and working forward, or for deleting all sales and then re-entering them.)  I believe you will find that some sale had somehow been misapplied to which shares were actually sold. 

Also, just to make sure -- you are talking about Cost Basis as reported by Quicken and not Amount Invested, a different Quicken parameter.  Correct?

  

johnlebas

I have fixed the problem; thanks for the help. I believe the solution was along the lines of what q_lurker suggested, however, the error was cleared in a different way. When I went to the sale on 4/1/2019. I saw the number of shares available for sale in one purchase lot was wrong and one lot was not listed as available for sale. It earlier had been correct and it was not clear why the shares on the one lot increased and another lot disappeared. I looked at the past transactions and all appeared to be correct, so I deleted the sale lots in the Specify Lots Sold screen and saved the 4/1 transaction. When I reopened the 4/1 sale transaction, the number of shares available for sale were all correct. I specified the correct allocation and saved the transaction. The quicken reports are now reflecting the correct amounts.

It seems like something had gotten messed up in the Quicken data file and deleting the data allowed it to be corrected. I can't say this leaves me feeling satisfied since if this happened once it can happen again. Bugs like this are hard to find.

q_lurker

@johnlebas That is just the sort of line I was trying to send you on.  Give yourself a pat on the back.  Be satisfied that you got this one identified, but be a bit watchful going forward.  I might catch something like that once every year or two. 

Anymore, I try to a) enter transactions sequentially in time, especially for an individual security, and b) either let a security be totally default lot specification (FIFO) or specify lots for each and every sale of that security.  I don't know that having a mix of those for one security is an issue, but I can imagine it could be.