The Transition to Inline XBRL (iXBRL)



The Securities and Exchange Commission (SEC) is constantly making and updating reporting regulations, and it is important for companies to keep up with the latest changes. One of those major changes is the switch in the reporting standard from XBRL to Inline XBRL (iXBRL). On June 28, 2018, the SEC adopted amendments requiring the usage of iXBRL, which is being phased in over three years. Although iXBRL is derived from XBRL, there are some differences that are important to note.

Evolution from XBRL to iXBRL

XBRL (eXtensible Business Reporting Language) has been the standard format and requirement for public companies and mutual funds reporting to the SEC since 2009. Filings in XBRL are used for everything from business registrations to quarterly financial reports. XBRL is a machine-readable, XML-based framework, which uses standardized taxonomies to organize and categorize data in SEC filings. Each of these standardized taxonomies includes a set of financial concepts and defines the relationships among those concepts. XBRL connects the facts within the filing to the concepts defined in the taxonomy. 

Inline XBRL or iXBRL, on the other hand, combines EDGAR-compliant HTML and XBRL, resulting in one single document that is both human and machine-readable. This single-document approach should create long-term benefits by removing a separate workflow of checking the numbers and text in the original HTML filing with the numbers and text in the separate XBRL filing. By embedding the XBRL data in an HTML document rather than tagging a copy of the data to create a separate XBRL exhibit, filers should increase the efficiency and effectiveness of their filing preparation process. Inline XBRL also eliminates the need to create a separate XBRL instance document containing all of the XBRL tags which will reduce re-keying errors and simplify the review process. 

Although XBRL and iXBRL offer similar functions, there are some advantages and tradeoffs to the introduction of iXBRL:


  • By combining the HTML and XBRL, iXBRL gives control of the presentation and formatting of the financial data to the filer, while keeping the data machine-readable.
  • Provides a streamlined review process which may save time and money.
  • Eliminates the risk of having differences between your HTML and XBRL exhibits.


  • Introduces a learning curve to understanding the differences between iXBRL and XBRL.
  • Eliminates the grace period between the filing of the HTML and XBRL for certain filings such as 485BPOS.
  • The SEC makes frequent updates to their Inline Renderer which makes visualizing iXBRL a bit of a moving target.

Important Dates

As deadlines approach, filers must keep some important dates in mind.

  • Accelerated filers were required to file using iXBRL beginning June 15, 2020.
  • Large fund groups with assets of $1 billion or more were required to file using iXBRL on September 17, 2020. If the registration statement was filed on or before the amendment date, an inline filing is not required. 
  • IFRS and non-accelerated filers were required to comply with Inline XBRL beginning with fiscal periods ending on or after June 15, 2021.
  • Small fund groups with assets less than $1 billion will be required to file using iXBRL September 17, 2021. If the registration statement was filed on or before the amendment date, an inline filing is not required.

Technical Aspects of iXBRL

Beyond the obvious difference of combining the HTML and XBRL, iXBRL requires a transition to XHTML and thus introduces some technical differences about which you should know. For example, some HTML tags, such as <font> tags, and certain HTML attributes like ”name” are no longer valid. Rather than <font> tags, XHTML requires the use of a <span> element, and the HTML attribute (name=“example”) should be represented with a unique ID attribute (id=“example”) instead. Furthermore, the closing tag is essential in XHTML. For example, HTML does not require <hr> element to have a closing tag, however, that would be invalid XHTML. For that element to be valid, a self-closing <hr/> tag is required. Another area where the technical differences are apparent is regarding numeric character references and a character entity references. There are only five entity codes that are allowed in XHTML, and they can be found below.


Character Reference
Special Characters



Less than 



Greater than





Double quote 


Single quote

Allowed entity codes in XHTML


