share count problems

Bayer (BAYRY) has 3,308,000,000 shares outstanding (according to the data view), which matches SharesCur(0). Yet it has only 872,000,000 fully diluted shares, which makes it a tremendous bargain if you use SharesFDQ to calculate value. This makes no sense to me. I thought the number of fully diluted shares was always higher than the number of shares outstanding–not 1/4 of the number.

There are even worse problems with other stocks. BTU, for instance, has 104,500,000 shares outstanding and only 18,400,000 fully diluted shares. CZR has 704,000,000 shares outstanding and 13,900,000 fully diluted shares. And these companies have not had splits in the last 90 days.

I don’t know how to value companies anymore. I’ve been using fully diluted shares rather than shares outstanding, but this is really throwing me for a loop. There are similar discrepancies with RBBN, ORIG, BKI, INPX, SCPH, TEUM, RTTR, NINE, GNCA, VTGN, ATOS, MBVX, HTGM, IMUC, NETE, etc. etc. In each case fully diluted shares are less than half the number of shares outstanding, and in each case there has been no split in the last 90 days according to the SplitCount function.

Maybe I should use Max(SharesFDQ,SharesCur(0)) to calculate market cap or per-share value?

Yup. There is no good workaround for this issue. It needs to be fixed.

In the case of Bayer, SharesFD() and Shares() provide the correct number of shares outstanding as reported by financial disclosures. 3,308,000,000 shares outstanding provided by SharesCur() adjusts to give the correct market cap given the price of one ADR (3,308 mm share * US$33.38/share = US$110 Bn = EUR$88 Bn = 826 mm sharse * EUR$106/share). It’s wonky, I know, but this is just a consequence of the structure of some depository receipts. You also have to counter that ADRs on OTC exchanges have very low regulatory disclosure and data quality standards.

From what I can generalize from this immensely illustrative example for ADRs:

  • Shares() and SharesFD() maps to financial data; inclusive of all common equity and equivalent shares.
  • SharesCur() maps to exchange price data; may be inclusive only of one share class.

I am not sure how this anecdote will hold up for other examples of ADRs which you provide. But if it does, you should definitely not use SharesFD() * Price (or Shares() * Price) for ADRs. On the other hand, it is problematic to use SharesCur()Price for companies which have more than one share class; RDS.A vs RDS.B is a prime example in which PriceSharesCur() provides an incorrect Market Cap.

BTU is a different case; the discrepancy is due to a 2016 bankruptcy and share reclassification. The SharesFD() reflect the old capital structure and it likely hasn’t been updated because the Capital IQ analysts are lazy (i.e., they are not reading the revised prospectus or investor presentations). There should be 132.5 mm common and equivalent shares.

I am not sure how we counter the stale data problem, other than Max(SharesFDQ,SharesQ) is probably the most conservative metric to calculate per share financials. Company’s more often increase common share counts in bk due to senior claims converting into common, not the other way around.

If the Price and Shares() disconnect only applies to ADRs, then you can use a rule to only use SharesCur()*Price for ADRs (granted that you accept that you might miss multiple share classes).

For non-ADRs (where there is no wonky price to share count disconnect), using Max(SharesFDQ,SharesQ) runs the risk that the company’s share count or ownership structure has changed since the last analyst update. Using ShareCur()*Price risks the possibility of ignoring multiple share classes.

The alternative is to use MktCap. I know it is not perfect and there is a definite lack of transparency on how it is calculated, but it is probably the most complete measure of capitalization available to us. A major unresolved problem, then, is how to estimate historical market cap in a way which comparable with historical disclosures. FHist(“MktCap”, n) may be used in certain instances, but cannot be used in the general cases due the script interpreter’s inability to parse nested quotes.

Thank you for sharing these examples with us, Yuval. I think you’ve been able to kick up enough muck to warrant greater transparency into the inner workings of the capitalization “sausage factory”. Who knows… maybe P123 will dig up Capital IQ’s SQL script for MktCap???

Using max(Sharescur(0),SharesFDQ) won’t work either. CZR’s latest financial report shows quite clearly that it has 149 million shares. It also reports that 10 million in stock options and 6 million in restricted shares were excluded from that number and were not taken into account when calculating EPS. P123 shows 149 million SharesFDQ and 149 million SharesQ. It also shows 704 million SharesCur(0). Where does THAT number come from? CZR has not made a share offering in the last three months. And nowhere does the additional 16 million in stock options and restricted shares show up in P123’s data. For P123, CZR’s market cap is calculated by multiplying its current price by SharesQ, which is correct. So what is the SharesCur(0) number all about?

Basically, for some companies, like Bayer, the only way to get accurate share counts is to rely on SharesCur(0). And for others, like Caesar’s, the only way to get semi-accurate share counts is to rely on SharesFDQ, though even that is problematic since P123 didn’t count the 16 million in stock options and restricted shares that should be incorporated into the fully diluted count. It would be very nice if the distinction between the two were simply that Bayer is an ADR and Caesar’s isn’t, but I haven’t done the research into that yet. I do know that if you screen for companies whose SharesCur(0) are more than 25% higher than SharesFDQ and with no split in recent history, you get 267 stocks, including such major players as DowDuPont, Toshiba, and CenturyLink. This is a huge problem. It obviously affects EPS numbers, market cap numbers, float-to-shares ratios, enterprise value calculations, and on and on. It’s a nightmare scenario.

