Until now, companies have been required to provide the financial statements accompanying their periodic and current reports in “structured,” i.e., machine-readable, format using XBRL and to provide this XBRL data as an exhibit to their filings. Today, the SEC issued an order allowing companies, on a voluntary basis through March 2020, to file structured financial statement data in a format known as Inline XBRL, instead of as a separate exhibit. Inline XBRL allows filers to embed XBRL data directly into an HTML document.
Information is “structured” or made machine-readable by labeling (or “tagging”) the information using XBRL (eXtensible Business Reporting Language) so that it can be processed by software for analysis. The standard taxonomies of XBRL allow “aggregation, comparison, and large-scale statistical analysis of reported financial information through significantly more automated means than is possible with other formats, such as HTML.” To create XBRL exhibits, companies frequently need to convert their financial statements to HTML, copy the financial statement information and then tag it in XBRL, sometimes resulting in errors that affect the quality of the data and its potential use by the public and the SEC. One issue of note is that, as opposed to the current system under which a major technical error in an exhibit does not lead to suspension of the entire filing, with Inline XBRL, EDGAR “will suspend an Inline XBRL filing that contains a major technical error in embedded XBRL data, which would require the filing to be revised before it could be accepted by EDGAR.” However, the SEC expects those rejections to be rare because issuers will be able to identify errors in advance through test filings.
As discussed in this 2013 article in Compliance Week, “If You Build It, They May Not Come,” a report from Columbia Business School suggested that the time-consuming and costly effort to implement XBRL “might have been a colossal waste of time.” According to the report, the investors and analysts that were supposed to benefit from XBRL “don’t seem to be using it. According to the report’s authors,… analysts and investors remain skeptical about XBRL and have many concerns about its utility. The main complaint, according to the study, is that the data is still unreliable and fraught with errors. ‘We could not identify any users or potential users who were comfortable with the reliability of the XBRL-tagged data currently available,’ the authors write.” Apparently, a major problem is that companies are still using too many company-specific tags, known as “extensions,” rather than existing tags. The author speculates that “part of the problem lies with filers. They tend to think that the whole project is an exercise in tedium, and therefore they aren’t vested enough in the process to truly make it work. ‘Most filers we surveyed doubt whether any investors are using their XBRL data and believe they are bearing an unnecessary incremental cost with any benefits going to data aggregators who resell the data and can reduce their own data collection costs,’ the [report] authors write. They found that companies aren’t using their own XBRL interactive data for internal decision making or for benchmarking with peers. Until that changes, filers might not have enough skin in the game to really make XBRL work.” Other problems identified in the report include the unavailability of XBRL for much of the other information that analysts use in their models and analyses, as well as the dearth of analytical tools that make use of XBRL. (See, however, this PubCo post and this PubCo post, describing SEC proposals for pay-versus-performance and clawback rules, both of which would require the use of XBRL for specified disclosures in proxy statements and Forms 10-K.) The author suggests that “it’s way too soon to dub XBRL a failure or to predict its demise. But the window of opportunity won’t be open forever, either….The fact is that just because you build it doesn’t mean they’ll come. You’ve got to make it great. And with XBRL, it’s not entirely clear that regulators and, more importantly, filers have enough vested interest to improve XBRL to make it useful enough to get a broad swath of its intended audience to use it regularly.” (See this Cooley News Brief.) Not to mention that there have been efforts by Congress to limit the XBRL mandate. (See this PubCo post.)
The SEC contends that the use of Inline XBRL will offer a number of benefits compared to regular XBRL, including increasing the efficiency and effectiveness of the filing preparation and review process and reducing the cost of compliance. Because Inline XBRL allows companies to view XBRL metadata within the HTML document, it may decrease compliance time and costs, reduce the incentives for companies to create custom tags “and may better equip preparers to detect and correct XBRL data errors…. To the extent that permitting filing using Inline XBRL might improve data quality, it may contribute to wider use of XBRL data by market participants and may enhance the benefits that are associated with XBRL more generally.” The SEC believes that the adjustments necessary to use Inline XBRL will be minimal; EDGAR already has tools to enable users to view XBRL information in embedded tags without the need to access a separate document, and the SEC plans to make other enabling software freely available. Whether the advantages offered by Inline XBRL will be enough to overcome XBRL’s negative reputation — whether justified or not — remains to be seen.
The exemption from the requirement to file the Interactive Data File exhibit with Forms 6-K, 8-K, 10-Q, 10-K, 20-F and 40-F for reports due before March 30, 2020, will apply subject to compliance with the following conditions: The company must
“The company must
(a) file an Inline XBRL document as prescribed in the EDGAR Filer Manual;
(b) file the Interactive Data File as prescribed in the EDGAR Filer Manual for Inline XBRL filers as an exhibit to the Inline XBRL document;
(c) use XBRL tags within the Inline XBRL document that reflect the same information in the corresponding data as the HTML format part of the official filing;
(d) state in the exhibit index item referencing the Interactive Data File that the instance document does not appear in the Interactive Data File because its XBRL tags are embedded within the Inline XBRL document;
(e) not file in plain text ASCII; and
(f) not rely on the hardship exemptions in Rules 201 and 202 of Regulation S-T.”
[View source.]
