Gain / Loss Determination Not Consistent Between Accounts

JoelC

I have a problem in one of my trading accounts in determining the gain / loss on a security as follows:

1. I own the security BNS Tiered Investments Savings Account 6001 [let's call it "6001"] in 5 different investment accounts (i.e., personal x 2, corporate x 3, and registered). It is a USD money market account where cash is parked overnight to earn interest.

2. 6001 always trades at USD 1.00 per unit.

3. 6001 in 4 of my trading accounts shows the Market Value = Cost Basis as it should since it only trades at USD 1.00 with an example being as follows:

4. 6001 in the 5th account (which is one of two corporate accounts), shows the Market Value < Cost Basis which should not be the case as it always trades at USD 1.00. The problem is illustrated here:

5. I cannot determine / find the cause of this problem as:

a) It is the same security held in 5 accounts meaning the cause cannot be an incorrect unit value as the problem would appear across all accounts as the unit values are global / shared among all accounts.

b) As the Shares = Market Value = On-line Share Count there is no transaction where I entered the incorrect number of units.

I would very much like to get this anomaly fixed and would appreciate any ideas / input anyone has.

Thanks in advance.

volvogirl

You probably need to look at the individual purchases for that Account and the price on the purchase transactions.

JoelC

@volvogirl appreciated. I have and can find not a one that is offside.

JoelC

@volvogirl as an update to your above suggestion I manually reviewed each and every transaction with respect to 6001 and can confirm that each one was properly entered. I am baffled.

The only idea I have is to created a duplicate file and delete each transaction one at a time until the problem is found and then revert to the original fine to correct.

Would love another approach to find the problem.

++++++++++++++++++++++++++++++++++++

The other solution — which does not fix the problem — is to simply sell all of 6001 and repurchase all of 6001 BUT this means the gain / loss report will be inaccurate.

JoelC

**** UPDATE ****

I had some time this morning so I decided to dig deeper into the problem and am now more confused than ever.

1. I started by creating a report of all 6001 transactions in the "problem account" which resulted in the following:

2. I then deleted the transactions from newest to oldest (i.e., 2024-07-21 → 2024-07-21 → 2024-07-19 → 2024-07-02….) until I deleted / found the transaction that was creating the problem (i.e., deleted the transaction which returned to Gain / Loss = 0).

3. When I deleted the transaction dated 2024-04-10 the Gain / Loss for 6001 was zero. I then tried to re-enter the transaction and the Gain / Loss problem reappeared! How is this possible? What is going on?

4. When I looked at the transaction entry I could find nothing wrong with how I entered the transaction which is as follows:

Does anyone have any ideas / thoughts on how to solve this problem?

Thank you.

Chris_QPW

Try this (long shot), in the problem account make sure you are in the date field and then type Shift+Ctrl+z. And select OK for Quicken recalculating the transactions.

JoelC

@Chris_QPW , as always I appreciate the suggestion but no joy, the problem was still there.

mshiggins

" It is the same security held in 5 accounts meaning the cause cannot be an incorrect unit value as the problem would appear across all accounts as the unit values are global / shared among all accounts."

True.

But it doesn't appear that your problem is with the number of units, or the current price/share. It appears your problem is with cost basis being incorrect; suggesting that in one or more transactions, the price/share was not $1.00.

If you click the + sign to the left of your security name (as shown in your screenshot) to display all the lots for the security, are there any lots where the price/share is NOT $1.00?

"4. When I looked at the transaction entry I could find nothing wrong with how I entered the transaction which is as follows: ...."

Some thoughts:

Is the account in question an account with securities that are (or can be) denominated in different currencies?

That type account is not available in the U.S. version of Quicken, so I have no way to test the effect of supplying an exchange rate to an individual security transaction.

Is your treatment of exchange rate consistent for all the transactions for the problem security in the problem account?

If I recall, Quicken Canada retains an exchange rate history: is that exchange rate history correct?

-JP

JoelC

@mshiggins

If you click the + sign to the left of your security name (as shown in your screenshot) to display all the lots for the security, are there any lots where the price/share is NOT $1.00?

No there are no as exemplified by the following screenshot (i.e., there is only 1 lot):

Is the account in question an account with securities that are (or can be) denominated in different currencies?

No, the problem has now migrated to accounts that are denominated in CAD!