So now I’ve looked at Dow DuPont. Fully diluted shares at the bottom of their income statement is 1.595 billion shares, which is what shows up on P123 as SharesFDQ. The company specifies this as “weighted average common shares outstanding - diluted.”

In the stockholder’s equity part of their balance sheet, they list 2.339 billion shares issued at $0.01 par value. The 2.339 billion is what shows up on P123 as SharesQ. SharesCur(0) is 2.34 billion.

So given this, what is Dow DuPont’s market cap at $76.65 per share? $122 billion, if you use SharesFDQ, and $179 billion if you use SharesQ (P123 gives the latter number). And what is its earnings per share last quarter? $0.32 using fully diluted shares, but only $0.22 using SharesQ. P123 gives the former number.

This makes no sense. Fully diluted shares cannot be significantly lower than actual share count.

Maybe this is an explanation. Maybe DuPont is fudging the numbers on their income statement by using shares outstanding instead of shares issued to bump up their EPS. And everyone is falling for it. Including us.

Or maybe it’s something else. I do know that DuPont did not repurchase any shares outstanding in the 3rd quarter, which is the quarter I’m looking at.

If anyone can help, I’d appreciate it. This is really baffling me.

The difference for DWDP has to do with the company keeping two sets of books due to the Dow DuPont merger. One set is audited GAAP, the other is unaudited proforma. The proforma books estimate historical performance under the new structure, and includes the amount of current shares (I.e., Shares(0,QTR) == SharesCur(0)).

Shares() will get you the right market cap, but will not be comparable with historical financial data until if/when CapitalIQ restates this information.

SharesFD comes from the audited financials which is what you should use when computing historical “non-restated” per share metrics.

I think this dicscrepancy is caused by the method in which P123 chooses the shares to use for Shares(). For now, you should continue to use SharesFD since it seems less ambiguous, especially when looking at prior per share metrics. When Compustat restates historical data, it will upwardly adjust SharesFD to compensate for the merger.

This seems to provide a good case for P123 dropping SharesCur() from the algorithm which chooses Shares(0,QTR/ANN/TTM) and/or reintroducing SharesBasic().

Thanks, David.

I’m still not really understanding this.

  1. When two companies merge, as is the case with Nutrien or Dow DuPont, SharesCur(0) is way higher than Shares FDQ. Why shouldn’t the company be valued at the higher number? Now that the merger has been completed, will SharesCur(0) go down? Just FYI, for Nutrien SharesQ and SharesFDQ are both 336 million but SharesCur(0) is 644 million.

  2. SharesCur is, as P123 and you state, “taken from the daily pricing database rather than from the financial statements.” What does that mean? Would that help explain why CZR’s SharesCur is almost five times the amount of SharesQ? Could this have something to do with their emergence from bankruptcy and their obligations therefrom?

  3. Would it make sense to use Max(SharesFDQ,SharesCur(0)) for ADRs and SharesFDQ for domestic companies in order to calculate EPS, market cap, and EV?

Thanks so much for your responses. They really help me a lot. But if someone from P123 wants to weigh in on this and explain what’s going on with this crazy data, that would be great too.

There are two sources of share counts on the back end. The CompuStat fundamentals database gives the share counts associated with the 10-Ks and 10-Qs, which are basic, fully-diluted and the front cover number, the outstanding share count on the date of the report.

In addition, we get a share count from the pricing database that is intended primarily to calculate market cap. It is revealed as SharesCur. SharesCur is much more immediate, and the sources are much more varied. The problem is that it is, by definition, not fully diluted, so using it for valuation isn’t ideal.

S&P CapitalIQ also offers a separate figure, called “implied shares outstanding”. There are some situations where the number of outstanding shares is not going to be all the shares that exist.

Two of those situations that we’re aware of are companies with large ownership of foreign shares or companies with large private ownership – basically where there is another significant group that also lays claim to earnings but are not reflected in traditional dilutive instruments.

We receive neither information on the foreign shares nor on the private shares. We use the CompuStat database, and we therefore don’t get the CapitalIQ pre-calculated figure for implied shares outstanding. We also can’t calculate implied shares outstanding using the information that we do have, nor can we reliably identify those situations.

I think there’s also the possibility of just simple timing differences in some of the examples you cite. The share count from the statements can be up to four months old, while SharesCur is updated every day. Even when there’s no split, it’s possible for M&A activity to change the share count.

Yuval,

These problems are actually very interesting for me because by virtue of exploring all the possible data anomalies I become more aware. This all leads to better models. Of course, there is some speculation on my part regarding what’s happening underneath the hoods of P123 and Capital IQ.

  1. [quote]
    Why shouldn’t the company be valued at the higher number?
    [/quote]

It should, but historical financials (e.g., Net Income) have not been back adjusted, so you continue to use the lower number for “comps”. If you are doing a true DCF of the proforma company post merger, you should the more recent and higher share count.

