nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

GE did a reverse 8-1 split after close of business 7/30. Typical "Quicken" split problems arise.

Tom Young

As usual the reverse split of the stock and the adjustment of prices and volumes to post-split figures downloaded into Quicken doesn't jibe with reality, requiring some editing of the price history for the stock for a period of time before the split.

For whatever reason Yahoo Finance has NOT made the split adjustment for the period of July 19 - July 30, i.e., they are showing the old "before split" numbers, but have adjusted everything for dates before the 19th.

This makes it relatively easy to correct the incorrect downloaded information in Quicken which roughly uses those same dates. I expect that the Yahoo numbers will be changed fairly soon to the post split figures, so act fast.

Find more posts tagged with

Accepted answers

All comments

Boatnmaniac

@Tom Young - This morning during OSU the split transaction was downloaded showing it is effective with today (which is correct).

But the share prices were updated to show the adjustment took effect on 7/26, which I do not think should have happened because the split had not yet occurred. Why do you think the higher share prices should precede the actual reverse split?

The increased share prices preceding the actual reverse split caused my account balance and net worth for 7/26-8/1 to be overstated by a 6-digit figure. So, I ended up deleting the downloaded split transaction and the 7/26-7/30 prices.

Fidelity.com shows the split pending download for later today. When I run OSU this evening I'm hoping both the split data and the prices will be correct.

Tom Young

"This morning during OSU the split transaction was downloaded showing it is effective with today (which is correct). "

Yes, I know. That split actually happened after close of business on Friday, Monday is the first time you see the effect.

"But the share prices were updated to show the adjustment took effect on 7/26, which I do not think should have happened because the split had not yet occurred."

Yes. That's the problem.

"Why do you think the higher share prices should precede the actual reverse split?"

I don't. But again and again we see these sort of mistakes around the time of splits.

"The increased share prices preceding the actual reverse split caused my account balance and net worth for 7/26-8/1 to be overstated by a 6-digit figure. So, I ended up deleting the downloaded split transaction and the 7/26-7/30 prices."

Now you need to get the correct High/Low/Close shares prices for those days and the correct (pre-split) volume loaded into Quicken. I don't think I've ever that happen automatically as historical prices are Qucken-supplied. So the post had two points:

Same-old, same-old Quicken problems surrounding splits
Yahoo, for whatever reason, has the old pre-split information for a period shortly before the split occurred which makes it relatively easy to fix things manually in Quicken, and I'm guessing this information will go away at some point.

Rocket J Squirrel

Yup. This split/price/timing issue virtually always occurs when a stock splits. The only thing it seems to affect is a couple days' prices, so I no longer chase these down and try to fix them.

I had an interesting split recently. IHI split 6:1 a few weeks ago, but what I got downloaded was a 1:0.166667 split, i.e., introducing roundoff error when no rounding was needed. Easily fixed, of course.

Boatnmaniac

Tom Young said:

"This morning during OSU the split transaction was downloaded showing it is effective with today (which is correct). "
Yes, I know. That split actually happened after close of business on Friday, Monday is the first time you see the effect.
"But the share prices were updated to show the adjustment took effect on 7/26, which I do not think should have happened because the split had not yet occurred."
Yes. That's the problem.
"Why do you think the higher share prices should precede the actual reverse split?"
I don't. But again and again we see these sort of mistakes around the time of splits.
"The increased share prices preceding the actual reverse split caused my account balance and net worth for 7/26-8/1 to be overstated by a 6-digit figure. So, I ended up deleting the downloaded split transaction and the 7/26-7/30 prices."
Now you need to get the correct High/Low/Close shares prices for those days and the correct (pre-split) volume loaded into Quicken. I don't think I've ever that happen automatically as historical prices are Qucken-supplied. So the post had two points:
Same-old, same-old Quicken problems surrounding splits
Yahoo, for whatever reason, has the old pre-split information for a period shortly before the split occurred which makes it relatively easy to fix things manually in Quicken, and I'm guessing this information will go away at some point.

Thanks for clarifying. I misunderstood your original post to mean that you think the inflated prices reflecting the pending split were OK. My bad. We agree that they are not OK.