I am open to other ideas else I fear I will need to call Quicken which likely will not solve the problem other than a commitment to look into it! Sign! :(

volvogirl

You bought or acquired 112.83 shares? But it shows the cost basis is $411.31 which is not $1 per share on 112.83 shares.

JoelC

@volvogirl

You bought or acquired 112.83 shares? But it shows the cost basis is $411.31 which is not $1 per share on 112.83 shares.

Exactly that is the problem I am looking for assistance with because the Lot clearly shows the price as $1 / share!

volvogirl

Then you need to look at the actual purchase transaction and all the details like cost. Did you try deleting the purchase and re enter it?

JoelC

@volvogirl I appreciate your assistance but as noted in this thread, I have already done all of that including manually checking each entry. There is no indication of any transaction that is entered at a stock price that is not $1 / share.

mshiggins

" ... because the Lot clearly shows the price as $1 / share!"

And it also shows that a lot with a $1/share price and 112.83 shares owned has a cost basis of $0.00 and a market value of $0.00.

Maybe I'm missing something, but that should be impossible.

[I'm having trouble keeping track of the accounts/lots involved. I that 112.83 share lot the same lot shown in point #4 in your original post in this discussion? The shares don't match - maybe I'm missing something.]

I tried fooling around with showing/not showing closed lots, but could not reproduce the problem.

I tend to think there is some corruption involved, and I wouldn't bet that Quicken can find it, or fix it. But I don't think it could hurt to try.

You could make a Quicken Copy of your file for testing - all accounts will be deactivated for downloading, but that should not affect testing for your problem.

In that test Copy, try doing a Super Validate and telling Quicken to "rebuild investing lots" and "correct investing price history".

If problem still exists, try deleting the apparent problem transaction, and repeat the step above. Then add the problem transaction back.

If problem still exists, try deleting all the price history for the security in question (*), then repeating the Super Validate.

If nothing works, I would use Help > Report a problem to inform the Quicken developers. They should have the tools to determine the cause of the problem. While you are unlikely to get any response, and it may take a while for a solution to released, at the end of the day I think that's the most likely way to get the problem addressed. 

But also feel free to contact Quicken Support, perhaps Quicken already has some knowledge of this issue.

[ (*) Select the security in the Security Detail View. Click the "More" button and select "Edit price history". In the resulting price history list, you can select multiple prices as you would select multiple files in Windows

Explorer, then click the Delete button to delete all the selected prices.]

-JP

JoelC

@mshiggins , appreciate the continued help and in response note the following:

Maybe I'm missing something, but that should be impossible.

Agreed, this is part of conundrum and problem!

I'm having trouble keeping track of the accounts/lots involved. I that 112.83 share lot the same lot shown in point #4 in your original post in this discussion? The shares don't match - maybe I'm missing something.

All good and you are missing nothing noting:

1. The same problems appear in the lots shown in Point # 4 of my original post; and
2. The lot shown in with the $112.83 was used to demonstrate the spread to other accounts and because there is only 1 lot.

I tend to think there is some corruption involved, and I wouldn't bet that Quicken can find it, or fix it. But I don't think it could hurt to try.

Agreed, and this is my fear!

You could make a Quicken Copy of your file for testing - all accounts will be deactivated for downloading, but that should not affect testing for your problem.

In that test Copy, try doing a Super Validate and telling Quicken to "rebuild investing lots" and "correct investing price history".

Agreed. I will try this later today and report back. I just need to find how to do a Super Validate. It should not be too hard to find on the net.

If problem still exists, try deleting the apparent problem transaction, and repeat the step above. Then add the problem transaction back.

If problem still exists, try deleting all the price history for the security in question (*), then repeating the Super Validate.

If nothing works, I would use Help > Report a problem to inform the Quicken developers. They should have the tools to determine the cause of the problem. While you are unlikely to get any response, and it may take a while for a solution to released, at the end of the day I think that's the most likely way to get the problem addressed. 

I will try the suggested solutions over the next few days time permitting.

Fingers crossed!

JoelC

UPDATE

@mshiggins , I ran Super Validate with telling Quicken to "rebuild investing lots" and "correct investing price history". The results were:

a. It fixed the problems in all accounts but one (good).

b. The one not fixed account has the same problem.

Comments / thoughts / suggestions?

JoelC

UPDATE

I dug into the individual transaction in the account that still had a problem and noticed teh following:

a. When I deleted one specific transaction the problem went away.

b. When I added back that specific transaction the problem reappeared.

The transaction is as follows:

Any comments / thoughts as to what the problem is or what I should try differently (i.e., another day perhaps)?

Thanks,

JoelC

**** UPDATE ****

Following on my above idea of moving the transaction to another date I noticed the following:

a. Moving the transition backward in time did not solve the problem (i.e., market value <> cost basis, and gain / loss <> 0).

b. Moving it forward from July 10 to any date on or before July 18 did not solve the problem (i.e., market value <> cost basis, and gain / loss <> 0).

c. Moving it forward to July 19 or any date thereafter fixes the problem (i.e., market value = cost basis, and gain / loss= 0).

Any comments / thoughts / ideas as to what is going on?

q_lurker

Late to the storyline here.

b. When I added back that specific transaction the problem reappeared.

Thoughts in no particular order also noting your date change tests -

Did you close and reopen Quicken before adding back that specific transaction?

Did you try the Copy File and possibly validate process before adding back that specific transaction? The copy process generally is thought to truly delete deleted records,

If you add back a slightly different or very different version of that same transaction type, does the same symptomatic behavior show?

If you insert a different type of transaction followed by the correct one, does the problem recur?

JoelC

@q_lurker

As a seat i) apologies for the delayed response but I spent the weekend away from all screens as I needed a break and ii) thank you for your suggestions.