No, but Shares() and SharesFD() should increase.

I cannot speak for Nutrient.

  1. [quote]
    SharesCur is, as P123 and you state, “taken from the daily pricing database rather than from the financial statements.” What does that mean?
    [/quote]

It’s the most recent data point available from a variety of sources (I.e., press releases, 8-Ks, presentations, etc…), but I also believe it only accounts for a single class of shares. ShareCur()’s strongest use case comes from the ability to calculate up to date market capitalizations. The differences between share classes are likely attributable to legacy Compustat and Capital IQ data collection methodologies. When S&P bought Compustat, it rolled Compustat’s financials into its legacy fundamental data offerings.

I haven’t looked into CZR, but your guess seems likely.

  1. [quote]
    Would it make sense to use Max(SharesFDQ,SharesCur(0)) for ADRs and SharesFDQ for domestic companies in order to calculate EPS, market cap, and EV?
    [/quote]

I would be careful about the nuances with ADRs.

Most correct approach for all companies without major recent share capital restructuring and/or share count changes: NetIncBXor() / MktCap

Theoretically always correct: NetIncBXor() / SharesFD()

Correct for ADRs with simple capital structures and no recent restructuring: NetIncBXor() / (SharesCur()*Price)

Incorrect for ADRs: NetIncBXor() / (SharesFD()*Price)

Incorrect for ADRs: NetIncBXor() / SharesCur()

Correct (but perhaps dated) for Non-ADRs: NetIncBXor() / SharesFD()

At times like this, I think it’s wise to remember the words of the philosopher:

“It is the mark of an educated man to look for precision in each class of things just so far as the nature of the subject admits”
-Aristotle, Nichomachean Ethics

//dpa

Thank you, Paul. This is extremely helpful.

Perhaps the best practice, then, for ADRs is to use SharesCur, since SharesFD and SharesQ will often be very misleading, and since P123 does not have access to the S&P Capital IQ data that would provide a more accurate share count. Or perhaps Max(SharesCur(0),SharesFDQ) to ensure that different share classes are counted.

But for non-ADRs, we should stick with SharesFD for valuation and SharesCur for size . . .

  • YT

You’re absolutely right about this, and thank you! 6 months ago AXL and SMI had SharesCur that were much much higher than SharesQ, and now SharesQ has caught up with it in both cases.

If we want a one-size-fits-all approach for ADRs it might be SharesCur(0) + Max(0,(SharesFDQ - SharesQ)). The next question becomes what counts as an ADR. Deutsche Bank (DB), for example, is not in the $ADR universe, but it definitely has shares in the FWB, which may be the reason why its SharesCur(0) is about 40% higher than its SharesFDQ. And the Shares FDQ is significantly higher than the SharesQ, since it has plenty of restricted shares. So the next question is why isn’t DB in the $ADR universe, and is there a way on P123 to identify foreign companies that trade on foreign exchanges in addition to their US listings?

That approach seems to make sense. If you don’t mind, I am going to borrow it! Maybe a small improvement:

Max(1, SharesFDQ/SharesQ) * SharesCur(0)

… since the relationship is more likely proportional than arithmetic?

Why not use that formula for all stocks, ADRs or no, except for those that have split in the last 90 days?

My thinking is that if a company has increased or reduced its share count considerably since the last earnings statement, its EPS, book value per share, sales per share, etc. should be considered as lower or higher than reported. So my thought is a custom formula:

$shares = Eval (SplitCount(100) = 0, SharesCur(0) + Max(0,SharesFDQ - SharesQ), SharesFDQ)

Then other custom formulas could follow, e.g.

$epsttm = NetIncBXorTTM/$shares

$mktcap = Price*$shares

etc.

I guess the problem with this is that it doesn’t distinguish between companies that have a bigger share count because of a merger and companies that have a bigger share count because they issued more shares. But I like the idea of having all my value ratios go down after a buyback and up after a share issuance, because it reflects the reaction of Mr. Market quite well and anticipates the next earnings report.

fwii, I am now implementing the following algorithm to compute historical price comparable shares:

eval(Universe($ADR), Max(1, SharesFD(n)/Shares(n)) * SharesCur(63n+WeeksIntoQ5), SharesFD(n))

Just realized my new formula is very problematic for companies with more than one share class . . . it massively understates market cap.

For what it’s worth, I’ve revised my formula again.

Eval (SplitCount (100) = 0, MktCap/Price + IsNA (SharesCur(0) - SharesCur(5*Max(0, WeeksIntoQ)), 0) + Max (0, SharesFDQ - SharesQ), SharesFDQ)

To explain a couple of things: MktCap/Price gives you SharesQ in almost all instances except when SharesQ is NA in which case it gives you something else sensible. I had to add Max(0,WeeksIntoQ) because for some reason there are a few instances in the database where WeeksIntoQ is negative.

So now I get a market cap figure that’s usually very close to the one given by P123 except in the following cases: ADRs (my market cap now is much closer to the actual market cap as given by other websites); companies with a significant number of diluted shares that aren’t counted by SharesQ; companies that have recently increased or decreased their share count via acquisitions, issuing new shares, or buying back shares.