BUG: ESPP Income - Cost basis computation

[andrecs]

OMG everyone - I can't believe it, but I just updated my software this morning with the Feb. 26th (Friday) software update. I then went in and tested a few more of my ESPP transactions, and it appears this bug is fixed. The form 3922 data is now flowing to the forms view, and TT is correctly computing the cost basis.

Thank god.

[edenddc12]

@ReneeM7122 

I've tried doing what you suggested after the latest software update (using desktop version).

On the step-by-step wizard it recognizes the corrected cost basis and completes the flow  by showing the right amount.

HOWEVER, going to the Form view and looking at the produced 8949, I see that only the first ESPP sale has the corrected cost basis (with code "B" in column f). The second ESPP sale (and later) still show the wrong cost basis from the 1099-B and there is no code in column f.

Very disappointed.

[andrecs]

Huh, that is strange. I just checked my 8949, and it does appear to be properly adjusting my cost basis for all of my ESPP's (code B, column f, as you said). 

The only strange thing is the 8949 only fits 6 short term transactions (all of mine are short term) and I have like 35.. I'm not sure where the rest flow to? Maybe you're not required to list them all in the 8949, I don't know.

[Terrapin]

@andrecs There should be a scroll bar on the side to allow you to see the rest of the transactions.

[andrecs]

That worked - thank you!

[Terrapin]

I'm somewhere in the middle. For the form 8949 "Box E" transactions (Long-term, basis not reported), there is no adjustment in column (g), but the cost basis in column (e) shows the adjusted amount, so the numbers all work out in the end. The worksheets feeding into form 8949 look correct. The other form 8949 transactions (Box A, B, etc.) look correct, with the original cost basis in column (e) and the correct adjustment in column (g). 

The IRS might not like the original cost basis in form 8949 not matching the 1099-B that they received, so this will still require some overriding in TurboTax. But at least the actual tax is now being calculated correctly.

[Terrapin]

Never mind,  I suppose it doesn't matter since "Box E" means the cost basis was not reported to the IRS, so it's OK if the cost basis adjustment isn't itemized properly. So for me, the software works now.

[edenddc12]

I can now see it working with the latest update but only if I choose "Walk me through adding more info". If I go by "I have all my info" the wizard will complete the transaction by showing the corrected cost basis, but it will not go through to the forms, where it will default to the wrong cost basis from Box A and no code in column (f) -- with the exception of the first ESPP transaction.

In other words the bug has been partially fixed and the software is still very erratic. I don't want to imagine what terrible spaghetti code Intuit have under the covers, but I do know that next year that code will not be processing a single bit of my data. I am so disappointed with the poor quality of this overpriced crapware.

[eeggel]

Update on my part.  I've no clue if they fixed it.  I did as others have suggested and entered a different account for each ESPP transition. ( the work around probably stated different brokerage but I found it worked under one brokerage and different account designations ).  After entering my transactions the corrected cost basis totals were very close to my W2 value reported so I called it good.  Intuit / TurboTax has been absolute crap in handling this.  They owe everyone purchasing this a refund of the price dif between the NON-ESPP versions and this up sell.  It is just a stupid software bug.  They took my data and were to have emailed me when the defect was fixed.  Never got an email.