I have now tested / tried all of your suggestions and note:

Did you close and reopen Quicken before adding back that specific transaction?

I tried this one of the accounts with the problem and it has fixed / solved the problem I will try it on the other accounts later today and revert.

If it does not work on the other accounts then I will try the other recommendations.

Thank you.

JoelC

@q_lurker

I tested the other two accounts that had the problem and note the following:

a) Unfortunately none of the recommendations you suggested worked for the other accounts with the same problem.

b) The best work around I was able to find was on the day / transaction that causes the problem, sell and the purchase the exact amount of shares for said transaction and then all is good! Weird for sure.

Comments / thoughts?

mshiggins

"c. Moving [the transaction] forward to July 19 or any date thereafter fixes the problem (i.e., market value = cost basis, and gain / loss= 0)."

I can only think of one condition that might explain that: the account contains a Placeholder for the problem security, dated July 18.

[A Placeholder will guarantee that the shares held of a security in a Quicken account will always be a specific quantity on the date of the placeholder.]

To locate placeholders, first go to Preferences > Investments and make sure there's a check mark in "Show hidden transactions".  Then in the account in question, look for transactions with an Action value of "Entry" (sorting on the Action column may help).

If you have a placeholder, you'll want to try to determine why a placeholder was needed. It could be caused by missing, extra, or incorrect non-placeholder transactions. Then you can decide what to do with the placeholder.

If you're able to eliminate the placeholder (or give it a more friendly date), you should then be able to change the data of your problem transaction to the correct data.

[I confess I can't explain how a placeholder would produce the problem I understand you to be trying to solve; but a placeholder is the only way I can explain why your transaction works only after being given a later date.]

-JP

JoelC

@mshiggins as always, I appreciate the help and suggestion.

I checked — per your instructions — and there were no transactions with an Action Value = "Entry".

I checked all accounts that have this problem and none had such a transaction. :(

Comments / other ideas / thoughts as I woudl like to get this solved.

JoelC

I am still struggling with this bug / issue.

I am wondering whether anyone has any other ideas or whether I need to call Quicken which I suspect will not be helpful.

Thank you.

q_lurker

Is the problem still with the one account with an exchange rate consideration - your point 4 in the original post? It seems other problems in other accounts have come and gone, but I am not sure about that.

I was recently helping another user with an issue in the Portfolio Values views where some Cost Basis inaccuracies appeared oddly. The solution necessary there was to ensure that all Sales of the security had the lots definitively specified, not relying on the default FIFO specification. Details in that case do not match up with yours, but it might be worth trying. For each SALE, edit the transaction, specify lots button, select the actual lot being sold, Accept the edit. This should not be necessary, but it was in that case.

By the way, I found that solution for that case by individually and manually replicating the poster's transactions in a new independent file. No other securities were required. Only one account with 20 or so transactions.

Unless you can somehow replicate your problem in some fashion, I suspect a call toe Quicken support will not be helpful.

JoelC

@q_lurker appreciate the follow up.

The problem currently exists in a CAD investment account so there is no f/x issue.

With respect to calling Quicken I concur. The experience I have had to date with the problems I have discovered and can replicate is that they take forever to fix despite being with engineering (i.e., some are getting close to being 9 months old).

Will call with fingers crossed.

JoelC

Quick update, I have not yet had teh time to call Quicken but hope to do so over the next day or two. I will provide a further update at that time. This really has me baffled.