First, let’s recap the SEC’s requirements for Inline XBRL (or iXBRL). On June 13, the SEC issued an order under the Securities Exchange Act to allow companies to voluntarily file the structured financial statement data that is required in their annual and quarterly reports as Inline XBRL. In other words, through March 2020, filers can choose to integrate their XBRL data directly within the HTML document for their EDGAR filings. The EDGAR System has been updated to accept filings that contain Inline XBRL within the submission document.

It’s important to note that the order permitting the use of Inline XBRL is voluntary. You can choose to submit your periodic and current reports using the standard XBRL exhibits or you may opt to transition to Inline XBRL and submit your filings as part of the voluntary program. Presumably during the trial period, as industry advancements are made to the preparation and filing of Inline XBRL, rules will be adopted to permanently allow Inline XBRL.

So what exactly is Inline XBRL?

Inline XBRL (or iXBRL) is a standard developed by XBRL International that allows a preparer to place XBRL information inside of an HTML document. Using iXBRL means that a document can be viewed in most HTML browsers and looks just like a normal HTML document. However, through browser extensions or other software, the XBRL information contained in the document can also be viewed directly or even exported into normal XBRL.

When using iXBRL, the HTML document replaces the instance file of the XBRL file set. The other files for the XBRL data (such as the calculations, definitions, presentations, schema, and labels) are still separate from the HTML file. To put it simply, the Inline XBRL document is a straight-up replacement for the XBRL instance document.

The idea is that by directly embedding the XBRL element tagging into the official document, the burden of preparing the documents will be reduced and the ability of consumers to read the document will be improved. By embedding the XBRL tagging into the HTML document, the SEC also believes that preparers will be better able to detect and correct the data errors that tend to occur when preparing XBRL exhibits separately from the official document.

For XBRL data that is required but is not necessarily included in the official HTML document, preparers will be able to tag additional facts in a hidden area. Items like the company CIK and other document and entity information will be included in this hidden area so the look of the HTML document will not need to be altered to accommodate the Inline XBRL data.

There are a number of positive things about the SEC’s initiation of the voluntary Inline XBRL program.

Because the Inline XBRL document obviates the need for both an XBRL instance document and the official HTML document, there should be a smaller chance of introducing mistakes in the filing. In particular, during the review and revision process, you will no longer need to make changes to two separate documents. (It is important to note, however, that a change to the XBRL data in the Inline XBRL document may still require changes to the other XBRL linkbase files.) Preparing one document versus two documents should also decrease the overall time it takes to create and submit your EDGAR filing, which could potentially reduce costs.

Further, because the Inline XBRL document is prepared using HTML, you are now in control of the appearance of the XBRL data, from an HTML perspective. With standard XBRL, you are at the mercy of XBRL viewer software, meaning your XBRL data could be rendered in a manner you didn’t intend. As a consequence of the XBRL viewer software, preparers often misused element extensions as a means of forcing the viewing software to render the XBRL data in a particular way. However, since a presentation, label and calculation linkbases are still required, it does not mean that the need for properly structured presentations will be obviated.

With Inline XBRL (and assuming the user is viewing the document with an inline XBRL viewer), users can see your facts and XBRL data as they appear in the document using your styles and in the textual context of the report. Your document has the power of computer readability, but it also retains the human-readable format of your official HTML file, which has always been a concern for registrants.

However, there are some consequences to using Inline XBRL.

From an EDGAR standpoint, the HTML coding permitted for use with the Inline XBRL document is not compatible with normal EDGAR HTML. The HTML used for Inline XBRL is XHTML, HTML structured to the strict rules of XML. What this means is a document that may be compliant for EDGAR may not be compliant for Inline XBRL. For example, Inline XBRL does not allow the <u> tag for underlining text, so an Inline XBRL document would have to replace the <u> tag with <span style="text-decoration: underline"> or with a <font> tag. Further, the <font> and <span> tags are mutually exclusive in each environment; traditional EDGAR HTML does not allow the <span> tag, and XHTML does not allow the <font> tag. Another consequence of XHTML is that coding must be well structured. While the overall quality of the HTML code submitted to SEC over the years has improved, a lot of poorly structured HTML is still being filed. Documents with poor HTML quality tend to view in web browsers just fine but are not structurally compliant with XHTML standards.

Because of this, the tools for creating Inline XBRL may not be ready for EDGAR and the tools for creating EDGAR HTML may not be ready for Inline XBRL. You will have to carefully research your current filing software to ensure that it is ready for you to make the switch. You may also need to consider that, if there is an error in your Inline XBRL document that causes EDGAR to suspend your filing, the whole submission will be suspended. With the current system, errors in the XBRL exhibits that would suspend the filing simply cause the XBRL data to be removed from the submission, allowing the rest of the filing to be accepted.

Additionally, Inline XBRL is similar to XBRL but there will be a learning curve. The biggest challenge is that, unlike standard XBRL, the Inline XBRL tags must contain information on how to transform data into a computer-readable format. For example, consider the date “06-05-16”. To an American, it is “June 5, 2016”. To a European, it would be “May 6, 2016”. And to a computer, it is just dashes and numbers.

When you create Inline XBRL, you need to specify in the XBRL tagging the format for that date. If there is no transformation available for your data, you will have to change the primary document to a more acceptable format. For example, if your document had a sentence like “...options expire on the 2nd of March in 2016” and you needed to tag that date, you would have to change the date format or use a hidden fact.

There are some control and formatting oddities. For example, all numbers have to be tagged as positive values, parenthesis and negative signed must be outside the Inline XBRL tags. If a number is actually negative, the sign must be expressed inside the XBRL tag and as text with the HTML. This could lead to confusion. In addition, the EDGAR Filer Manual rules still apply. For example, the HTML text will have to be coordinated with the label and presentation linkbases.

It may sound complicated, but it illustrates the challenge that iXBRL will pose to preparers. Most preparers are just now becoming more comfortable with XBRL tagging, and to change to a new format will require re-learning some basics.

There may be other less technical and but more procedural issues to tackle. For example, will the Auditor Statement and Consent have to be altered because the official HTML document now contains additional “hidden” information? These are other things that also need to be considered.

So the burning question in your mind is probably: “Should I be using Inline XBRL?”

Because the voluntary program is time-limited, you may also feel that you have a few years to put off learning this new format or that the SEC might change their minds about using Inline XBRL. It’s a question that doesn’t have an easy answer. It is also important to note that the announcement and order from the SEC makes no mention of replacing the current XBRL filing method with Inline XBRL.

But, overall, there isn’t much of a downside to switching to Inline XBRL. You will have plenty of time to carefully research Inline XBRL before beginning the transition and, once the technical challenges facing preparers, software providers and the SEC are overcome, Inline XBRL very well may reduce the burden of preparing XBRL documents and provide an improvement to the quality of the XBRL data being submitted to the SEC.

If you would like to learn more about Inline XBRL or are looking for additional guidance, please contact our technical support team for more information. As a leader in the XBRL industry Novaworks will be providing more information and learning tools in the upcoming weeks to help you better understand Inline XBRL and what the transition entails. Your GoFiler Complete or GoXBRL software will also be updated with more tools for creating Inline XBRL as the voluntary Inline XBRL program gets further underway.

Sources:

EDGAR Filer Manual (Volume II), Version 37

SEC 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

SEC to Permit Voluntary Filing Using Inline XBRL