In the Weeds – Another Interesting Example Why We Use the RDATE as our Proxy for the Filing Date

We are going to reconstruct our filing archive. I was testing the code that will process the accession.txt files today on 2024 proxy filings. Rather than pull new filings I was working with the 2024 files we pulled during our production run in 2024. It is a bit tedious but necessary to identify all of the issues that we had not thought of when we are working on the code.

Here is the link to the index page for a DEF 14A filing made by Biora Therapeutics – notice that the filing date is reported at 2024-09-16. If you look carefully at the index page you will not see the date 9/20/2024. However, ultimately the filing will end up in the directEDGAR archive with a DEID of 1580063-R20240920-C20241009-F36. The reason for that is kind of interesting if you are an SEC wonk.

Here is a little extract from the accession.txt file that was in our archive and originally pulled on 3:45 PM (CDT) on 9/16:

</SEC-HEADER>
<DOCUMENT>
<TYPE>DEF 14A
<SEQUENCE>1
<FILENAME>d48307ddef14a.htm
<DESCRIPTION>DEF 14A
<TEXT>
</TEXT>
</DOCUMENT>
<DOCUMENT>

Notice that there is no content between the SGML open and close TEXT tags despite other clues present that there should have been an HTML file with the filename d48307ddef14a.htm between those tags. Based on these clues I concluded that either the EDGAR processor ripped out the original filing during the submission process or the filer somehow failed to map in the HTML file when constructing the accession.txt file.

If we look at the associated header file from EDGAR – the current version differs from the one we originally pulled. I have pasted the first few lines from each of the header files below:

The date next to the header ‘declaration’ differs between the two filings. However, what I find really interesting is that when this filing was originally submitted a DATE-OF-FILING-DATE-CHANGE tag was added with the date of the original submission. This tag is not found in every filing. Per the EDGAR filer manual it is supposed to indicate the “Date when the last Post Acceptance occurred.” It is an optional tag and we generally see it when the SEC-HEADER associated date does not equal the filing date. I should clarify though – we see it much more frequently than expected. We see it even when the complete filing does not appear to be changed and the date next to the header tag matches the FILING-DATE. The existence of that tag is not a clear signal that something might be amiss.

Chasing these kinds of things is probably a waste of time but I am hugely curious about all things EDGAR so I decided to pull the feed archive for 9/16/2024. I drilled through it and found the original filing and it matched the one we pulled on 9/16/2024 – specifically the HTML content was missing. Based on my experience with these I then pulled the feed archive for 9/20/2024 and found another version of the accession.txt file (saved as an accession.nc file) and it matched the current version that is available from the index page.

What can we conclude – I do not believe the DEF 14A was available to the public on 9/16. If you were running an event study and this filing was in your sample you would be introducing error by using the Filing Date that is reported on the landing page, in the EDGAR indexes and in the filing itself.

What I find particularly interesting is that it is not clear to me that we can rely on the file dates as reported in the EDGAR archive for the filings. Here is a screenshot of the accession archive directory for this filing.

Based on everything above, I am suspicious that the LAST MODIFIED date for this filing is correct. The htm file was not included in the dissemination feed on 9/16 but was present on 9/20. Thus, I suspect that the filing was just not available until 9/20. I find it interesting that the EDGAR code altered the LAST MODIFIED date to match the acceptance date-time.

I did warn you that this was a bit wonky. More on the archive rebuild later.

Leave a Reply