EPSActual - A good way for handling the problem with SpecItems?

Hi all,

For my better understanding I have a question concerning EPSExclXor vs. EPSActual.

EPSExclXor is excluding the so called extraordinary items but is still dirtied by SpcItems. And in practice it is cumbersome to get clean historical eps numbers because we only have pretax SpcItems available.

But what do you think about using EPSActual instead of EPSExclXor?
Am I right in assuming that here SpeclItems as well as extraordinary items are excluded and hence EPSActual would be much more meaningful and should be preferred for modeling purposes, in cases where historical eps numbers are used?

Thank you very much in advance.

Michael

I believe so. Try two things: using EPSActual and using (EPSExclXor - 0.8*SpcItems). They both work pretty well for me–better than using EPSExclXor alone. But if you’re looking at stocks with little or no analyst coverage, be careful using EPSActual. (I use a multiplier of 0.8 for SpcItems to take care of the pretax factor. The number should actually be different depending on whether SpcItems is positive or negative, but that gets pretty complicated. 0.8 is a rough estimate, but it’s not bad.)

I would advise against using EPSActual in any case except for breaking down surprises.

EPSActual is the EPS value as defined by analysts. They make adjustments that we are not privy to in order to try to get at consistent projections for operational growth. We can sometimes guess at what they’re doing, but sometimes it would require us to actual break down the effects of the footnotes and do in-depth analysis of our own. That’s not really our bailiwick.

More importantly, though, everything else on the site is GAAP (or at least, slightly modified GAAP). That means that EPSActual can’t really be compared to much on the site, and it’s really only supposed to be meaningful together with the surprise percentage and EPSEst.

In short, we have no idea how it’s calculated and it’s comparable to nothing else. I would be very uncomfortable with that level of ambiguity.

Special items, by the way, I’d think is a pretty neutral item in most cases. It sounds terrible, but it’s for things like “We moved to a tax-advantaged location” as often as it’s used for “We set aside 30% of our earnings because we’re being sued so badly”.

EDIT: I can’t believe that I used “affect” instead of “effect”. I am mortified.

Thanks to you both for your helpful advise. You are right, EPSActual is not the best suited item if there is no analyst coverage.

With regard to your formula (EPSExclXor - 0.8*SpcItems), maybe I am wrong but as far as I know SpcItems are not provided on per-share basis at P123. In order to have cleaner eps numbers, which are better representing the underlying earnings power of a company, Marc provided us in his strategy-design seminar with the formula (NetIncBXorTTM - (.65 * SpcItemsTTM)). Here the assumed tax rate is 35%. In my view that is a good approximation to exclude the impact of SpecItems but of course it would be much more comfortable with EPSActual

Are there any standards of how analysts make their adjustments to EPSActual or can this analyst item differ depending on the analyst who calculated it?

Thanks,
Michael

There are no standards, and it can vary per analyst. Reasonable people can differ on whether something is operational or not, and any difference in an estimate of, for example, growth rates or tax rates can also result in material differences.

We’re paying CompuStat for their analytic insight, by the way. Whenever Marc and I have had cause to buckle down and look at their decisions they’ve been pretty good. I think that I had one serious disagreement with their analytic call and a bunch of I-see-your-point opinions. But EPSActual is an aggregate of a bunch of different opinions.

Thanks Paul for your clarification on this topic. I can see your point, why you advised against using EPSActual as a substitute for EPSExclXor.
I only wonder if all the existing shortcomings of this analyst adjusted factor might be outweighed by the positive fact that SpclItems (which sometimes can be huge) are not an issue here.