Correcting Price History Errors After Recording a Stock Split

It is VERY unfortunate that the Quicken folks answered so wrongly. @Quicken Kristina a follow-up with the support folks would be helpful, if possible.

Prices get downloaded principally from two sources - 1) Quicken's third party data suppliers (Download Quotes and Download Historical prices, and 2) your financial institution (as part of downloading transactions and holdings). Your FI will (typically) only provide prices one day at a time. The third party data supplier seems to provide a minimum of 5 days of prices and with a historical request can go back up to 5 years. But those longer stretches are end-of week or end of month values, not daily. Other price sources are User manual entry, user initiated csv file import, and prices associated with transactions (buys and sells, etc.). The hierarchy on how these various prices take precedence is presented here.

At one time an outfit called Mark-It was one of the third party data suppliers. Maybe they still are, maybe not. No one who really knows is saying.

The major issue that leads to the types of data spikes you are seeing is that after a stock split or similar event the data suppliers adjust the historical prices for that current split. That makes their graphs appear right, but is is wrong for Quicken data. Our Quicken records identify the change in share quantity, so the price history should not be adjusted.

If you go after historical prices (from the data supplier) and end-of-week or end-of-month values are missing or from a lesser source, the split adjusted can get inserted when they should not be.

The additional misinformation you received - If you manually enter a corrected price for those bad spikes, your manual entries are supposed to be of highest precedence and not later overridden by a subsequent historical download. They should hold, and have in my experience.

While I am comfortable promoting the indicated hierarchy as the true intent, I hold some skepticism that more recent programming changes may have created some cases that ignore that hierarchy. It is nothing I can prove or document, but the blips you are showing appear to occur more frequently than they used to.

Your opening paragraph questions — a) Yes, they misinformed you; b) Yes, they misinformed you; third: Yes, I would not expect the prices to be corrected in the future, unless you manually do so.

Second paragraph: Your evidence is what I was suggesting with my skepticism in my final paragraph where I am not sure the professed hierarchy is being followed or maintained. Your DODFX plot is suggestive that month-end prices were coming from the historical price downloads going back for a period of 5 years. Those prices (#3 in the hierarchy) should not have overridden regular quote downloads (#2). Even if those prior prices were from a prior historical price download, I don't think the new data should replace pre-existing same-source level data. The only scenario I can conceptualize a new value popping in would be if the month end price somehow appeared for a weekend (Sat or Sun) and the existing data only included Fri and Mon. Just to be a little clearer, the historical price data is supposed to be: Daily values for the 30 days (or Month?) previous to the query, then end of week values to go back a full year, and finally end-of-month values for the remaining 4 years to cover a total 5-year length of time.

Third paragraph: Certainly by intent, the csv prices might get overwritten. I have not proven that to happen or not happen. They are good for time periods older than 5 years, or for securities with prices not being downloaded.

The other unspoken part here is why might historical prices been brought in anyway. I rarely invoke that selection and if I do, I do so only for a specific security I am working on. Again, my skepticism wonders if historical prices aren't being called in by some (or all) one-step update actions. My thinking at one time was the programming saw the most recent x-days of prices missing for a given security and only solicited for data back that far. I am not sure that is currently correct if it ever was.

• 1. Yes, I would go ahead with the manual updates. Depending on your patience level, you could try building the csv file for a few dates, importing it, requesting a historical price update, and seeing what survived. a) you might find the csv import did nothing since it is lower on the hierarchy. b) if you deleted existing bad data, imported the csv data getting good values accepted, you still might find it overridden by the subsequent historical data download. So even then for your own piece of mind, I'd suggest manual entry of a few prices, then historical quotes to make sure the manual entries hold on.

2. I don't habitually go to the below pop-up for historical prices. When I do, I am very selective to a specific security rather than the default 'all' securities. But I do sometimes find historical prices filled in that I didn't expect. Why? When did that happen? I don't know. If it is from a OSU, for just those securities already being updated by the OSU, maybe that is ok. If there is something else initiating a historical quotes access, I'd want to be in control of that.

3. My policy more and more is to keep up to date with regular (current) price updates. That seems to keep the #2 hierarchy data in play and avoid the hassles you are seeing here. Associated with splits, I try to watch and examine the price data for the few days before the split. It seems the supplier providing the 'current' quotes is likely to adjust the prices based on the 'date of record' as opposed to the effective date of the split. No idea why sometimes this shows up and not other times. May associates back to my point 2 comments that I don't know why historical prices sometimes fill in.