When converting from HTML to XHTML, any character entity references not listed above should be converted to their equivalent numeric character reference. For example, the Dollar sign ($) does not have a non-numeric entity reference, therefore the numeric character of (&#36;) is required.

To fully illustrate differences in more detail, we will compare how one number is included in the filing in HTML/XBRL compared to iXBRL. Let us track the number reported as the Operating Lease Expense for Three Months Ended 10/31/2019, 1557, which is scaled to thousands.


HTML Table
This table provides an example of a human-readable format as it appears in HTML


HTML Snippet
Here you can see the underlying HTML tags used to format and present the number


XBRL Snippet
Here you can see the underlying XML tags used in the XBRL instance document to represent the number


Derivation of the iXBRL
Here you can see that the XBRL tags are embedded in the HTML tags, combining both the presentation and the financial tagging information


Viewed in the Inline Renderer
Because iXBRL is the combination of HTML and XBRL, when viewing the filing in the SEC Inline Renderer, we see the HTML presentation along with the XBRL information; reducing and simplifying the review process. 


Data Transformations

One of the most complicated aspects of building an iXBRL filing is understanding how data transformations within the filing work. These transformations change a value from the HTML into the proper iXBRL format required by the SEC. The transformation used for each fact is listed within its detailed fact popup in the SEC Inline Renderer and due to the standardization of the outputs, it simplifies comparing facts. Although these data transformations are often found on the filing’s cover page, they can be used throughout the filing as well.

Cover Page

An inline preview of a tagged 8-K cover page.


Transformations are listed in the SEC’s EDGAR Filer Manual and are defined and approved by XBRL International or the SEC. As iXBRL evolves, future versions of the EDGAR Filer Manual might introduce more data transformations.

Here are some common examples of data transformations:

  • durwordsen: This will transform duration words, such as “five years”, into “P5Y”. It is a way of standardizing durations so that they can be easily compared. 

  • duryear: Similar to durwordsen, duryear will take a duration format that uses numbers rather than words for the number of years and turn it into the same comparable format. For example, “5 years” would transform into “P5Y”.

  • datemonthdayyearen: This changes the common date format, “December 31, 2019”, into the computer readable date format, “2019-12-31”.

  • boolballotbox: This transformation changes the Unicode ballot box characters (“☐”, “☑”, “☒”) from symbols to the corresponding values of “true” and “false”.

  • stateprovnameen: This will transform the name of a state or province into its 2-letter code, for instance, “Delaware” will transform into “DE”. A common issue here is that it only allows for the first letter to be capitalized, so “DELAWARE” would result in a hidden fact and test filing warning. One way to work around this issue is to change the HTML to use the text-transform attribute to make the word appear as capitalized but have the underlying text in lowercase.

Although data transformation makes it easier to compare facts, there are issues that filers may encounter. One issue a filer might run into is a fact that cannot be transformed due to the currently allowed rules. In this situation, the fact will be marked hidden while still providing a link to the associated text in the Renderer. For example, the text “6-months” tagged with a duration data type will be marked hidden. Due to the hyphen, the fact cannot be transformed into the iXBRL format, but it would still be linked in the filing.

Additionally, filers may run into test filing warnings, such as Hidden-Fact-Eligible-For-Transform,  if there is an eligible data transformation for a concept but not being utilized due to text formatting or other inconsistencies. Although this warning may imply that the filing was generated incorrectly, in some cases this is unavoidable. For example, if the value for EntityIncorporationStateCountryCode in the HTML document is set in all caps, e.g., NEVADA, the fact would be linked but the filer will receive a Hidden-Fact-Eligible-For-Transform test filing warning.  One way to work around this issue is to change the HTML to use the text-transform  property in CSS to make the word appear as capitalized in the filing but have the underlying text in lowercase.

Cover Pages and 8-Ks

In addition to the amendments requiring the usage of iXBRL and the release of the SEC Inline Renderer, in March 2019, as part of the FAST Act, the SEC has also made it a requirement for filers to tag their 8-K cover page using iXBRL. An 8-K is a current report that is filed by public companies in the U.S. when a material event occurs. These filings include important information for shareholders and must be submitted to the SEC within four business days of the event. Previously, XBRL was only required if updated financials were included. 

In addition to the mandate, filers must provide additional detailed information such as registrant, address, phone number, and SEC file number. Each additional field is required to be tagged and linked to the corresponding text found on the cover page of the filing. This rule will be phased in at the same time filers become subject to the iXBRL mandate. Sections 6.5.46-52 of the EDGAR Filer Manual highlight in detail the additional fields that are required when filing iXBRL.

When linking some facts to the HTML, data transformations will be required to convert the text to the standardized iXBRL format. A common example is converting the ballot boxes on the cover page to true or false. If the formatting of the text does not match with the data transformation rule, it will still be linked to the text but will be marked as hidden in the underlying iXBRL.

However, there are exceptions for certain concepts. For example, the registrant name in the filing must match the registrant name in the EDGAR database but some variations will still be allowed. To illustrate, “ABC Corporation” can be used in the iXBRL even if it is listed as “ABC Corp” in the EDGAR database. Exceptions like the one stated, make it less likely that a fact on the cover page would need to use the hidden tag.

SEC Inline Renderer

In addition to the amendment to require filers to transition to iXBRL, the SEC released an open-source iXBRL visualization tool to preview how filings would render once filed. The SEC’s Inline Renderer takes iXBRL files and renders them in a way that is easy to review. Because the XBRL data is embedded directly into the HTML document, the Inline Renderer will allow the user to see the rendering on a web browser with a marked-up version of the original HTML.

The Renderer is available for anyone to download and install on their personal computers from the Arelle website. Their documentation page includes step-by-step instructions on how to install and use the renderer, which can be through a graphical user interface or the command line. 


Viewing the Rendering

The Inline Renderer will allow the user to see the original HTML formatting with orange markups for each particular fact. The orange markups highlight facts that have more details about the iXBRL tag used. Text block and table text block-level tags will have a vertical orange bar before and after the fact which can be clicked on for more details regarding the iXBRL tag.

Orange Fact Markups



Navigating the Rendering

The header bar of the Renderer offers several helpful tools. For example, the Sections option allows the user to jump to different sections of the document. It offers a similar function to the standard sidebar of the XBRL Renderer. The new Inline Renderer also features a search bar which is useful for looking up concepts, values, or text within the document.  The search feature also comes with a filter, allowing the user to set different searching parameters such as fact name, definition, or dimension. Lastly, the Data, Tags, and More Filters found on the header bar offer additional filtering capabilities of the rendering.


Inline Renderer Header Bar



Renderer Complexities


Hidden Facts

This new way to render an iXBRL filing comes with a few complexities. One complexity is with hidden facts. Some facts do not have text within the HTML filing that can have a direct link. Therefore, to view these facts in the preview, the user has to filter by Additional Items Only which is located under the Data dropdown and opening the fact sidebar on the right-hand side. An example of one of these facts is the Entity Central Index Key, which is still required to be tagged within the filing but is not listed in any text within the filing.



Another complexity is how the Inline Renderer displays label information. For each fact within the pop-up window, there is a tab for Labels.


Labels in Fact Dialog


The tab lists all the labels that were used for a specific concept throughout the entire filing, including any standard, negated, terse, or verbose labels, but does not specify which type of label was used for the fact that is currently being viewed. This issue may cause confusion because without looking at the underlying iXBRL, there is no way to know which of these labels was used in this context.



Another complication that was introduced with iXBRL is the usage of continuations. Continuations are used when a fact spans over several nonconsecutive paragraphs or sections; the “ix:continuation” tag is used to connect the sections to each other and assign the same concept. This is common for text block sections to avoid page breaks or unwanted whitespace. Each of these continuation tags must link to one another, and if just one of the links is broken or incorrect, the entire chain would be incorrect.


While the transition to Inline XBRL introduces complexities in the filing process, over time, filers will be able to realize the benefits that iXBRL offers.  The SEC has adopted Inline XBRL with the intention to improve the data’s usefulness, timeliness, and quality. Inline XBRL involves embedding XBRL data directly into the filing so that the document is both human-readable and machine-readable. This amendment is expected to reduce the preparation time and effort needed to review XBRL data. iXBRL ultimately improves upon XBRL, giving control of the presentation and formatting of financial data to the filer. As deadlines approach, it is important for public and investment companies to keep up with these amendments to lessen the learning curve and ease the transition to Inline XBRL.

About the Author

Amin Kassim is a Business Analyst at CompSci Resources, LLC. He earned a M.S. in Analytics from American University. Here at CompSci, he is responsible for preparing and processing SEC filings for public and investment companies. By leveraging our patented technology, Amin Kassim helps businesses comply with SEC requirements.



Amin Kassim

Business Analyst at CompSci Resources, LLC