Regarding getting the correct historical prices downloaded: I don't know exactly where they come from but I have found that deleting the bad historical prices allows Quicken to enter new prices for those dates and usually within a few days the correct prices will be populated. Unfortunately I might need to delete those bad prices for a few days until good prices finally do get downloaded.

q_lurker

Boatnmaniac said:

...
Why do you think the higher share prices should precede the actual reverse split?
...

I don't think they should either. But to change your question ...

Why do you think the higher share prices DO precede the actual reverse split?

My opinion is that this reflects the trading vs settlement date. Example: If you initiate a trade on Thursday (pre-split) that closes on Tuesday (post- split) that is a trade for the post split shares (I believe). You say on Thursday you are selling 8 shares at $12.50. On Tuesday the transaction closes with you selling 1 share at $100. So the price source reports the Thursday price at the post-split level and treats the split as occurring before it actually did. The price-history info will also contain a split record. Again, my opinion only. I have never received any validation of that idea.

Boatnmaniac

q_lurker said:

Boatnmaniac said:

...
Why do you think the higher share prices should precede the actual reverse split?
...

I don't think they should either. But to change your question ...

Why do you think the higher share prices DO precede the actual reverse split?

My opinion is that this reflects the trading vs settlement date. Example: If you initiate a trade on Thursday (pre-split) that closes on Tuesday (post- split) that is a trade for the post split shares (I believe). You say on Thursday you are selling 8 shares at $12.50. On Tuesday the transaction closes with you selling 1 share at $100. So the price source reports the Thursday price at the post-split level and treats the split as occurring before it actually did. The price-history info will also contain a split record. Again, my opinion only. I have never received any validation of that idea.

Interesting theory. I'll need to spend some time thinking about this some more before commenting on it.

But this morning has been "interesting". Fidelity downloaded the split as a $0 Sell of all 2192 pre-split shares and a $0 Buy of 274 post-split shares with both transactions dated 8/2. Why they didn't simply download it as a Split transaction is odd but in theory it should work, right?

However, Quicken now shows I now hold the 2466 combined total of the 2192 pre-split shares plus the 274 post-split shares so the GE shares value is way overstated as is the total account balance. And, of course, Quicken suggests that a Placeholder be generated to address this issue.

I double checked the transactions to make sure they were entered properly and found no errors. Since the transactions are correct, this issue should shares count issue not be occurring in Quicken. I don't think I've ever seen this happen before.

I ended up deleting the Buy and Sell transactions downloaded by Fidelity and manually entered a 1-for-8 reverse Split transaction and everything now balances out correctly but I'm still just scratching my head on this one.

Tom Young

"Why they didn't simply download it as a Split transaction is odd"

Since a StkSplit action actually kicks off the stock split "wizard" that requires split information to be entered in a new window, Fidelity (or any FI) has no choice but to try and reflect the split in a series of simple transactions. Seems like the "more" proper transactions to use would be Removes and Adds as opposed to a Sold.

Jim_Harman

Here is what Quicken and Vanguard downloaded this morning 8/3 for this split. I did not do an OSU yesterday.

At the end of my OSU, I got "Stock splits may be missing" dialog, showing GE 1:8 on 8/2. I accepted this.

When I went to the Vanguard account, I got a Security match dialog for "GE New". I selected my existing GE security and accepted the match

The downloaded transactions were:
-- Remove xxx shares GE @$0.00
-- Add yy shares GE @0.00
-- Deposit $25.41
-- Buy Federal MM (Settlement fund) $25.41

Before accepting any transactions, the Holdings view showed yy.25 shares of GE

The first 3 transactions are clearly wrong so I deleted them before accepting.

I entered a sale of 0.25 sh GE for a total of 25.41
I accepted the buy of the settlement fund.

Looking at the Security detail page for GE, with the Split adjust box checked, there is a big jump for 7/26 - 7/30. I deleted those prices and everything looks good now.

Moral: Do not blindly accept downloaded transactions, make sure you know what is going on and make adjustments as needed.

Boatnmaniac

The issue I noted in my last post (incorrectly combining the Sell and Buy quantities) bugged me so much that I opened a test file I'd previously set up and did OSU there. The same Sell and Buy transactions downloaded but this time Quicken managed the transactions properly with only the correct post-split share quantity showing in current Holdings.

