Operator Search (and, or & not)

I was working on the finishing touches for the process of uploading the initial CAM_FEE data – which should be live in the next 10-12 hours. I was specifically agonizing on the value we should use for the AUFEEYEAR field. There is such inconsistency in how SEC registrants refer to their fiscal years and thus how it the data is reported in their filings.

As part of my research I decided to run a search for the phrase ‘FISCAL 2020 and 2019’. I had forgotten that when we search using words that are also search operators (and/or/not) it is necessary to append a tilde (~) to the operator that we want to use as a search term. Without the tilde the term is treated as an operator. The original search phrase returns all documents with the phrase FISCAL 2020 and the number 2019 somewhere else in the document. However, with the tilde (FISCAL 2020 and~ 2019 my search returns exactly what I was searching for (all documents with the phrase ‘FISCAL 2020 and 2019’

To illustrate the issue I am concerned about – here is an image from the 10-K/A filed by TECH DATA CORP on 5/21 (their FYE is 1/31).

Williams Sonoma’s FYE is 1/29. However, in their audit fee disclosure they describe the fee payment for their most recent fiscal year end as payment for FISCAL 2019.

Since we need to link the audit fee disclosure and the audit opinion and since the audit opinion is included in a 10-K filing that has the balance sheet date as the last date of the fiscal year – the AUFEEYEAR value needs to be the YEAR from the balance sheet date. I hope that is not confusing but that gives us the most robust way to track the data between the two filings DEF 14A and the 10-K. If we didn’t do this then we could have some 1/31 filers with the AUFEEYEAR value reported as 2019 (see William Sonoma) and others with the value 2020 (TECH DATA CORP).

Update on Critical Audit Matter Disclosures and Audit Fee Data

Well I apologize for our delay with the update to the CAM data processing. The automation process that extracts the audit report from the 10-K and then posts it to our download server is working fine. The struggle has been to determine the best way to organize the data extracted from the audit report and how to distribute this data. We are undergoing final testing today and Tuesday and I expect to make this new data live sometime late Tuesday (5/26/2020) – as an aside I will mention that Tuesday is the favorite (and only) son of doting elderly parents’ birthday.

Before I ask you to dig into the nitty-gritty on how about to access and work with this data – use this link to access a small sample (CAM_FEE_SAMPLE). There were some unexpected issues (discussed next) that are important to understand as you begin to use this data.

The first unexpected issue was what to do about those cases when the registrant files an amendment to the original 10-K. This actually happened much more frequently than expected. We have compared the original audit report and the subsequent audit reports and thus far there have been no changes to the data that we have extracted from the audit report except for the auditor signature date. Therefore – our present strategy is to include the original audit report date as one of the fields. If there is a change in the conclusion of the audit report or a change in the critical audit matter disclosures we might have to add a second row of data to report the original as well as the new values.

The next unexpected issue was how to handle the cases when the registrant files audit fees in multiple reports and the audit fees do not match. The most common scenario for this is when the registrant initially includes the audit fees in ITEM 14 in a 10-K or 10-K/A and then reports new values (for the same period) in a subsequent 10-K/A or DEF-14A. We have decided to operate on the presumption that the most recent filing has the best measure of audit fees. I will observe that we have investigated every case where there were differences reported. There was only one case where the registrant reported that the amendment was filed to correct the audit fee disclosure.

The third major issue relates to those cases where the sum of the audit fees do not equal the total amount of fees reported. We handled these cases in two ways. If we could identify a reasonable explanation for the discrepancy – perhaps the total was off by the amount of one of the components we corrected the total. If we could not identify the reason for the difference we left all values as reported and added a field to the data table named ERROR. This value represents the difference between the sum of the components and the reported total. The following table contains the full list of data values that will be delivered if this data is requested from our system.

FIELDDESCRIPTION
CIKIssuer Central Index Key.
RDATEThis is the balance sheet date for the 10-K filing as reported by the registrant. The year component of this date is the value to use in the request file for YEAR. For a 12/31/2019 FYE the RDATE will be R20191231. The YEAR value for the request file will be 2019.
CDATEThe CONFORM date for the filing that reported the audit fees.
FNAMELast two digits of the accession number of the filing that reported the audit fees.
TIDThe index of the audit fee table relative to all tables in the source document.  If the audit fee table was an image file this value is the image index.
AUFEEYEARThis is the fiscal year that the registrant reports in the audit fee table.
AUDIT FEESAudit fees as reported by the registrant.
AUDIT RELATED FEESThe total amount of audit related fees as reported.
ALL OTHER FEESThe total of all other fees.
TAX FEESThe total of the various tax fees as reported.
TOTAL FEESThe reported total of fees as reported in the source document.
ERRORThe unexplained difference between the reported total and the sum of the components.
10K_RDATEThe dissemination date of the 10-K filing that included the audit report on Critical Audit Matters.
10K_CDATEThe CONFORM (balance sheet date) as reported with the 10-K filing.
AUDITORThe name of the audit firm that signed the audit report.
LOCATION_CITYThe CITY location as reported by the auditor.
LOCATION_STATEThe STATE (or COUNTRY) as reported by the auditor.
AUREPORT_DATEThe date of the signature of the audit report.
SINCEThis value represents the year the auditor began working for the registrant.
REPORT_TYPEFINANCIAL or COMBINED to indicate whether or not the audit report includes the auditor’s opinion only on the financial statements or also includes their report on internal control.
OPINIONWhether or not the financial statements PRESENT FAIRLY the results of operations.
EXCEPTIf there is an exception reported in the audit report this field will report the language used by the auditor to describe the exception.
CAM_COUNTThe total number of Critical Audit Matters that were included in the opinion
CAM_1 – CAM_NThe auditor’s heading/description of the critical audit matters – these are reported in the order they were found in the audit opinion

The question now is how do you access this data after Patrick’s Birthday? Once we make the data live their will be a new field available in the Pull section of the ExtractionPreprocessed user interface. You will know that we have made the data live because you will see CAM_FEE_TABLES in the Data Tables Block.

Let me make sure that the parsed data in this form will only be available after the registrant has filed audit fee data. Until the audit fee data is available you can still access the actual audit reports that have been parsed from the 10-K filings. This form of presentation is meant to be entirely separate from the audit report access we turned on late last year. The year value to use in a request file for these reports should be the expected year of dissemination (filing) on EDGAR. So for a 12/31 firm the audit report for 2019 will normally be available in 2020.

Note that we included the original 10-K dissemination date 10K_RDATE as a field so you can run an event study with this data. We also included the fields 10K_RDATE and 10K_CDATE so you can match the data values to the actual audit report if you choose to pull the audit report. These fields also allow you to very quickly create a request file for the audit report. Use the CIK, the year parsed from the 10K_RDATE field from this new table and add the column PF with the value FY.

Of course the critical question is still Large Accelerated Filers. After communicating with some of our users I am convinced we need to make sure this valuable data point is available – I actually think we need to provide a new file type that lists the actual filer type (LARGE ACCELERATED, ACCELERATED . . .) accessible by CIK and YEAR. That has been added to the work list. In the meantime send me an email and I will let you have the most updated list of LAF that have filed since 6/30/2019.

This post is too long – I will wrap it up to note that when you request this new data type – the source file that is delivered is the original htm representation of the audit fee data. We normalized the audit fee disclosures – I know some of you want the more detailed fee components when they are disclosed. Those are easy to access by using the DEHYDRATOR-REHYDRATOR process on the source files.