Help handling Restricted Stock Units for Foreign Stock
jrm
Member ✭✭
Windows 7 Quicken 2015R12
I have been tracking non-vested RSUs in Q since 2013. As I was just creating a "placeholder" for our overall financial picture, I didn't think too much about the implication of my methodology. I have lots of experience with Q's ISO functionality and knew that wasn't the method to go. Also, had done a quick search at the time, probably just in Q help, not in the community about RSUs.
I created a non-linked brokerage account. Created a security without a ticker and added single yearly "added" transactions to enter the quantity of RSUs received. In the memo, I added the information about availability date so I wouldn't lose track of it. In our case, 100% vests at the four year mark.
When a handful of shares were forfeited, due to underlying rules, I "removed" that number.
Fast forward to today when I started thinking about the picture not being reflected in Q.
The vest happened a few months ago and I decided it was time to play with them. I found a few great threads from year's past, and in particular, having been referring to this one...
https://getsatisfaction.com/quickencommunity/topics/how-to-handle-restricted-stock-units-in-quicken
I'm working in a Q copy and created a new non FI linked brokerage account. Created new security names for each RSU granted for ability to track; added in the appropriate RSU quantity and in the one case, removed the forfeited shares.
Then, my aha moment... our RSUs are a foreign holding. I figured out how to turn on multiple currency support and recreated a brokerage account to work with, so that I could change its currency type and reentered my transactions.
To help myself along, I "removed" the quantity of RSU shares that vested. I then, intitially added the same quantity of actual shares, therefore no cost associated. Sold a portion of those shares, generating cash and transferred the funds to the account in which I track tax dollars in the w2. (So far, I don't know how much actually went to federal vs state taxes, but I figure I can manage that once we have the detail report.)
I then went back to Tom's process in the above link and changed the "added" transaction to a buy transaction with the acquisition price, generating cash in my account. I still have the sold transaction to generate the tax w/h amount.
I have created a miscInc transaction, to generate the W2 income (using full number of shares + FMV) and created a category for its use.
In the RSU/Share account, I see the value appropriately in Euros. When I do a report on the income category to see how it will track, it has converted to dollars, but the amount doesn't reflect the same earning value that should up on a pay stub.
How do I get that to reflect accurately? When I had value going from the same account to the tax account I've set up, it gave me the option of overriding the conversion amount (which I in fact, haven't done yet in testing.) I did read about the currency conversion list, and I can see how to edit it, but that seems to be point in time, so I don't know that I can create something that give the conversion for a date in March, but something different for now.
Any help would be greatly appreciated. If I can't make the conversion to work, I'm thinking I might just leave out the MiscInc transaction, as I can track that differently when prepping taxes.
Anything else I might be leaving out in my thought process?
Thanks kindly!
ps. I also was checking out this thread https://getsatisfaction.com/quickencommunity/topics/does-quicken-2012-have-a-way-to-record-restricte..., but haven't tested if option accounts can work with foreign currency. Also, I suspect I'd have the same conversion issue.
I have been tracking non-vested RSUs in Q since 2013. As I was just creating a "placeholder" for our overall financial picture, I didn't think too much about the implication of my methodology. I have lots of experience with Q's ISO functionality and knew that wasn't the method to go. Also, had done a quick search at the time, probably just in Q help, not in the community about RSUs.
I created a non-linked brokerage account. Created a security without a ticker and added single yearly "added" transactions to enter the quantity of RSUs received. In the memo, I added the information about availability date so I wouldn't lose track of it. In our case, 100% vests at the four year mark.
When a handful of shares were forfeited, due to underlying rules, I "removed" that number.
Fast forward to today when I started thinking about the picture not being reflected in Q.
The vest happened a few months ago and I decided it was time to play with them. I found a few great threads from year's past, and in particular, having been referring to this one...
https://getsatisfaction.com/quickencommunity/topics/how-to-handle-restricted-stock-units-in-quicken
I'm working in a Q copy and created a new non FI linked brokerage account. Created new security names for each RSU granted for ability to track; added in the appropriate RSU quantity and in the one case, removed the forfeited shares.
Then, my aha moment... our RSUs are a foreign holding. I figured out how to turn on multiple currency support and recreated a brokerage account to work with, so that I could change its currency type and reentered my transactions.
To help myself along, I "removed" the quantity of RSU shares that vested. I then, intitially added the same quantity of actual shares, therefore no cost associated. Sold a portion of those shares, generating cash and transferred the funds to the account in which I track tax dollars in the w2. (So far, I don't know how much actually went to federal vs state taxes, but I figure I can manage that once we have the detail report.)
I then went back to Tom's process in the above link and changed the "added" transaction to a buy transaction with the acquisition price, generating cash in my account. I still have the sold transaction to generate the tax w/h amount.
I have created a miscInc transaction, to generate the W2 income (using full number of shares + FMV) and created a category for its use.
In the RSU/Share account, I see the value appropriately in Euros. When I do a report on the income category to see how it will track, it has converted to dollars, but the amount doesn't reflect the same earning value that should up on a pay stub.
How do I get that to reflect accurately? When I had value going from the same account to the tax account I've set up, it gave me the option of overriding the conversion amount (which I in fact, haven't done yet in testing.) I did read about the currency conversion list, and I can see how to edit it, but that seems to be point in time, so I don't know that I can create something that give the conversion for a date in March, but something different for now.
Any help would be greatly appreciated. If I can't make the conversion to work, I'm thinking I might just leave out the MiscInc transaction, as I can track that differently when prepping taxes.
Anything else I might be leaving out in my thought process?
Thanks kindly!
ps. I also was checking out this thread https://getsatisfaction.com/quickencommunity/topics/does-quicken-2012-have-a-way-to-record-restricte..., but haven't tested if option accounts can work with foreign currency. Also, I suspect I'd have the same conversion issue.
0
Comments
-
Have you considered using another account to act as the "conversion" account? You would transfer the euros in from the RSU proceeds, make the specific euro to dollar conversion needed to get the correct dollar amount, and transfer out the dollars. .
Quicken user since Q1999. Currently using QW2017.
Questions? Check out the Quicken Windows FAQ list0 -
I had not considered that. Thanks for raising it. I will give that a run in my testing. Based on my experience in seeing that when I transfer from one currency in an account to a different currency in another account, I can specify the specific conversion. It seems that while it creates an extra account for me, that it just might be the way to get my dollars to reflect accurately.
Thanks.0
This discussion has been closed.