I then opened up my main data file, again, and ran Validate & Repair on it but no issues were found. So, I'm still scratching my head about what originally happened in this file.

Getting back to the Share prices: In the test file post-split prices were incorrectly downloaded for 7/28-7/30 when they should have been pre-split prices. In the main file the post-split prices were previously incorrectly downloaded for 7/26-7/30 so it looks like this price issue slides out with each passing day. I'm guessing that if we were to download prices 3 days from now, all the prices for 7/26-7/30 will be the correct pre-split prices but I'll have to remember to check that out then to see if my assumption is correct. It still then begs the question of why are post-split prices getting downloaded before the split occurred. Something is broken somewhere.

q_lurker

Tom Young said:

"Why they didn't simply download it as a Split transaction is odd"
Since a StkSplit action actually kicks off the stock split "wizard" that requires split information to be entered in a new window, Fidelity (or any FI) has no choice but to try and reflect the split in a series of simple transactions. Seems like the "more" proper transactions to use would be Removes and Adds as opposed to a Sold.

I disagree. I don't see the "StkSplit action" kicking off a wizard. The transaction can be entered either in-line in the transaction list, or through the Enter Transactions button. The OFX specifications include a SPLIT transaction directly intended to identify splits for stocks and mutual funds. As far as I can see, the data is complete with respect to Quicken generating a StkSplt transaction, noting that Quicken considers the price optional for the StkSplit transaction.

I have not delved back into the OFX logs to see what my FIs have sent recently for stock splits,

Tom Young

"I have not delved back into the OFX logs to see what my FIs have sent recently for stock splits, "

I've had a few stock splits occur over the year and I don't think I've ever seen a downloaded SPLIT transaction. Schwab's download for the GE reverse split was a Remove and Add series.

M.A. Jebens

Yesterday, General Electric (GE) did an 8:1 reverse stock split. If I had 800 shares at $13/share as of last Friday, after the split, I now had 100 shares at $104/share. Quicken picked up the split on the data feed. When I looked at the Investing tab, Quicken gave me a loss (in the "Day Gain/Loss") of 7 times the total GE investment amount (in addition to the normal daily gain/loss I expected). The "Price Change" column is also wrong. It does not matter if I update the Stock Split transaction to enter data into the optional New Price field. It appears that it is using the old number of shares at the new price to compute the previous day's value.

I have seen this issue on previous versions with other stock splits. I am using version R34.24 with Windows 10.

Is there a workaround for this?

Ps56k2

I usually just wait a couple of days to let the Stock Price history catch up and then, if still bad - fix things.

M.A. Jebens

> @Ps56k2 said:
> I usually just wait a couple of days to let the Stock Price history catch up and then, if still bad - fix things.

Great! How do you fix things? I see now that in the INVESTING tab before the split, the number of shares is correct but the prices are eight time the value back then. How do I fix the prices for every trading day going back in history?

Tom Young

@M.A. Jebens

"How do I fix the prices for every trading day going back in history?"

Typically it's just a few days before the split date that get messed up. Look at that security's price history and that's what I'd expect you'd see. If Yahoo Finance hasn't changed the presentation mentioned in the opening post all the information should be right there.

Ps56k2

look at the brokerage register and the recent "split" transaction -

Was it entered as a Split or just Shares Added/Removed - my recent NVIDIA was bad, had to delete & enter the Split

Also, go look at the GE stock Security Detail View register....and see how things are reflected there....

look at the ... Price History ... More --> Edit Price History - again I had to fix the numbers as they were off a few days.

M.A. Jebens

> @Ps56k2 said:
> look at the brokerage register and the recent "split" transaction -
> Was it entered as a Split or just Shares Added/Removed - my recent NVIDIA was bad, had to delete & enter the SplitAlso, go look at the GE stock Security Detail View register....and see how things are reflected there....look at the ... Price History ... More --> Edit Price History - again I had to fix the numbers as they were off a few days.

Thanks! That was exactly what I needed. The Security Detail View showed that the price changed a week before the stock split transaction. I just changed the split date to coincide with the price change and everything was correct.

Ps56k2

M.A. Jebens said: The Security Detail View showed that the price changed a week before the stock split transaction. I just changed the split date to coincide with the price change and everything was correct.

