Restatement data

Susan Shulz and Zoe Vanna Palmrose collected a comprehensive data set of firms involved in restatements. Burch was at a Kansas State Research Collequium where many other researchers were talking about that amazing data set and how challenging it must have been to collect that data. As Burch was driving back to Omaha after the meeting he was reflecting on his own past experiences hand collecting data and wondering how much research was trapped in the morass of hand collection of data from EDGAR filings.

Proof of concept

Burch had been mulling these issues over for some time and in 2004 the SEC released the regulations required by Sarbanes-Oxley. The business press was full of speculation about how these new regulations would impact audit fees. So Burch decided that it would be really cool to develop something to be able to capture and report on audit fees in a timely manner. The deadline for reporting 2004 audit fees for 12/31 firms was in early May of 2005 so Burch and his colleague Dr. Susan Eldridge decided to try to be first out the gate with some descriptive research on the impact of SOX on audit fees of 12/31 public companies in the Fortune 1000. While they did not have a fully functioning version of anything they had a number of pieces that made it possible to help them focus on their data collection. The initial data for the paper was fully collected about 12 hours after the last company in their sample filed their proxy on EDGAR. This provided some proof that the ideas that Burch had been mulling over could simplify the process of collecting raw data from EDGAR filings.

Launch

We initially started out with the name directSEARCH (you could directly search EDGAR filings) but that name was copyrighted by an employment agency so we had to change the name. However, we launched with the first, and we think still the easiest, way to search a set of EDGAR filings and limit the search result to a specific set of CIKs. It does not matter if you have 100 or 10,000 unique CIKs, our application allows you to either select a file with the list of CIKs or paste them into the list box. This is a critical feature when you need disclosures for only a subset of SEC registrants.

Table Snipping and SmartBrowser

Two of our earliest clients presented an interesting problem. They wanted to collect data from specific tables in 10-K filings. Ken Reichelt who was at Louisiana State University and Alan Blankley who was at the University of North Carolina at Charlotte had a similar problem. Professor Reichelt wanted to collect data from the Selected Financial Data table (Item 6 in a 10-K) and Professor Blankley was trying to collect data from the Valuation and Qualifying Accounts table in the 10-K. They were using directEDGAR to search and identify the table but they had research assistants and they wanted to be able to pass the table to those research assistants so they could then transfer values from those tables to Excel files for use in their research. They both felt it would really make their lives easier if they could just pass the tables to their assistants instead of forcing them to learn how to use directEDGAR. These requests, coming so close to one another led to the development of the original TableSnipper. However, once tables were 'snipped' from the filings they were painful to look at because the users would have to go to the directory with the files and click on them one at a time. Once we understood how painful that was we developed the SmartBrowser which is an amazing tool as it sequentially loads all htm and txt files in a selected directory and then allows users to view them, delete them or transfer them to another directory if needed. All of this is accomplished by mouse-clicks instead of having to open and close files and do the other manual steps associated with file review.

Dehydration/Rehydration

Numerous clients using the TableSnipper were coming back to us and wondering why we could not just get the table data into a csv file. Their thoughts were that if 10-K Wizard would extract the table into an Excel file we should be able to do the same. The problem we saw was that there is not really any advantage to just transfer the data from individual tables into individual csv files. You still have to consolidate those tables for the data values to be useful. The problem with consolildation is that the registrants are using synonyms to describe the same underlying phenomena. Given that there is no way in advance to predict which tables a user might be trying to use to collect data we developed a two-step process for data consolidation. The first step was the dehydration step. Here all of the tables are scanned to identify the row labels and column headings. After deleting repeating values we present the users a csv file with the unique column headings and row labels. This allows our users the opportunity to consolidate the columns (or rows) by renaming the original values that are synonyms to some common value. The rehydration step then consolidates all of the data into one csv file without losing the identity of the source files. Early testers wondered if we could persist those associations they made and so this led to the development of user dictionary files so once a user maps Other Comp. into OTHER the system will automatically do the replacement in later uses of the dehydration step.

Text parsing Allen, Larsen & Sloan - Journal of Accounting and Economics Vol 56 (July 2013)

We were surveying the literature that has cited directEDGAR and came across this paper. The authors needed to collect data on inventory write-downs from 10-K filings. They described using directEDGAR to search for and filter on CIKs but then explained how they had to manually review each disclosure to identify the amount of the write-down. This caused us to wonder if we could improve this process. This led to the development of a text extraction and normalization feature. Users can specify a search phrase and then define the extraction of content (words or numbers) relative to the search phrase. Our application will then scan the search results and extract the defined words or numbers relative to the search phrase and place them in a separate column. This feature has turned out to be a real benefit to some of our clients. Tanyi and Smith's Auditing a Journal of Practice & Theory 2015 article 'Busyness, Expertise and Financial Reporting Quality of Audit Committee Chairs and Financial Experts' used this feature to extract and normalize the audit committee meeting frequency from a large collection of proxy and 10-K filings.

Word Counts & Frequencies

Our clients began expanding their data requirements from just numbers to data about the documents as more research became focused on sentiment and content analysis. We had been asked several times to help users get word counts and frequencies from various documents so we developed and added tools to our ExtractionEngine that would allow users to collect those attributes from any document collection from our archives.

Started the Use of an Amazon Server to Augment Our Feature Set

By 2014 we had our first Bootcamp and Burch had made over 50 visits to client schools. A consistent observation was that many people were doing many of the same tasks. Two tasks in particular seemed like areas we could help. First we found many of our clients were using directEDGAR to create richer compensation data sets than were available from other sources and then many others were trying to isolate particular sections of 10-K filings. Given that we see it our mission to help research we thought we should try to streamline that process. Thus we began extracting and normalizing Executive and Director compensation and writing routines to divide 10-K forms into their constituent Item-# sections. We needed a distribution method and discovered how we could load the content on an Amazon server and have users submit a request file to the server with the server returning either the 10-K sections or the compensation data.

Daily Automatation Processes & Adding CIKs and a Gender Identifier to Compensation Data

Once we started preprocessing some data in 2014 the next step had to be to automate these processes with the goal to make it possible to have all of the proxies and 10-Ks filed by 12/31 firms available to our clients no later than 5/1 - the day after the proxy filing deadline for 12/31 firms. We focused our development on converting many of our ExtractionEngine tools to forms that could be used in a machine controlled process. By May of 2015 we had made significant progress. We also introduced the matching of individual person CIKs to their names in the compensation tables to provide our users with a persistent identifier so they can more easily track excutives and directors across firms and time. Some of our clients had been also trying to identify the gender of executives and directors so we augmented our processes to identify their gender and add it to the compensation data.

Release of Search Extraction & Normalization Engine

Complete Reimagination of Software & Introduction of Custom Indexing

We needed to enhance our search features and modernize our architecture. Most of our users had switched to 64 bit computers but our applications were not designed to take advantage of the increased power. In particular, more and more clients wanted to be able to search larger collections of SEC EDGAR filings at one time. So we started from scratch by adopting new search technology from dtSearch and combining all of the features into one coherent application. One of the other drivers of this reset was the significant number of requests we had received over the years for custom indexes of more limited or specific sets of filings. In addition, many of our users who were downloading the Item-# sections of 10-K filings wanted the ability to use the other features of our software on those particular document collections. We introduced custom indexing so users can point our application at a relevant set of documents and then use the full range of features on that set of documents. Now a user can identify and extract specific tables from say the Risk Factors section or use our Text Normalization tools on just the MD&A.