Document ID: SEC-2016-1046-0001
Agency: sec
Document Type: Notice
Title: Exemptions from Compliance with Interactive Data File Exhibit Requirement
Posted Date: 2016-06-17T04:00Z

[Federal Register Volume 81, Number 117 (Friday, June 17, 2016)]
[Notices]
[Pages 39741-39743]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-14306]

-----------------------------------------------------------------------

SECURITIES AND EXCHANGE COMMISSION

[Release No. 34-78041]

Order Granting Limited and Conditional Exemption Under Section 
36(a) of the Securities Exchange Act of 1934 From Compliance With 
Interactive Data File Exhibit Requirement in Forms 6-K, 8-K, 10-Q, 10-
K, 20-F and 40-F To Facilitate Inline Filing of Tagged Financial Data

June 13, 2016.

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,\1\ and it is currently used by companies in other 
jurisdictions for a variety of regulatory purposes.\2\
---------------------------------------------------------------------------

    \1\ See http://specifications.xbrl.org/spec-group-index-inline-xbrl.html.
    \2\ 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

[[Page 39742]]

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.\3\ 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.
---------------------------------------------------------------------------

    \3\ 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).\4\ 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.
---------------------------------------------------------------------------

    \4\ 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.\5\ In particular, Inline XBRL makes 
it possible for preparers to view XBRL meta data \6\ 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.
---------------------------------------------------------------------------

    \5\ 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.
    \6\ 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

[[Page 39743]]

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