it seems like the price gets messed up ahead of the actual split -

when it is pre-announced and the price quote download seems to pick up that pre-date vs the actual date.

Also - you might keep the actual split date - and just fudge the prices to make everything seem ok, so things don't get confused or flagged as an error for "split dates" in the future.

Boatnmaniac

I deleted the remaining bad GE share prices for last week and then downloaded historical prices from the Security Detail View for GE. All share prices for last week are now correct (i.e., pre-split actual prices).

Since I'd previously deleted the Fidelity-downloaded Sell/Buy transactions (which, BTW, shows in my Fidelity online account as Delete/Add transactions) and entered a Split transaction for 8/2 to replace them, all now looks good in Quicken, again.

Jim_Harman said:

When I went to the Vanguard account, I got a Security match dialog for "GE New". I selected my existing GE security and accepted the match

I meant to comment on this earlier. What originally brought the Reverse Split pricing issues to my attention was this "GE New" security, as well. The Sell transaction downloaded from Fidelity was for "GE", not "GE New". The Buy transaction downloaded was for "GE New", not for "GE". I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this. Of course, I do not really know this but it does make some sense. Anyway, when I deleted the Sell/Buy transactions and replaced it with the Split transaction, the "GE New" security disappeared from my Security List. And things started falling into place, again, with new price downloads all being entered against just "GE". I guess I'll just have to wait until the next split for me occurs to see if this "guess" plays out the same way with it.

@M.A. Jebens - I agree with @Ps56k2 . If you want your GE investment data to be accurate, you should keep the split date as 8/2.

If you still have the Delete/Add transactions for this split, you might want to also delete those 2 transactions and replace them with a Split transaction for 8/2. I have found that Delete/Add (or in my case, the Sell/Buy) transactions will often mess up the cost basis of the investment. Doing a Split transaction retains the Cost Basis.

Then delete the bad GE prices for last week followed by manually downloading the Historical Prices. Of course, it is a personal choice as to whether or not to do that and if you are OK with your Quicken file showing the split occurred a week before it actually did and are not concerned with tracking Cost Basis, then just leave it the way you currently have it. If your investment account is a retirement account, then accuracy on all this really does not matter anyway because there is no tax impact.

Tom Young

" I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this."

No, GE now has a new CUSIP number. 369604 301

q_lurker

Tom Young said:

" I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this."
No, GE now has a new CUSIP number. 369604 301

If that is the case, those wanting to keep it as one security will need go through the uncheck the “Matched …” box and rematch the new with the old.

Boatnmaniac

Tom Young said:

" I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this."
No, GE now has a new CUSIP number. 369604 301

Yes, I apparently messed up on my assumption to a degree. But it does appear that there were a series of changes made to the GE securities that were made over the past week or so. Previously all my GE holdings were under 369604103 but now everything is under 369604301. It seems likely that the share prices and what was getting downloaded were pretty caught up in that conversion process.:

Pre-split (sometime in June):

On the Split day (8/2):

Today (8/4):

q_lurker said:

Tom Young said:

" I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this."
No, GE now has a new CUSIP number. 369604 301

If that is the case, those wanting to keep it as one security will need go through the uncheck the “Matched …” box and rematch the new with the old.

Since the brokerages downloaded the split as Delete/Add and Sell/Buy transactions that accomplished it all in one fell swoop with no manual effort needed (other than fixing the errant pre-split share prices), right?

q_lurker

Boatnmaniac said:

q_lurker said:

Tom Young said:

" I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this."
No, GE now has a new CUSIP number. 369604 301

If that is the case, those wanting to keep it as one security will need go through the uncheck the “Matched …” box and rematch the new with the old.

Since the brokerages downloaded the split as Delete/Add and Sell/Buy transactions that accomplished it all in one fell swoop with no manual effort needed (other than fixing the errant pre-split share prices), right?

If the brokerage downloaded Remove/Add or Sell/Buy and the user continues with that, they will be two separate securities -- GE, and GE (new). That was not my premise. (Bolding added above)

In almost all cases, the brokerages fail to include the correct basis (or any basis) on the Add transactions. They always download as one lot when there might be multiple lots. The Sells (at what price, were cap gains/losses errantly created?) are inaccurate. The Buys at what price? Holding periods will be wrong.

