Share balance of fund in retirement account is truncated

VTQuickUser

Quicken Deluxe 2020 R25.18 Build 27.1.25.18 USA
Windows 10 Home Version 1903 Build 18362.657 64-bit

Hi,

I have a "Retirement Account" in Quicken which is my 401k. Within the account there are five funds. I download transactions using "Direct Connect".

When comparing the share balance of each fund with the balance shown on my employer's website, I noticed that the balance of one of the funds was incorrect. I've traced the problem to a SoldX transaction that occurred on 4/18/2019 for .072316 shares. The share balance on 4/16/2019 (the date of the previous transaction) was 7096.072409. The share balance after the SoldX transaction on 4/18/2019 should be 7096.000093 (i.e., 7096.072409 less .072316), but it erroneously shows as 7096. That error has carried forward so that the share balance of this fund is still off by .000093 today.

I tried deleting the transaction and re-entering it manually but the error persisted.

I believe the issue is with the small value to the right of the decimal place in the share balance. I can replicate the problem by taking the share balance today (7519.937477) and creating a SoldX transaction of .937384 that should bring the balance down to 7519.000093. When I enter this transaction, the share balance incorrectly shows as 7519, so Quicken is truncating the share balance in the same way it did on 4/18/2019. A little testing shows that a transaction that brings the share balance down to 7519.0001 is handled correctly and the share balance is correct, while a transaction that brings the balance down to 7519.000099 results in a truncated share balance.

I reported this issue via a phone call on 2/28/2020 (Case number 7445986). The representative understood the issue but didn't have a solution. He said I would receive a follow-up email but I haven't received anything.

Has anyone else seen this behavior? Any idea on the best way to correct the share balance of my fund?

Thanks,
Don

Quicken_Natalie

Hello @VTQuickUser,

Thank you for your patience while this was being researched.

I have gone ahead and reported this behavior and a Bug Ticket has now been opened. 

There is currently no ETA on a resolution, however, I will be sure to post back with any updates as they become available.

Thank you,

Quicken Natalie

CTP-646

Quicken_Natalie

Hello @VTQuickUser,

Thank you for taking the time to visit the Community and post your issue, although I apologize that you have not yet received a response.

It appears that Quicken only supports fractional share entries/balances up to 6 decimal places.

Based on the description you've provided here, I believe this is the cause of the behavior that you're experiencing, as the entries with 6 decimal places or less appear to record accurately, whereas the entry with 7 decimal places appears to round to the nearest whole number.

Hope this helps!

-Quicken Natalie

NotACPA

@Quicken_Natalie,

That doesn't quite explain the situation ... as 7096.072409. IS only 6 decimal places (6 places to the right of the decimal point).

Quicken_Natalie

Hello @NotACPA & @VTQuickUser,

My apologies, I miscounted. 

I will do a bit more research on this and report back if I find any other potential culprits that may be causing this. 

Thank you,

Quicken Natalie 

Quicken_Natalie

Hello @VTQuickUser,

I suggest checking for and resolving any placeholder transactions, utilizing the information outlined here.  

Please let us know if this helps to resolve this matter for you.

Thank you,

Quicken Natalie

VTQuickUser

Hi @Quicken_Natalie,

Thanks for your reply.

I created a new 401k investment account containing one security and gave it an opening balance of 7096.072409 shares. I then entered a SoldX transaction for .072316 shares. The share balance incorrectly became 7096 shares, when it should be 7096.000093.

Can you try this and see if you get the same results? If you do, I think the problem clearly has something to do with how Quicken is handling the SoldX transaction.

I can try to resolve the placeholder entries in my existing 401k account (there are two) as you suggested, but the fact I created a brand new account and still saw an incorrect share balance leads me to believe the placeholder entries in my existing account are not the cause of this problem.

Thanks,
Don

Quicken_Natalie

Hello @VTQuickUser,

Thank you for doing some additional testing and posting back with more information regarding this.

I am seeing the same behavior in Quicken when following the outline you've provided here. I did some additional testing with the level of the fractional share being "sold" and determined that Quicken only began to truncate the number when four zeros were in place after the decimal point.

I am going to do some additional research on this and will post back with more information as soon as it becomes available. 

Thank you,

Quicken Natalie

NotACPA

