If you’ve dived into directEDGAR you know that we have two key dates for searching filings. One we label the RDATE (R for revealed)- the label is weak in the sense that when I was developing our initial infrastructure I should have called it the DDATE (D for dissemination).
The RDATE is to provide you with some relative certainty regarding the date that the filing became available to EDGAR users. So for example if you wanted to study market response to filings then you would want to know the date the filing was revealed/made available or disseminated through the EDGAR platform. This is actually not the filing date as reported on EDGAR. I have a great example to illustrate this.
For background we are doing some work right now to identify any gaps in our director and executive compensation data. Specifically we ran some code to identify those cases where a registrant is missing one or more years in the time series of the compensation data we have available.
I was double checking the code results in preparation for assigning the data collection to one of our interns. The first registrant I identified was CIK 3906. We had DC data from proxy filings RDATEs from 2007 to 2010 and then we we had a result from an RDATE of 2012. So I presumed that we were missing 2011 and looked to see if I could sort out why we would have missed that particular year. First stop was EDGAR – and I see yes – there was a DEF 14A “filed” in 2007.
So then I switch to my network copy of directEDGAR – I want to sort out why we would have missed this observation and not just collect the data. So I open up the correct folder and I don’t see a folder that looks right. In the image below I would expect a folder in the sequence where the arrow is pointed. The folder above is the PRE 14A (we don’t use these for comp data as too often they will not have the complete data).
When I was comparing our archive with EDGAR I also realized that there were not any proxy filings on EDGAR with a 2012 date – the most recent proxy was filed in 2010.
I’ve been here before, I have gotten emails from clients who have found an occasional 8-K or 10-K filing where the dates have not matched to data they’ve collected elsewhere or matched to the filing date for the forms on EDGAR. I’ve shown them where we pulled our dates from . . . My point to them was that I trusted our dates but I’ve never tried to prove that the filings were not actually available on the filing dates. However, two days ago I was doing some arranging in my office and I came across a copy of directEDGAR that was about ten years old. We did a significant rebuild of our platform beginning in 2015 that was distributed to our customers in early 2016. The software changed and we also did a complete rebuild of the filing archive so we could use our new search engine. You may not recall but one constraint we were dealing with in the ‘old’ days was the two gigabyte file size limitation imposed by 32 bit Windows (64 bit Windows was was very uncommon when we started). This affected the size of the indexes and so our filings were organized in two year folders.
Below is an image from the correct folder – as you can see this version of directEDGAR was created in June 2010.
The filing I am looking for is not there. Another alternative is that I missed that filing when I constructed that version of directEDGAR. However, I am confident that is not the case as we did significant testing to make sure we knew how to capture the filings based on the indexes – that is if a filing was of the type that we wanted and it was listed in the index in that period we captured it.
However if you go to EDGAR right now and access the index (master.idx) for Q2 2007 the filing that is under discussion is listed there.
Does this mean we missed it? No actually the SEC indexes are not static. The EDGAR code platform modifies them frequently. It looks like the Q2/2007 master.idx file (which is the one we use) was last modified in September 2014.
When we do an update we don’t actually pull the latest index. Instead we pull all of the indexes (all the way back to 1993) and compare the new indexes to the last version of the index we have stored in the cloud and then we pull those filings that are not listed in the previous/archive index (no matter the stated filing date). My recollection is that the last update we did there were more than 3,000 filings that have an SEC ‘FILING DATE’ before 12/31/2019 that we had to capture and add to directEDGAR because they were not listed in our last comparison of indexes.
So back to the punch line we were actually not missing any compensation data for this filer. We had comp data from a 10-K/A that was filed in 2007 (RDATE 20070809 which also matches the filing date). The 2012 RDATE comp data we have correctly reports the YEAR (2006) that the data relates to. We have the complete time series of DC data for this registrant so we just have to delete the as reported with RDATE equal to 2012 since it duplicates the data included in the 10-K/A that was disseminated earlier. The filing in question was not available until 2012.
Of course the question is – why was this filing not disseminated until 2012. While I can’t fully answer that question – our research indicates that it is often the case that when one or another of the filings made by the company is under review by the SEC. In this case it seems that the PRE 14 was reviewed and the registrant responded to the points raised by the SEC in a letter associated with the DEF 14A. I can’t conclude anything more. However, I am very confident that the filing was not disseminated until 2012. If I do a search in directEDGAR PROXYMASTER I can find more than 200 filings with an RDATE more than 1,000 days greater than the CDATE (normally on proxy filings the RDATE is before the CDATE). When I spot check these (only 3) I see exactly what I saw with the filings from CIK 3906. Our CDATE matches, the filings were not available on the older version of directEDGAR and there is CORRESP included with the filing.
In summation – EDGAR is a ‘living’ thing. As I noted earlier – when we distributed the last update we identified more than 3,000 filings that were listed in previous indexes but were not in the version of the indexes we accessed in early January.