Incorrect Category for Investment Transactions

craig.

It only happens a couple of times per year and for only a few of my (Vanguard) investment funds, but when these funds issue Long or Short Term Capital Gains that are automatically reinvested, One Step Update only categorizes them as Dividends, even though the memo that is downloaded with the transaction CLEARLY states "DIV REINVEST LT CAP GAIN" or "DIV REINVEST ST CAP GAIN".

This Quicken failure requires me to remember to identify these transactions and manually edit them to categorize the correct long or short term gain for accurate reporting for tax purposes. Since this data is provided, can't Quicken be programed to identify if and assign the correct category?

NotACPA

Except that it's Vanguard that's sending the Investment Action. Apparently they're sending a Div instead of the proper transaction.

SO, you're asking that Q pay attention to the Memo instead of the Action … I don't think so.

craig.

OK, so its Vanguard that sends the category? What specifics should I ask them to change it to?

NotACPA

Not the Category, the Action. They should be sending a CGShort, CGLong, ReinvLG etc as appropriate for the transaction.

Jim_Harman

I am seeing the same issue. Three ReinvDiv transactions downloaded today for VWILX. One was correct, a dividend reinvestment. The second was actually a short term capital gain distribution, and the third was a long term capital gain distribution. Looking in the OFX log, the INCOMETYPE for each transaction was DIV.

I have reported this via Report a Problem but we users will probably have to work directly with Vanguard to get this resolved. This has been an issue for several years.

Myrna Larson

I have the same problems. I have 3 accounts (taxable, IRA, trust) with at least 6 mutual funds in each. In December this means correcting ~36 transactions!

That would be reasonably easy if you could correct the transaction by simply clicking on the Action (which is ReinvDiv) and selecting ReinvLg or ReinvSh. But that doesn't work. Instead you have to click the Edit button. That opens the big investment transaction edit window where you have to transfer the shares and dollars from the Div line to the correct line. If anyone has an easier fix, I'd love to learn about it!

I agree this is basically a Vanguard problem. Maybe Vanguard would fix it if the request came from Intuit/Quicken, i.e. the corporation itself, rather than a few disgruntled Quicken users. Does Quicken monitor this forum for 'fixable' problems?

But my problem has not been limited to correcting 36 transactions! At least twice, this has corrupted my Quicken file! The modified transaction was entered twice: in the correct account, and ALSO in a CLOSED ACCOUNT, where it overwrote the final transaction there. That transaction happens to be one side of a transfer. That means go to a backup file to get the overwritten transaction, write it down, go back to the current file and reenter the transaction, and check whether the other side of the transfer is OK. (Surprisingly, Quicken lets me enter a transaction in a closed account.)

Quicken is at least responsible for this duplicate transaction issue. Before you say (as Quicken support always does) that my file must be corrupted, the only time Super Validation has shown an error is in this situation, i.e. correcting an investment transaction.

Also a Quicken user, since 1992, in the DOS days!

Jim_Harman

But my problem has not been limited to correcting 36 transactions! At least twice, this has corrupted my Quicken file! The modified transaction was entered twice: in the correct account, and ALSO in a CLOSED ACCOUNT, where it overwrote the final transaction there. That transaction happens to be one side of a transfer. That means go to a backup file to get the overwritten transaction, write it down, go back to the current file and reenter the transaction, and check whether the other side of the transfer is OK. (Surprisingly, Quicken lets me enter a transaction in a closed account.)

I have recently seen this same issue, exactly as described by @Myrna Larson. Unfortunately I do not have screenshots or the exact steps to document the problem, but basically editing the ReinvDiv to a ReinvLg caused a copy of the transaction to over-write the last transaction in a long-inactive, hidden account. The over-written transaction was an XOut and broke the transfer, leaving the final balance of the old account in place.