@Quicken_Natalie,

We might have another example of the topic of this discussion: https://community.quicken.com/discussion/7871865/why-cant-i-reconcile-investment-tranactions-to-more-that-4-digits-after-decimal#latest

VTQuickUser

@Quicken_Natalie ,

Thanks for your reply. I'm glad you're seeing the same results as me, at least that gets us one step closer to a solution. It also sounds like @NotACPA has found a post where someone seems to have the same issue I do.

So far I haven't found a way to fix this. I tried entering an "Adjust Share Balance" transaction but when I entered the current share balance from my employer's website (which differs from the balance in Quicken by .000093), a Placeholder transaction was created for 0 shares and the share balance didn't change.

I also tried selecting the Gear Menu and choosing "Update share balance" but entering the current share balance resulted in a message saying "No Adjustment Required" and no transaction was created.

What happens next? At what point is this recognized as a bug (if it in fact is one) and submitted to the developers to be fixed programmatically?

Thanks,
Don

NotACPA

@VTQuickUser,

It's possible that Natalie will come up with a workaround ... but given the nature of the problem (unintended truncation somewhere within Q), I don't see an option other than waiting until a fix is released in a future product update.

q_lurker

@VTQuickUser :  Don't know if this will be helpful or not.

My policy is to manage all fractional shares to 3 decimal point precision (0.001 shares).  That seems to match what Vanguard (my prime but not sole fund group) does as well.  Any Buy/Sell/Reinvest transaction is shares to that precision and total dollars to the penny.  I never rely on price/share as a user input always letting Quicken vary the price/share accordingly.  As such, I would never fall into this hole you've unfortunately discovered.  

On the chance that you could go back and edit old transactions to a lesser precision (some users use 4-digit precision), that would be the work-around or correction I might offer.  

VTQuickUser

Hi @NotACPA ,

I agree that this seems like an issue that will need to be solved by a fix implemented by Quicken. I have no prior experience with something like this, maybe you do? Will Natalie confirm that this problem has been submitted to the developers for a solution? And once it's submitted, will I be able to track the progress of the problem and possibly be notified when a fix is issued? Or do I just have to read the Release Notes of each Quicken release and look for the resolution to my problem?

Thanks,
Don

NotACPA

@VTQuickUser

Q doesn't release info about product updates (incl bug fixes) until JUST before they're released.

I don't see that this is SO critical that they'll make an exception for this.  I.E., there's no way to track the issue other than by "staying tuned" here to see if further info is forthcoming.

VTQuickUser

Hi @q_lurker ,

Thanks for your suggestions. I don't think this would work for me because I have seven years of transactions in this account so going back and modifying old transactions would be a time-consuming process. Also, the fund company from which I download transactions maintains shares to 6 decimal places so if I round the transactions in Quicken to 3 or 4 decimal places, my Quicken share balance will not match that on the fund's website, and that's the very issue I'm trying to resolve.

Thanks,
Don

VTQuickUser

Hi @NotACPA ,

Thanks for this information. I guess all I can do now is wait to hear back from @Quicken_Natalie about whether she's found a fix and if not, then whether this issue will be added to the list of bugs to be fixed.

Don

Quicken_Natalie

Hello @VTQuickUser,

Thank you for your patience while this was being researched.

I have gone ahead and reported this behavior and a Bug Ticket has now been opened. 

There is currently no ETA on a resolution, however, I will be sure to post back with any updates as they become available.

Thank you,

Quicken Natalie

CTP-646

VTQuickUser

@Quicken_Natalie ,

Thanks for following up on this. I'll keep watching for a resolution.

Don

NotACPA

NotACPA said:

@VTQuickUser,

It's possible that Natalie will come up with a workaround ... but given the nature of the problem (unintended truncation somewhere within Q), I don't see an option other than waiting until a fix is released in a future product update.

In a way, this truncation is similar to the Y2K issue.  In that a frequent solution (in my opinion the best, but not the simplest solution) is to expand ALL "# of shares" fields so that they all hold 6 digits.

BUT, this could be a complex research project and could require database and/or screen changes.

OR, it could be as simple as someone did a "round to 4 decimals", which would be much easier to fix ... once it's  found.

SO, hang on.  It might be a while before this gets fixed.