by Cydney Posner
At an open meeting this morning, the SEC voted to propose the mandatory use of Inline XBRL (eXtensible Business Reporting Language) for financial statement information. The proposal is intended to facilitate “improvements in the quality and usefulness of XBRL data and, over time, decreas[e] filing costs by decreasing XBRL preparation costs.” In June 2016, the SEC began a voluntary program allowing companies to file structured financial statement data using Inline XBRL. (See this PubCo post.) The progress of this sample suggested that a wider use was feasible. There are now only two SEC commissioners, but they both seemed to be genuinely excited about Inline XBRL.
(This post is based on notes from the open meeting and has been updated subsequent to initial posting to reflect information from the press release and related fact sheet and from the proposing release.)
(The SEC also voted to adopt new rule and form amendments requiring that the exhibit index in registration statements and reports contain hyperlinks to exhibits listed. See this PubCo post.)
The proposal, part of the SEC’s disclosure modernization initiative, would require the use of Inline XBRL for the submission of financial statement information for operating companies. (Note that the proposal also requires the use of XBRL for mutual funds, not addressed in the post.) Currently, companies are required to provide the financial statements and schedules accompanying their Exchange Act reports and Securities Act registration statements in “structured,” i.e., machine-readable, format using XBRL, but they provide this XBRL data as an exhibit to their filings and are required to keep it posted on their websites for at least 12 months. Inline XBRL allows data tagging to be embedded directly in the text of an HTML document, eliminating the need for separate exhibits for the XBRL data and, the SEC believes, reducing the likelihood of inconsistencies. According to the SEC Fact Sheet, “Inline XBRL would give the preparer full control over the presentation of XBRL disclosures within the HTML filing. In addition, tools like the open source Inline XBRL Viewer on SEC.gov can be used to review the XBRL data more efficiently.”
SideBar: Information is “structured” or made machine-readable by labeling (or “tagging”) the information using XBRL so that it can be processed by software for analysis. The standard taxonomies of XBRL allow comparison and statistical analysis through automated means. According to the proposing release, “Inline XBRL would be both human-readable and machine-readable for purposes of validation, aggregation and analysis.”
The proposed amendments would require filers “to embed a part of the Interactive Data File within an HTML document using Inline XBRL and to include the rest in an exhibit to that document. The portion filed as an exhibit to the form would contain contextual information about the XBRL tags embedded in the filing.” The proposal would also eliminate the requirement for filers to post Interactive Data File exhibits on their websites. At the open meeting, Corp Fin staff indicated that the legal framework would remain the same.
One issue that may arise relates to technical errors. Currently, if filings contain a major technical error in the XBRL data submitted in an exhibit, EDGAR “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 would 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 believes that, with available tools, these suspensions should be rare.
SideBar: 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.” 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.)
As indicated in the proposing release, even the SEC staff “has identified a number of data quality issues associated with financial statement information XBRL data filed by operating companies.” Typical types of errors include “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 taxonomy extensions (‘custom tags’), incomplete tagging (e.g., a failure to tag numbers in parentheses) and missing calculations that show relationships between data (e.g., how subtracting cost of revenue from revenue equals gross profit).” The SEC attributes some of these errors to the need for reflecting the XBRL data on a separate exhibit. Whether the advantages offered by Inline XBRL, which eliminates the need to copy and tag the information in a separate exhibit, will be enough to overcome XBRL’s negative reputation — whether justified or not — remains to be seen.
The proposal contemplates a three-year phase-in, although early compliance would be permitted: large accelerated filers that prepare their financial statements under U.S. GAAP would be required to comply with Inline XBRL requirements for financial statement information in the second year after the rule is effective, followed by accelerated filers in the third year and all other operating company filers (including filers that prepare financial statements using IFRS) in the fourth year.
