This has not yet been fixed, but it’s on our agenda.
Just to be clear: some companies report semiannually rather than quarterly. On the Legacy server and for Compustat data on the current server we give quarters with odd numbers N/A and quarters with even numbers the semiannual number. For FactSet data, on the other hand, (0,qtr) is the latest statement, (1,qtr) is the statement before that, and so on. This behavior is problematic because (4,qtr) would be two years ago rather than one.
We need to come up with a solution for all semiannuals, and haven’t done so yet. We’re working on it. In the meantime we’ll be changing the behavior of the FactSet server to be more like the Compustat servers.
The difference lies in the number of shares. For most companies, the Compustat and FactSet numbers for Shares(0,Qtr) match. But for some, they don’t at all. These companies are good examples.
Let’s take BEP.UN:CN, for instance. Compustat says it has 179.02 million shares outstanding and FactSet says it has 308.68 million. I’m attaching the section of their latest quarterly report to show you where both numbers come from (the last two bold lines).
Is there a way to create a function: PeriodDatePQ? This would allow us to work around most of these data issues when combined with the existing function PeriodDateQ.
This way, for example, DaysDiff(PeriodDatePQ, PeriodDateQ) > 93 would expose all stocks with non-standard reporting intervals.
EDIT: Another, possibly simpler option is to create a function QtrsInPeriod. So for example, QtrsInPeriod > 1 would expose all stocks with non-standard intervals. Those wishing to compare quarterly financials of ADRs to US stocks can use something like EBITDAQ/QtrsInPeriod/EV.
I’m afraid that’s not a good solution. A lot of companies that report quarterly report irregularly in terms of the amount of time between announcements. We’re working on a better solution and I’ll update you as soon as we’ve got it.
Sorry, I wasn’t thinking straight. You were correct, that might work. We’ll certainly consider it, along with another option, which is to create a PIT universe of stocks that report semiannually.
In the meantime, here’s a rough workaround: #QPeriods-FHist(“#QPeriods”,52)) <= 2
Most of those companies will be companies that report semiannually. It’s not entirely reliable, though, as a few quarterly companies with issue changes or late reporting (e.g. UN, HALL) get in there by mistake.
The value shown on the Snapshot page for “Shares Outstanding” shows the same Compustat value when Factset is selected. That is one of the reasons my attention was drawn to this. I’m not sure if this value pointer is wrong anywhere else but I think it’s worth a look.
I’m holding back questioning the use of adding in the value of redeemable units but if that’s the only LP unit value that factset sends then so be it.
Yes, I know that the snapshot doesn’t match the market cap. In fact, it rarely does, even for Compustat on the legacy server. Take GOOGL, for instance. SharesOut is 300.05 million, price is $1409.46, you’d expect market cap to be $422 billion. But market cap is actually $962 billion. The reason is that the snapshot gives SharesCur(0). We rarely use that number to compute market cap. You really want to use the number of shares reported on financial statements, not the number of shares available on the market. And GOOGL is far from an isolated example. Look at DELL, MTCH, CRWD, CHWY, DISH, TW, DISCA, NET, etc etc.
As for “the only LP unit value,” you’re free to use other ones. FactSet gives SharesQ as 309 for Brookfield Renewable but gives SharesFDQ as 179. You could use a custom formula like $mktcap = Price*SharesFDQ if you think it’s better than our formula. You’ll see quite different numbers for SharesQ and SharesFDQ both for Compustat and FactSet for a number of stocks, and you can decide which one suits your criteria best.
We were talking about companies that report semiannually recently in this thread. I’ve figured out a way to screen for them on the Compustat server (and this will work on the FactSet server in the near future too):
sales(0,qtr)<>na and sales(1,qtr)=na and sales(2,qtr)<>na and sales(3,qtr)=na and sales(4,qtr)<>na and sales(5,qtr)=na and country(“usa”)=0
This brings up 146 companies in the All Fundamentals universe.
If you’re using quarterly numbers for companies that report semiannually, you might want to make a few minor adjustments. Quarterly numbers from the income statement and cash flow statement will be twice as high as those for other companies (TTM, annual, and balance-sheet-item numbers will be fine). Almost all fundamental items will give you NA for odd-numbered quarters and formulas that end in PQ.
Thanks for the formula. One stock, SMSMY, Sims Ltd - ADR, was excluded using this formula even though it has semi-annual reporting. A slightly more accurate rule is:
sales(0,qtr,keepna)<>na and sales(1,qtr)=na and sales(2,qtr)<>na and sales(3,qtr)=na and sales(4,qtr)<>na and sales(5,qtr)=na AND (!country(“usa”) OR Universe($ADR))
This brings up 147 stocks in the fundamental universe. I spot checked many of the stocks and it looks accurate.
Q. Is this how semiannuals will be treated in FactSet going forward?
EDIT: I checked my notes and there are some stocks that slip through the cracks. For example, a newly listed company may not yet have five quarters of sales reported. I think that we need a more direct way to find these semi-annual reporting companies.
I would urge caution about relying on the share count from the financial statements. It can be stale when there has been a large share issuance or buyback after the closing date of the most recent financial statements. I have been burned on this in the past. Caveat emptor. You don’t want to be trading based on stale information when the rest of the world knows up to date information.
SharesCur(0) has the advantage in that it is up to date as of the latest trading day. OTOH, as you brought up, SharesCur(0) is not accurate when there are multiple share classes and such as in the examples you gave above.
Solution: We need a up to date share count that includes all share classes.
I was discussing the Compustat engines (both of them). The FactSet engine hasn’t been changed yet, so you won’t get NAs, but you’ll get the incorrect period along with double the quarterly values for income-statement and cash-flow-statement items.
We haven’t come up with a permanent solution yet. We’ll be changing the FactSet engine to operate like the Legacy engine shortly, but after that we are hoping to come up with a mechanism that will alleviate these problems. And we will be exposing semiannual companies as such so that elaborate workarounds won’t be necessary.
It’s not perfect. If you can suggest a better formula, I’d be glad to consider it.
There is some merit in not looking at sharescur(0). After all, nothing else you’re using when looking at a company’s fundamentals reflects post-filing changes. So if a company buys back some shares four weeks after its filing and you use sharescur(0), your P/E will change but your ROA and profit margin won’t.
I got burnt big time a few times. There were stocks showing an owner earnings yield of 33% when their true yield was less than 5%. The rest of the market knew.
You may not run into this issue too often because you use multiple factors for each stock. But subscribers like me use some systems that are pure value and we need a way to fix this issue.
Changes in margins don’t give everyone else an edge over us because we get the data about the same time as everyone else. In fact, we are usually able to act on it before human analysts, so that gives us an edge.
However, changes in share counts can take four and a half months until they get reported in the financial statements. The rest of the market knows right away. Value factors can be thrown off by an order of magnitude. That’s currently a huge weakness in the data we have been using.
This issue may partially explain the struggles many have had with value ratios since the switch from Reuters in 2012 (when this was not an issue). I am hopeful that FactSet has the data to fix this issue.
It’s not a question of not having the data. We have the data; FactSet and Compustat have the data. It’s the discrepancy between the number of shares on the market and the number of shares reported in the most recent financial statement. SharesCur(0) is the number of shares on the market; Shares and SharesFD are the number of shares reported. There’s no one right way to combine the two: they’re very different numbers. I think that using my formula or something like it will get you what you need.
I didn’t quite get that. If you have the data, why don’t you expose it?
I’m not sure what you mean here. As you may know, SharesCur(0) is up to date but is limited to a single share class. In most cases they should probably be exactly the same.
I find it hard to believe that you don’t have the data for up to date share counts across all share classes. Reuters had it. Many financial sites have it. Doesn’t Compustat and Factset have it too? In my mind this is basic market information. I don’t like to trade against people who have better information than me.
Your formula is an estimate. I have used a similar formula myself, but I have found material errors in it to the point that it is not any more accurate than Shares from the financial statement. Perhaps the problem is that it assumes that the ratio of shares in the various shares classes remained constant. This may not be true when new shares are issued. I have abandoned my formula because of those errors.
I am looking for the actual up to date share counts.
We do expose the data. The SharesCur(0) data comes from ICE. It’s up-to-date and changes constantly. The financial statement data comes from Compustat and FactSet. It’s all there. It’s up to users to put those together in the manner that suits them best. I’d like to see an example of “up to date share counts across all share classes.”
Take, for example, ZM. SharesCur(0) is 167.56. SharesCur(40) is 127.47. SharesQ is 278.73. SharesFDQ is 292.79. On which of those numbers do you base Zoom’s market cap? At $164 per share, Portfolio123 has the market cap at $45.71 billion, which is what you’d get if you used SharesQ. Google Finance, Fidelity, and Thomson Reuters all base their market cap on SharesFDQ, which is a tiny bit higher. But Zoom has well over 40 million more shares in circulation than it did when it released its last financial report on March 4. Should its market cap really be $59.79 billion? I don’t know. Do you? Is there another website that says so? Is there a website that currently gives it a share count of over 300 million, which may be what it’s going to report next week? I’m not trying to be contentious. I’m honestly very curious about this and have no idea what the right answer is.
