Some language first. When we think about SEC filings internally our team thinks of them as composite documents that have a form and perhaps some exhibits. We think of the filing as the accession number dot txt file. When we collect a filing we parse it into the constituent documents and then store those documents in a unique directory that is based on the CIK of the filer and the RDATE as well as CDATE of the filing.

As part of the parsing and processing steps we embed metadata into the individual documents that constitute a filing. The metadata we embed varies based on the nature of the form. Some of the metadata is likely to enhance the value of your searches, for example we include a field named DOCTYPE that describes the nature of the document. Other pieces of metadata are added to simplify your collection of information you might need relating to the results of a particular search. For example, we have started adding the ACCEPTANCE time field to documents parsed from filings. All of the metadata that is embedded in a document is automatically included in both the Summary Results file and the ContextExtraction Results file.

To determine the fields included in a particular filing category you need to select an index first and then hit the Fields button next to the search panel on the application. In the image below I have selected an index that contains parsed 8-K filings. I hit the fields button so the application lists all of the fields that are available in this particular archive.

To highlight/emphasize that the field lists changes dynamically based on the embedded fields in the documents in a particular index – the following image illustrates the fields that are available in an index of Proxy filings (DEF 14A and PRE 14A)

To illustrate how the fields are embedded in the documents the next image has the section where the fields were embedded in an 8-K Form as part of an 8-K filing.

There will be a discussion on how to access and use the fields in our Python code section. Note, for the cases where the source document is a pdf or other type of image file – fields will not be available as there is no way to embed without disturbing the content of the original file.

In general, to use a specific field in a search – select the field and then enter the appropriate value. Hit OK and the proper field search instructions will be entered into the search box. You can use as many fields as you like and operators with those fields. It is important though to remember that when you use multiple fields there must be some operators separating the fields and other search terms or phrases.

The following sections describe some of the key fields and how to use them in a search. Remember, not all fields are going to be useful in a search – however any field embedded in a document will be reported at the end of the search and included in any of the search outputs.

DOCTYPE

We think the DOCTYPE field is one of the most useful fields for focusing a search. As noted above we collect a filings and then parse it to separate the individual documents and then tag each document with the conformed type of document as labeled in the SGML tags used to construct the filing. Here is an image of the index page of an Apple 10-K filing which lists all of the component documents that constitute the filing.

This filing consists of nine different documents and two image files (in addition to the XBRL components which are not listed here). We construct the DOCTYPE by taking the value for type and splitting it on any period/decimal value. We remove any dashes (-) and slashes (/) and then compress the remaining characters to remove any spaces. The 10-K document tag becomes 10K, each of the EX-10.## are tagged as EX10, the Exhibit 12 (EX-12.1) is tagged with EX12.

While the SEC has standardized the 10-K form and eliminated many variants it is not uncommon to find 10-KT – which is a 10-K filed at the end of a transition period. Without going through the full history, earlier variants of the 10-K included 10-K405 and 10KSB (as well as amended (/A) versions of these filings. Thus, if I want to search for 10-K filings and I want to include all variants one strategy would be to use the value 10K* in the DOCTYPE field.

Once I have entered the value and hit the OK button the following constraint is added to the search box.

It is important to note that the DOCTYPE value occurs during preprocessing of the filings. We do not know when new values are added by the SEC to the list of valid values. We process them as they are reported in the filing.

Cornell University’s Law School has a fabulous resource – their Legal Information Institute maintains an electronic copy of the Code of Federal Regulations (CFR) and the requirements for exhibits are detailed there. The table in the middle of this page is the first place I go when I discover that there is a new exhibit type in our indexed collection and I need to understand the nature of the exhibit. Below is an excerpt from their site that I collected and organized on 4/20/23. While we periodically update the list below our updates will lag the SEC setting our new exhibit requirements. However, our code anticipates new exhibit numbers and so they are properly embedded when included in a filing.

8-K Item Codes

The SEC has a set of standardized item codes that are required to be included with 8-K filings. Below is a screenshot of a number of 8-K filings made on 4/20/2023. The green box indicate the item codes that were furnished during the submission of the listed filings.

The image above that has an example of the embedded metadata in a filing illustrates how we add these values to the filing. We add a tag for each item code submitted by the registrant and we set the content attribute to Yes. To date we have never seen more than nine item codes submitted with any single 8-K filing.

When selecting an 8-K item code it is not necessary to enter a value in the Value to Search box. If you select and item code and hit the OK button the application will prefill the value with the word YES. It is important to understand that while individual documents are tagged with their unique document type tags all other documents included in an 8-K filing have the same item tags.

In the first image below I ran a search over an 8-K collection to find all documents tagged with ITEM 4.01 (Change in Registrant’s Certifying Accountant. In the particular time-span I searched I found 3,395 unique documents.

The next image has the same search but I added an additional constraint – I set the DOCTYPE to be 8K* (both 8-K and 8-K/A) and that search only returned 786 documents.

It is important to know that the SEC remapped the item codes as part of their response to Sarbanes-Oxley and added a significant number of additional triggering events that require filing an 8-K. For example, 5.07 Submission of Matters to a Vote of Security Holders only became an 8-K disclosure in 2010. As a matter of fact, Apple was one of the first to file an 8-K with shareholder votes reported on 3/1/2010.

Thus, you cannot find any of these disclosures in an 8-K filing prior to 3/1/2010. In addition, the SEC changed the codes. For example, the item code that indicated there was a change in auditor was 4 until 2004 when it changed to 4.01. To maintain consistency and ease of use we remapped all of the old 8-K item codes and re-tagged the documents in our archive to match the 2004 requirements. Thus, ITEM_4.01 can be used to find auditor changes across the entire archive of 8-K filings. In the image below you can see that Barnes Group (CIK 9984) filed two 8-Ks relating to auditor changes in 1994.

To find these same filings in directEDGAR we just need to search for the current Item Code (ITEM_4.01) as illustrated in the results summary captured in the next image.

In my opinion the best place to verify the disclosure requirements and the details that relate to understanding the 8-K Item Code meanings is by reviewing the instructions for a current 8-K which can be found here (8-K Filing Instructions). However, here is a schedule of the current item codes as well as the caption associated with the code.

CNAME

The CNAME field reports the company name at the point in time the filing was made. Company names are not persistent and in general directEDGAR is not the right platform or tool to look for filings for just one company. However, you can use the name to identify specific documents – our caution is that companies use different variants of their names even in sequential filings and so it is better to be as general as you can rather than too specific. Frankly, if I know that I want to look at a 10-K for Conagra and that is all I want, I will generally use the SEC’s EDGAR website for that task.

FYEND

The FYEND field reports the fiscal year end of the filer AS IT WAS REPORTED IN THAT FILING. This is useful for searches where you want to limit the sample only to those filings made by firms with a particular fiscal year end. It can get clumsy articulating between databases on this field. We use the FISCAL YEAR END as reported by the filer and we do not make any adjustments. Some companies operate on a 52/53 week fiscal year end and the others may make an error when they enter the value of this field as they are submitting the data to EDGAR.

SECPATH

This is a relatively new field and it represents the path to the source document on EDGAR. We hope this facilitates matching search results from our platform with data collected from other sources.

SICCODE

The SEC assigns an Standard Industrial Classification code to almost all filers. Filers are inconsistent as to whether or not they report this value in their filings. If they do we capture it and include it in the metadata to make it possible to limit searches by this value. The current composition of the SEC’s SIC code table can be found here (SEC SIC CODE ASSIGNMENT TABLE)