I was playing around to look at buyback yields and found quite a few strange numbers in shares and fully diluted shares, which did not match other sources like Google finance when checked.
For example, CXP has 231m shares based on P123, but only 124m from Google finance, quite a difference. Also, the difference between PTM and TTM is quite dramatic and seems wrong. Is this a data error or is it due to non-adjustments?
Is the number of shares, i.e. Shares TTM and Shares PTM, etc. adjusted for splits and corporate actions like mergers?
However Compustat kept all the previous financials. A case could be made that an entirely new company should be started, but it’s also desirable to keep the history, like revenues. It’s entirely Compustat’s call.
AMBC could be eliminated with this work-around:
close(300)!=NA
This makes sure that the current stock was trading 300 bars ago, ~ 1.2 years ago, so that the shares line item corresponds to the stock trading today
To add to what Marco said, I would also point out that data on our site may or may not match other sites simply because we sometimes make adjustments to facilitate analysis over time.
One of the specific goals of P123 is to deliver NAs as seldom as possible, and one of the functions that is impacted by that goal is the Shares function. We go through several different data items to present the best number that we can. In general, Shares goes down the list of most recent shares, fully diluted shares and then basic shares. SharesFD goes fully diluted, most recent and then basic. SharesBasic delivers only basic shares. (Basic shares are not usually used in financial analysis, so we assume that if you’re using SharesBasic you are looking only for basic shares.)
What’s important to realize is that the function’s output might change over time.
Imagine a company that has only anti-dilutive agreements in place. In such circumstances, fully diluted shares are not reported (null) in the database, and basic and most recent are likely to be very close. On P123, that company’s Shares, SharesFD and SharesBasic will all report the same number, which will probably match Google’s.
Then the company does a secondary IPO with several executive options which are materially dilutive. Now P123 will display different numbers in Shares, SharesFD and SharesBasic, and only one will match Google. (Probably Shares.) In this example, the exact number reported would have changed from period to period.
I’m not saying that this is what happened, but only that this is what could happen, and it would probably appear as a large change to the naked eye. In fact, in my example it is a material change.
Thank you for the comments, despite that, I think a few are actually wrong, perhaps unadjusted for splits.
i.e. NVGS - had a 3x1 split, and the Q and PYQ shares are almost 3x, on reuters, the sharecount is similar between Q and PYQ, but not on compustat, so I think it must be a mistake. I understand that there can be slight differences between databases, that is fine, but not 3x the number of shares.
WLH, SBS and NKA seem to have the same issue.
Which share count is used to calculate marketcap at P123? The current might very well be correct, but I am concerned that there might be more of these errors, therefore calculating a wrong point in time marketcap?
Thank you
The output of FHist is point in time only for the offset to which it resolves to. Ex, FHist(“xyz”,10) used today, returns xyz point in time as of 10 weeks ago. Whatever happened in the past 10 weeks is not included.
It’s best used for ratios where the #shares is normalized away, like PE, mktcap, etc.