To the best of my knowledge this type of split with a 'New' security issued is still treated as a like-kind tax-free exchange. I would not want my Quicken telling me something drastically different.

So I would suggest if the user does want the two treated as different securities, they should use the Corporate Acquisition entry to maintain cost basis and holding periods. GE (New) acquires GE at a 1 for 8 exchange ratio. I don't think such downloaded transactions do accomplish it in one fell swoop. I would consider additional manual effort necessary.

Boatnmaniac

q_lurker said:

Boatnmaniac said:

q_lurker said:

Tom Young said:

" I'm guessing "GE New" was a temporary security set up to accommodate the Reverse Split and that the reason for the the wrong prices being entered into Quicken might have been caused by this."
No, GE now has a new CUSIP number. 369604 301

If that is the case, those wanting to keep it as one security will need go through the uncheck the “Matched …” box and rematch the new with the old.

Since the brokerages downloaded the split as Delete/Add and Sell/Buy transactions that accomplished it all in one fell swoop with no manual effort needed (other than fixing the errant pre-split share prices), right?

If the brokerage downloaded Remove/Add or Sell/Buy and the user continues with that, they will be two separate securities -- GE, and GE (new). That was not my premise. (Bolding added above)

In almost all cases, the brokerages fail to include the correct basis (or any basis) on the Add transactions. They always download as one lot when there might be multiple lots. The Sells (at what price, were cap gains/losses errantly created?) are inaccurate. The Buys at what price? Holding periods will be wrong.

To the best of my knowledge this type of split with a 'New' security issued is still treated as a like-kind tax-free exchange. I would not want my Quicken telling me something drastically different.

So I would suggest if the user does want the two treated as different securities, they should use the Corporate Acquisition entry to maintain cost basis and holding periods. GE (New) acquires GE at a 1 for 8 exchange ratio. I don't think such downloaded transactions do accomplish it in one fell swoop. I would consider additional manual effort necessary.

I have always preferred using the Split transaction for true stock splits, like this one. I deleted the Sell/Buy transactions downloaded from Fidelity and entered the Split transaction. This kept the lots history and the cost basis intact. And all my shares are also now matched to the new CUSIP...and I did nothing to make that happen. For me this was all, as my wife likes to say, easy-breezy and I'm a happy camper with how everything turned out after adjusting for the bad pre-split prices.

Tom Young

"This kept the lots history and the cost basis intact. And all my shares are also now matched to the new CUSIP...and I did nothing to make that happen."

The initial download of the split information from Schwab for me resulted in Quicken asking if the security "GE" (or "General Electric") that Schwab had included in the download (I don't remember getting any sort of "special" name beyond the regular security name) matched any securities in the Account. I expect that answering "Yes" to that and connecting the "new" security to the correct security in the Account would have automatically changed the CUSIP.

Boatnmaniac

Tom Young said:

"This kept the lots history and the cost basis intact. And all my shares are also now matched to the new CUSIP...and I did nothing to make that happen."

The initial download of the split information from Schwab for me resulted in Quicken asking if the security "GE" (or "General Electric") that Schwab had included in the download (I don't remember getting any sort of "special" name beyond the regular security name) matched any securities in the Account. I expect that answering "Yes" to that and connecting the "new" security to the correct security in the Account would have automatically changed the CUSIP.

Ah, yes, I suppose that is what matched my shares to the new CUSIP, too.

RatPak

How did you handle the Cash in Lieu? Did you enter a sell of fractional shares at $12.73/shr?

Jim_Harman

@RatPak, the Cash in Lieu sale was post-split.

In my case it was 0.25 share for a total of $25.41. I always let Quicken calculate the per-share price, which in this case was $101.64.

RatPak

> @Jim_Harman said:
> @RatPak, the Cash in Lieu sale was post-split.
>
> In my case it was 0.25 share for a total of $25.41. I always let Quicken calculate the per-share price, which in this case was $101.64.

So you manually enter the sale of 0.25 shares? Did you have multiple lots?

Jim_Harman

Yes it was a manual entry b/c there was no transaction downloaded for that. I only have one lot so that was simple; if you have more lots you would have to see what your broker did - probably FIFO but you never know...