Compustat quarterly data

[mk0417]

Signals/Code/DataDownloads/C_CompustatQuarterly.do

gen time_avail_m = mofd(datadate) + 3  // Assume data available with a 3 month lag

This may have two minor issues. If we compare the RDQ (which is the release date of earnings) and datadate:

1. RDQ < datadate: more than 600 obsrvations.
2. RDQ > datadate+90 (day): more than 50,000 observations (that are not public available with 90-day lag)

For above two scenarios, is it better to set epspxq and other quarterly accounting information to missing?

[chenandrewy]

This is a good catch. Thank you!

I agree that we should patch the quarterly Compustat lagging somehow. I say somehow because I'm not sure the best fix and would like some feedback. Fortunately this only affects about 10 predictors. Some of these from what I recall have the largest t-stats though, so I think we should fix this.

If I load Compustat Quarterly and run

gen time_avail_m = mofd(datadate) + 3 // Assume data available with a 3 month lag
gen time_avail_rdq = mofd(rdq)
gen lag_ok = time_avail_m >= time_avail_rdq

I find 80% of obs with eps data have lag_ok overall, and that the share increases over time from 60% in 1990 to 95% in 2021. That doesn't seem great to me. Seems like using RDQ is just better.

The following predictors use m_QCompustat:

I looked at the OPs for RevenueSurprise and MS, and neither uses the 3 month lag. Revenue surprise uses RDQ (and does mainly event studies), and MS does a kind of 4-month lag (assumes portfolios rebalanced 1st of May based on data up to December datadates).

Thoughts?

[mk0417]

Hi @chenandrewy, yes, I agree with you. There is no straightforward fix. RDQ will be better to avoid forward-looking bias. But further control is needed because there are many cases that the RDQ is much later than datadate (the gap can be more than thousands days). In addition, RDQ is widely populated from fyearq of 1972.

[chenandrewy]

Thanks for the additional info @mk0417!

Here is a bit more info to frame this, from the Thomas and Zhang ChTax predictor:

Our findings about the timing of RDQ vs datadate seem to be at odds with this text. Hopefully we can resolve all of this together in the next release.

[mk0417]

Hi @chenandrewy, thanks for the paper.
I suppose that their check requires the availability of earnings release date.

Please see below:
Run the sql query to load Compustat quarterly data

keep if epspxq!=.
gen time_avail_m = mofd(datadate) + 3
gen time_avail_rdq = mofd(rdq)
gen lag_ok = time_avail_m >= time_avail_rdq

tab lag_ok

lag_ok	Freq.	Percent	Cum.
0	349,436	25.47	25.47
1	1,022,362	74.53	100.00
Total	1,371,798	100.00

tab lag_ok if rdq!=.

lag_ok	Freq.	Percent	Cum.
0	45,337	4.25	4.25
1	1,022,362	95.75	100.00
Total	1,067,699	100.00

It seems that most of the bad cases are due to the missing rdq. Without rdq, we cannot decide the exact gap.

[chenandrewy]

Oh, shoot, I slipped on Stata's missing values handling! Thanks @mk0417 for pointing out my mistake. I think R and Matlab return missing whenever something in the inequality is missing, which is what I'm used to.

So it's really just 5% of observations that are affected, then my vote is to use

time_avail_m = mofd(rdq) if rdq != . & mofd(rdq) > time_avail_m

This is a minimal modification that improves the quality of the code. @mk0417 , @tomz23, what do you think?

[mk0417]

Yes @chenandrewy , this should be good.
And I suppose you want to use

gen time_avail_m = mofd(rdq) if rdq != . & rdq > datadate

to replace

gen time_avail_m = mofd(datadate) + 3

Do we also control the late release? There are cases that rdq is much later than datadate. For example, around 1% are more than 180 days (6 months).

See Hou, Xue and Zhang (2020) below. rdq should be their formation month and they require 6 months to avoid stale information (but I am not sure if my understanding here is correct or not). If we need to control this, we can use

gen gap = mofd(rdq) - mofd(datadate)
gen time_avail_m = mofd(rdq) if gap > 0 & gap<=6
keep if time_avail_m != .

Any thoughts? I can make a pull request if you agree.

[chenandrewy]

@mk0417, @tomz23, sorry it took so long to get back to this. To be clear, I actually favor a minimal modification. That is, I don't want to replace gen time_avail_m = mofd(datadate) + 3 with gen time_avail_m = mofd(rdq) if rdq != . & rdq > datadate since could be a pretty significant change to 10 signals. I don't want to mess people up too much who are already using the data.

Instead, I'm proposing to use

gen time_avail_m = mofd(datadate) + 3
replace time_avail_m = mofd(rdq) if rdq != . & mofd(rdq) > time_avail_m

so the second (new) line just patches up the 5% of cases in which mofd(datadate) + 3 > mofd(rdq).

Regarding very late release, I agree that it makes sense to drop if mofd(rdq) - mofd(datadate) > 6.

What do you all think?

[tomz23]

Sounds good to me. How many cases are dropped using the filter mofd(rdq) - mofd(datadate) > 6?

[mk0417]

Yes, that makes sense. Thank you.

[chenandrewy]

Just 0.59 percent of cases are dropped if we use the filter mofd(rdq) - mofd(datadate) > 6.

[tomz23]

Thanks! Happy to go forward with the suggested adjustment then.

[tomz23]

Fixed in 3472fdf .
Note that I changed Andrews suggestion slightly to take into account missings in rdq in the last filter:
drop if mofd(rdq) - mofd(datadate) > 6 & !mi(rdq)