I. Introduction
Operating companies are required to provide their financial statements accompanying their periodic and current reports in machine-readable format using eXtensible Business Reporting Language (XBRL). Companies currently provide this XBRL data as an exhibit to their filings. Since these requirements were first adopted, technology has evolved and now would allow filers to embed XBRL data directly into a HyperText Markup Language (HTML) document through a format known as Inline XBRL. The technology is freely licensed and made available by XBRL International, and it is currently used by companies in other jurisdictions for a variety of regulatory purposes.
For example, in the United Kingdom, the “accounts and computations” part of a “Company Tax Return” must be submitted to HM Revenue and Customs using Inline XBRL. See http://www.hmrc.gov.uk/ct/ct-online/taxonomy.htm. Other examples include Australia ( http://asic.gov.au/about-asic/media-centre/find-a-media-release/2015-releases/15-104mr-asic-introduces-format-for-improved-communication-of-financial-information/ ); Japan ( https://www.xbrl.org/the-standard/why/who-else-uses-xbrl/ ); Denmark ( https://www.xbrl.org/the-standard/why/who-else-uses-xbrl/ ); and Ireland ( http://www.revenue.ie/en/online/ros/ixbrl/index.html ). We note that the specific disclosure regimes in these countries differ from that in the U.S.
We believe that filing financial statements with Inline XBRL has the potential to provide a number of benefits to filers and users of the information. For example, Inline XBRL could decrease filing preparation costs, improve the quality of structured data, and by improving data quality, increase the use of XBRL data by investors and other market participants. Consequently, as a means of further assessing the usefulness of Inline XBRL, we are exercising our authority under Section 36(a) of the Securities Exchange Act of 1934 (Exchange Act) to permit, but not require, operating companies to use Inline XBRL in their periodic and current reports under the Exchange Act through March 2020. Additionally, permitting companies to use Inline XBRL on a voluntary, time-limited basis could facilitate the development of Inline XBRL preparation and analysis tools, provide investors and companies with the opportunity to evaluate its usefulness, and help inform any future Commission rulemaking in this area.
II. Discussion
Information is “structured” when it is made machine-readable by labeling (or “tagging”) the information using a markup language, such as XBRL, that can be processed by software for analysis. Structured information can be stored, shared, and presented in different systems or platforms. Companies currently use information systems that accommodate and rely upon structured information.
Standardized markup languages, such as XBRL, use sets of tags, referred to as taxonomies. Taxonomies provide common definitions that represent agreed-upon information about reporting standards, such as U.S. GAAP for accounting-based disclosures. The resulting standardization of financial reporting allows for 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.
Structured financial statement information is currently required to be submitted in an “Interactive Data File” exhibit to certain forms. These forms are prepared in either HTML or (less commonly) American Standard Code for Information Interchange (ASCII) electronic formats. The form as prepared in these formats is called the “Related Official Filing.” The Interactive Data File currently consists of an “instance document” and other documents as described in the EDGAR Filer Manual. For the purposes of this order, we use “instance document” to describe that part of the Interactive Data File that contains the XBRL tags for the information contained in the corresponding data in the Related Official Filing to satisfy the content and format requirements in 17 CFR 232.405. The other documents in the Interactive Data File contain contextual information about the XBRL tags.
See 17 CFR 232.405; see also 17 CFR 229.601(b)(101).
Companies often create XBRL exhibits by first preparing their financial statements in a word processing application and then converting it to another format, such as HTML. Filers then create an XBRL exhibit by copying the financial statement information and tagging it in XBRL. In this way, preparers essentially tag a copy of the data contained in their HTML filings in a separate document, which requires them to expend resources to create and tag a copy of the data and verify the consistency of tagged data across documents.
Errors sometimes appear in financial statement information submitted in XBRL that affect the quality of the data and its potential use by the public and the Commission. For example, Commission staff has identified several recurring issues with XBRL submissions, including errors related to the characterization of a number as negative when it is positive, incorrect scaling of a number (e.g., in billions rather than in millions), unnecessary custom tags (such as to achieve a particular presentation), incomplete tagging (e.g., a failure to tag numbers in parentheses), and missing calculations that show relationships between data (e.g., how adding cost of revenue to gross profit equals revenue and subtracting cost of revenue from revenue equals gross profit). While these data quality issues may have multiple potential causes, we believe that some of these errors may result from the submission of XBRL tagged information as an exhibit separate from the Related Official Filing.
See, e.g., Staff Observations of Custom Tag Rates (July 7, 2014), available at http://www.sec.gov/dera/reportspubs/assessment-custom-tag-rates-xbrl.html;; Staff Observations from the Review of Interactive Data Financial Statements (December 13, 2011), available at http://www.sec.gov/spotlight/xbrl/staff-review-observations-121311.shtml.
Embedding XBRL data in an HTML document (which we refer to together as the “Inline XBRL document”) rather than tagging data in a separate instance document may increase the efficiency and effectiveness of the filing preparation and review process and, by saving time and effort spent on the these processes, may, over time, reduce the cost of compliance with XBRL requirements. In particular, Inline XBRL makes it possible for preparers to view XBRL meta data within the HTML document. By facilitating the review of XBRL data, we believe that Inline XBRL could decrease the overall time required to comply with the XBRL data filing requirement and may better equip preparers to detect and correct XBRL data errors.
Embedding XBRL data in the HTML filing could create some confusion about the operation of current accuracy requirements, such as in Rule 405(c)(1). That rule requires “[e]ach data element . . . contained in the Interactive Data File [to reflect] the same information in the corresponding data in the Related Official Filing.” Although the Inline XBRL document will contain XBRL data that is currently presented in the Interactive Data File, that data must still accurately reflect the corresponding information in the HTML format portion of the filing. See condition (c) below.
Such meta data include, for example, definitions, reporting period information, data type, and related references.
Permitting filing in Inline XBRL is intended to improve XBRL data quality. In particular, the elimination of a separate instance document should reduce the incidence of re-keying errors. Additionally, Inline XBRL might eliminate unnecessary or inappropriate custom tags intended to make XBRL data look similar to an HTML document when “rendered” by software into a human-readable presentation. With Inline XBRL, companies would have less of an incentive to create custom tags solely to mimic the appearance of an HTML filing. 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.
In light of the potential benefits from using Inline XBRL, we are initiating a voluntary, time-limited program to assess the usefulness of this new filing format. This voluntary program also may facilitate the development of technological tools to support the potential further use of Inline XBRL in the future.
We note that, with the acceptance of Inline XBRL filings under this program, XBRL data users, such as investors, analysts, filers, and data aggregators, may need to modify their software or algorithms to be able to extract the XBRL data. We believe, however, that such adjustments will be minimal because the voluntary Inline XBRL program will not affect the taxonomy or the scope of the information required to be tagged. In addition, the Commission has incorporated tools into the EDGAR system that will enable users to view information about the reported XBRL data contained in embedded tags on the Commission's Web site, using any recent standard Internet browser, without the need to access a separate document. With this feature, when a user views a filing submitted with Inline XBRL on EDGAR, the user will be able to see tags and the related meta data while viewing the HTML filing. Software enabling this feature will also be made freely available to the public in an effort to facilitate the creation of cost effective Inline XBRL viewers and analytical products. We also plan to make freely available software for Inline XBRL extraction, which may further mitigate potential effects on XBRL data users. Additionally, the EDGAR system will, for the duration of the voluntary program, extract and make available the XBRL tags from an Inline XBRL document as a separate file, enabling current software to continue automated processing of XBRL data with minimal changes to existing processes.
We also note that permitting filing using Inline XBRL may result in changes that affect those filers choosing to use Inline XBRL. Currently, when there is a major technical error with XBRL data submitted in an exhibit, the EDGAR validation system causes the exhibit to be removed from the submission, but the submission as a whole is not suspended. With Inline XBRL, the EDGAR validation system 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. Based on staff observations, very few XBRL exhibits are suspended, in part, because companies and preparers routinely use tools the Commission makes available to submit test filings to help identify and correct technical errors prior to EDGAR filing. Similar tools to submit test filings will be available to those filers choosing to file in Inline XBRL. Because we expect that Inline XBRL filers would utilize available tools to submit test filings to identify and correct any technical errors prior to EDGAR filing, we believe that such suspensions should be similarly rare for Inline XBRL filers.
III. Conclusion
Based on the foregoing, we find it is appropriate in the public interest and consistent with the protection of investors to grant companies that choose to use Inline XBRL when filing financial statements in their Exchange Act periodic and current reports a time-limited and conditional exemption from certain requirements of the Interactive Data File exhibit.
Accordingly, it is hereby ordered pursuant to Section 36(a) of the Exchange Act that any company that complies with each of the conditions below is exempt from the requirement to submit an instance document as described in this order as part of its 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.
Conditions
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.
By the Commission.
Brent J. Fields,
Secretary.
[FR Doc. 2016-14306 Filed 6-16-16; 8:45 am]
BILLING CODE 8011-01-P