Inline XBRL, Explained

In this episode of the Financial Executive Podcast we speak with SEC and XBRL industry professionals about the impact of the new requirement, the benefits and challenges of implementation and how preparers can get ready for the transition.


This summer the U.S. Securities and Exchange Commission adopted a new rule that requires the use of “Inline XBRL” in the financial reporting process. Inline XBRL allows the user to embed data directly into a filing so that it is both human-readable and machine-readable.

In this episode of the Financial Executive Podcast we speak with SEC and XBRL industry professionals about impact of the new requirement, the benefits and challenges of implementation and how preparers can get ready for the transition.

Joining us for the discussion are Emily Huang, CEO & Co-Founder, Idaciti, Mike Starr, Vice President, Governmental and Regulatory Affairs at Workiva and Mike Willis, Assistant Director of The Office of Structured Disclosure at the U.S. Securities and Exchange Commission

An edited transcript of the discussion appears below the podcast player.

Editor’s Note: Per U.S. Securities and Exchange Commission Policy, the SEC disclaims responsibility for any private publication or statement by any of its employees. Therefore the views expressed by Mike Willis are his and do not necessarily reflect the views of the Commission or the other members of the staff at the Commission.

FEI Daily: Maybe you could start the discussion about Inline XBRL with a summary of the ruling, and we'll start off that way.

Mike Willis: I'll try and focus this specifically on operating companies rather than funds.

The inline rule requires the use of Inline XBRL for financial statement information, also for risk return summaries by the funds, with the intent to improve data quality and to decrease over time cost of XBRL preparation. I think we'll cover that in a few minutes.

Instead of submitting the entire active data file as an exhibit that's separate, inline filers embed a part of the interactive data file within the HTML filing. They submit the rest of it as an exhibit to the filing, which includes the contextual information that describes a tag and that process typically handled by the software that they're using.

The Inline rule eliminates the XBRL website posting requirements for operating companies, and then there's a three-year phase-in with the large accelerator filers that use U.S. GAAP required to file Inline for fiscal periods ending on or after June 15th, 2019, the accelerated filers using U.S. GAAP after June 15th, 2020, and the other filers for fiscal periods on or after June 15th, 2021. Unlike in the prior Interactive Data rule in '09, filers may comply beginning with their form 10-Q.

FEI Daily: One question I always ask and try to get understanding of is the “why now.” From the SEC's point of view, why the why now to move ahead with this ruling?

Willis: Timing is everything, and the staff have been looking at Inline since the very inception of the interactive data program. If you go back in time, the interactive data rulemaking back in '09 was released on April 1st, and just over 12 months later on April 20th, 2010, the Inline format was actually submitted as a public recommendation by theXBRL Consortium. If it was just a year later, we may not be even having this conversation. So, we have been looking at this for a very long period of time.

The why now is ... There are three or four items I'll cover, and the first one is market adoption of Inline. We see this being required by regulators all over the world; the UK, Ireland, Denmark. It’s not public companies, it's all companies in those countries. That also gives us some degree of comfort with vendor support and the related economics. I think most of your filers are familiar that European Securities and Markets Authority requiring Inline reporting by all EU registrants starting in 2020. So, the first item would be market adoption.

Second would be the voluntary program that was run. We ended up with about 150 registrants supported by seven different vendors, and over 600 Inline XBRL reports. In that mix, there was about 40 percent large accelerated filers and 40 percent small reporting companies, so a very good mix of large and small companies. We also noticed that there was quite a few very large Fortune 200 companies that were not technology related. That whole mix sort of confirmed market support.

Third item is that we continue to observe, what I would call, persistent data quality errors from both large and small filers, and so we want to enable filers to have some more options on how to see these common reporting errors. The Inline XBRL viewer enables a range of filters that help filers and investors to see these common errors, which would include things like: negative values, custom extensions, scaling values, dimensional attributes, and other common errors. Those are all going to be very easily identifiable using the viewer, and it's one of the reasons why we made the viewer open source. It provides some of those capabilities that we thought would be particularly useful to filers and their investors and analysts.

The fourth would be that we heard from the market vendors, some of which did not even participate in the voluntary Inline program, that they could and will support the Inline XBRL filing shortly after any filing final rule mandate was announced, and so that's what we're observing now.

Those are four reasons on the 'why now.'

FEI Daily: When you're thinking about moving ahead with a ruling like this, what are some of the issues particular to Inline XBRL that the SEC sort of took under consideration from the preparers' perspective when devising the final rule?

Willis: Absolutely. Those would include the following, and I'll cover each one in detail, but first is reducing reporting burden, second would be enhancing report quality, third would be easing the transition, and then fourth, assessing vendor support.

In looking at reporting burden, removing the duplication of disclosures that was previously required under the separate HTML and XBRL reports, so that's eliminated in the Inline program. It's also able to reduce the burden in the removal of the disclosures from a review perspective. So, we've not only eliminated the HTML reports, but we also provide some features, that I mentioned earlier, to facilitate the review process. I think you'll see and hear more about that in the conversations with Mike and Emily as to how effective and significant that might be.

Third, we eliminated the website posting requirements. Frankly, those created more confusion than good, and I think many registrants probably looked at page views on their websites as some kind of metric in terms of the use of XBRL. That was sort of contrasted with investors and analyst who typically looked to an aggregation play on data, not to the filer's website. So, things like EDGAR or some of the other aggregator sites. So, a third item would be eliminating the website posting.

Then we also observed that filers were spending an inappropriate and inordinate amount of time adjusting the XBRL structures to somehow realize some kind of desired rendering presentation. With Inline, the presentation control is fully in the hands of the filer through the HTML view. That's how people are going to see the data - HTML, and this whole hacking around on the modifying the structure to facilitate a particular rendering is simply no longer necessary, and therefore should free up that time.

The second item was report quality. As I mentioned earlier, we've seen some very persistent errors, from both large and small filers, and so the first thing was to try and address those through the open source Inline viewer. The Inline viewer has some very interesting features, and they're all outlined on our website. There's even a video there that provides a good summary. But my favorite features of the Inline viewer are, number one, navigation. Gone is the need for table of contents and a table or block text tagging level. If you've got to tag, you can simply evoke that index and quickly get to anything you want to see.

The second item is references. The instance documents use the taxonomies, and thereby include the references from those disclosures. If you're looking at long term deferred tax asset, that reference will take you directly to the FASB codification paragraph and page. I'd also say those references would enable you to search for disclosures within a specific topic. In the past you might have had to Where's Waldo a particular disclosure, or maybe look for a particular word. With the references now tying into the codification, we can search these documents by topic, and that would enable to some degree automated disclosure discovery.
I would also say that the references are extensible, and being a recovering audit partner, being able to track disclosures back to either permanent file memos or key issue memos would also be something that would be a benefit to the filers.

The Inline viewer is open source, and I think, in addition to those features, filers should expect additional features to be added. The disclosure checklist I mentioned earlier, time series charting of numeric values in report, time series peer benchmarking, data quality validation rules, et cetera.
It's really a heads up display platform for additional risk and quality assessments that would be useful for the filers, for auditors, and for their stakeholders.

Before I move off data quality, one thing I want to mention to the filers is that the freely available open source XBRL US data quality rules provide very useful capabilities to filers. We have observed a significant decrease of errors that are targeted by the data quality rules in the registrant filings that are using those rules. So, if you haven't thought about using those data quality rules, that would be a good consideration as a filer.

The third area is transition issues, and with any change we're going to see that. Looking at the experiences of the companies and the vendors in the voluntary program is very useful. As I mentioned earlier, we saw a good mix of large and small, but, you know, with that we've got a stage transition here. It's a three year deal, so it should be easy for the companies to adopt. And for filers, I think the hard part is actually doing the mapping and the modeling. The Inline XBRL is a 'file/save as' function, so it's sort of like you've got a Word document, and want to 'file/save as' PDF or as HTML. That should be sort of the level of effort at a macro level you'd be seeing here.

The last thing I mentioned is vendor support. With the Inline voluntary program, we did get insights on that. The main insight we got was that none of the vendors supporting the voluntary program passed along the Inline adoption cost. We also learned that given the availability the open source Inline XBRL code, that the burden on vendors may be relatively low, and support would be available to the filers.

The higher report quality and reporting process enabler should, over time, work to enhance the quality and timeliness of the filing.
But as with any internet open standard, like XBRL or HTML, support by the vendor community is really where the tire meets the road. And I got to tell you, I'm very interested to hear what Mike and Emily have to say about that as I think your FEI members will, as well.

FEI Daily: Let's get to Mike Starr. Mike, you work with a lot of companies when it comes to financial reporting, including their XBRL mapping. How would you describe the effort and resources needed to adapt to the Inline XBRL ruling?

Mike Starr: The program was announced June 13, 2016. Our first customer filed their first Inline filing with the SEC on July 1, 2016. Less than three weeks after the announcement, and I can tell you that we had done minimal work for Inline until that announcement came out because we needed to see what the final announcement contained. The effort was actually pretty minimal.

To date 192 of our 3,000 customers have used Inline XBRL. There've been 674 filings and 479 of those have been Workiva customers. So, I think the cost and effort, I think Mike's right, the cost wasn't passed on because the cost was not significant. So, I was curious about why we had a three year phase-in because I did not think it was necessary.

FEI Daily: From your perspective, the difference between the initial XBRL adoption and the adoption of this Inline is markedly less and a much easier path towards adoption? Would that be a proper way of phrasing it?

Starr: Correct. In the initial implementation we had a very immature market, in terms of readiness. Today the market is mature, and the change is not that big a deal.

FEI Daily:When you are a senior- level financial executive, you're always juggling priorities. If you are adding this to the plate, how would you describe that? On a level of one to ten.

Starr: Nonevent. I mean you're still tagging financial data using XBRL. That hasn't changed. The only thing that's changed is the way that it's presented. And it reduces, Mike was right, you know, I think the major benefit was that it reduces the duplictive filing, and the need to reconcile the two. Now for our customers that wasn't a big deal, because they've always prepared both the HTML and the XBRL in the same document. But for a lot of filers that was a big deal because they had to make sure that there was consistency between the two documents.

FEI Daily: The cost for adopting XBRL has reportedly gone down significantly over the last couple of years. Are there any risks for halting that progress or even reversing it, by adopting the new inline standard?

Starr: No, in fact I think that it won't have any impact on the cost, and the costs have gone down. In fact,  the cost related to XBRL today is negligible because most companies are using one application, to prepare their 10K and their tagging. So, I think the process of preparing and filing the reports with the SEC overall the cost has gone down, and I think that's attributable to the technology that was introduced for tagging XBRL data.

In terms of the error rates, the biggest problem that we see is inconsistent tagging. So companies will use different tags to tag the same information, and I think Inline could help to eliminate that. Particularly, if preparers consider the change in the criteria for element selection that was issued by the SEC, in July 2017 that made the reference to the FASB Codification the number one criterion for element selection. So today you see people extending when for example, they have a line item called Research and Development and Other Related Expenses and use an extension for that line item. However, that line item complies with the reporting requirement for reporting R&D cost and, therefore, you should use the standard element for that reporting requirement not an extension. So I think it will highlight those types of inappropriate extensions. And I think that the real question is, will the use of Inline lead to enhanced enforcement by the SEC?

FEI Daily: What are your thoughts? Do you think that's going to lead to increased enforcement?

Starr: Well, you know, if I represent that my disclosure complies with the recording requirement, and I use a custom element when there's a standard element for that reporting requirement, would you say that's wrong? I would. Since investors are relying on XBRL data, I would think that the SEC would want to enforce the selection of the correct element.

FEI Daily: That's an interesting point. Mike Willis, do you have any thoughts on that, or can you offer any thoughts on that?

Willis: Yes, I'm not speaking for enforcement for anybody else in the building. I think what was said earlier is that these types of errors will be abundantly more obvious in the Inline format because of the filters. I think in the past it was kind of an Easter egg hunt, a Where's Waldo kind of activity. But with Inline those types of custom extensions will be very obvious, and so when you find them in areas like Mike mentioned, R&D or revenue or something like that, that's clearly inconsistent. I think it would be more obvious to the reviewer and therefore we may see more questions about that.

Starr: And I can just add one thing. I think there's been a view some of the staff have expressed to me, that there's considerable judgment in selecting the right tag. And I would say since the number one criterion for element selection is the reference to codification, that doesn't entail a lot of judgment.

FEI Daily: That sounds like something that you know, certainly gained more interest as it's adopted. Ms. Huang, from a user and analyst investor point of view, what does Inline XBRL bring to the table that the previous iterations of the standard did not?

Emily Huang: Thank you Chris. First I really want to say thank you for bringing the regulator and the service and data provider to the conversation. You know, just have exchange between Mike Willis and Mike Starr, I think the U.S. has a very healthy sort of ecosystem for financial reporting and structured data. It really has seemed like the poster child around the globe, and it's because we always have an open dialogue between the regulator and the service provider to exchange ideas. Mike Willis may not be able to say for the SEC what can be changed, but I think that by us, a service provider, voicing our opinion hopefully can give the regulator some ideas of what the market is really asking for.

So, personally I'm really excited about this new standard. You may think, you know Inline XBRL, XBRL fundamentally the core technologies are the same, right? So why would it greatly, not just small, like in a small sort of way, why would it greatly improve the usability of this data? It's because people like to read the document the way they always read the document, and now that Inline XBRL sort of unified the underlying metadata with the presentation, which is the HTML the 10K the 10Q's, everybody used to read. Computers can part the data very quickly and people can still read the document in the ordinary, natural way. And that's both simple, intuitive and very powerful. I think that's probably the biggest reason why Inline is making us data consumption sort of companies really excited.

And another thing I want to talk about is, probably go back to what Mike Willis and Mike Starr both mentioned about the data quality and the disclosure requirement. And one thing I think the SEC has done a great job is creating this sort of open source of free Inline viewer. And I think the whole idea is, they create a starting point, and they want the vendors to take the Inline viewer and enhance the functionality, right? I take that to heart.

I think it's probably maybe just a few days after they released the source code that we saw an interest in taking the source code and cutting away, but adding a whole lot of features to it. And we started with a disclosure requirement checklist and a quality checks. I think that's really beneficial to the investors, the analysts. Mike Willis talked about now you don't have to look for the information. We sort of went a step further to say, not only you don't have to look for it, we're going organize it. Let's say for example you're looking for fact disclosed based on the disclosure requirement. The codification from IFRS or FASB for leases or revenue recognition, you can very easily go to DR checklist find the disclosure topic, click on it. We'll show you every fact based on that disclosure requirement. If in that disclosure you found that some elements are extended, they're going stand out so very obviously you don't have to really look for them. That really is one of the biggest things that we believe that Inline viewer has done. Increases the canvas, right? It has the presentation layer, that basically married the underlying metadata and sort of make it interactive.

I'll give you another example, so for analysts. Honestly they don't really care that much about the DR checklist or quality, they just want great data, right? So that's really for the preparers and the regulators to worry about. As an analyst, I want to see the data. I don't care too much about the metadata. This sort of geeky stuff behind it. But what if I can...we're not doing a presentation so if you can bear with me, maybe imagine this. Let's say you are reading the income statement, right? For a company that you follow, and you want to see are they doing better or worse? Are they spending more on R&D or less? So all you need to do with the Inline viewer now, is you can hover over that line item. Right away you hover over say the revenue, you can see the trending data shows up. It's really because the embedded XBRL sort of allows the vendor like us to grab the historical data and then show that to you. Or, you want to go to a footnote, say segment reporting, and see if the company is doing better or worse in different sort of geographical regions or different product lines, you can do the same thing. Hover over and you can see the data very, very easily. And I think that's a very powerful thing.

After we implement this we'll alter ourselves, you know do companies really just want to see their own data? Or if I follow say Pfizer, do I want to just see the Pfizer information? Not necessarily. Now the Inline, because they have the XBRL tag associated with it, guess what? You can actually you know hover over the revenue, the cost and revenue or expenses.

You can actually do instants with benchmarking, right? I can say, "I want to see how Pfizer compared to Merck or to Eli Lilly." Assuming they're using pretty consistent tags for those regular common items, you can actually just hop right over and do an instance or benchmarking, right there without reading the 10K, the 10Q document that you're so used to reviewing.

And I think that sort of unification of the presentation, underlying data, really, really sort of brought us interactivity from a dream to reality. That's why Inline XBRL is so powerful.

FEI Daily:Do you think that with this data, and the way it's going be represented, do you think retail investors have any benefit?

Huang: I definitely think it's on the table. I think that as Mike, as both Mikes were talking about this, 2009, after 2010, at that time the XBRL, the whole market was very immature, right? I was working for a vendor that produced a document as well, so I know it was very immature. Now, after ten years, I think there are two things going for us.

One is we have a lot of historical data. Nobody has to want to analyze the current year, the current quarter or even, just a couple years, right? People want historical data. And for industrialists, especially the trending data is super critical. Now we have very, very good historical information that people can use.

And, two, is, I think that with the amount of interest in technology come online, especially in the past with people always used Excel or Analysis. Now, there's a lot of interesting sort of data visualizations, storytelling, and that really, I think, triggered the interest level from the investors.

And, look at Inline, right? It's really a representation of what that is. You're looking at the narratives. You're basically reading the numbers within the context of the bigger picture. And I think that will make the investor community a lot more interested. And it's not just the retail investors, I think institutional investors, we know a lot of them already using this data. They don't want you to know about it. Most of the larger corporation using the information don't want to tell people, because it is competitive advantage. They actually want to use it quietly, improve their workflow. Make sure their processing is a lot more efficient compared with their competitors.

And I think that gradually this information will come out. And, I think the market and the corporations themselves will probably be a little bit surprised about who is actually already using this data in Inline, which is pushing forward so much faster as well.

FEI Daily: What are the chances of other technologies like blockchain replacing XBRL on this process?

Huang: Wow. Right. I think a few people actually asked me that question before as well. And, I think let's not be confused with the sexy technology versus some fundamental technology that enabler of everything. Not only blockchain, and there's other really sort of, you know, highly talked about technology in the syntax space as well. Machine learning, right? Artificial intelligence, augmented reality, you name it. People are talking about all this newer technology all the time.

And if you do a Google search, for example, I think the last time I did a Google search of XBRL a few weeks ago, I think you get like 4 million hits coming back. Not bad. But, if you search blockchain, you probably get like 150 million hits. And you search artificial intelligence, machine learning, you get like 300, 500 million hits, right?

Not only is it not going to be disrupted by this newer technology, if you think about it, what is actually enabling machine learning and artificial intelligence to work? It's good data, right? When you have good, clean, structured, understandable data - comparable data - that's how we enable the great machine learning and artificial intelligence. And, Blockchain is the distributive ledger, right? And, XBRL is fundamentally the data flow through the pipes that enables everything.

So, no, I do not believe ... all this newer, sexier technology will disrupt XBRL. I think it's just going to make this silent hero even more widespread into sort of different aspect of the financial services industry. I think that's only the starting point right now, and things will only move forward, much quickly than before, because of new technology.

Willis: The blockchain is, you know, and DLT is clearly something that's emerging very quickly. And when you read about it, it's not there by itself, something has to go in the chain and in the block. And, you know, I would say you can't put a stone tablet in that block, so what's going to go in there?

Well, the short answer is a smart contract. Something that is highly structured and very intelligent in and on it's own because it's all going to be processed by a machine. That's where the XBRL convergence with things like blockchain begins to make a lot of sense.

And so, when you look at this, it's not an either or, it's actually a confluence of the two. And recently a ... the chief scientist from a large fund group commented on this that he thought that XML and XBRL were probably the enablers for scalable blockchain in that sector.

I don't want you to think it's an either or, it's like a confluence of the smart contracts, the semantic definitions that are enabled by the taxonomies which have a lot of legs and we'll see them used in a lot of different areas.

FEI Daily: Can give me an idea from your perspective about what's the next step after Inline from your perspective?

Willis: I think the immediate next step would be the head's up display and the tools that will enable filers to enhance their processes. Their quality assessment, their compilation processes, their validation processes, et cetera. So, I think that would be a very big step for the filer community in leveraging that platform as a way to enhance their own business processes and controls.

Starr: Our customers are already do everything that Mike just mentioned, with or without Inline XBRL. My hope is that it will lead to consistent tagging across companies. You know, GAAP requires the same information to be reported for similar events or transactions. And the inherent consistency in GAAP is not always reflected in the XBRL filings.

And my hope would be, Inline, because it marries the HTML and the XBRL, will highlight discrepancies where the XBRL element used is not the element for a GAAP reporting requirement and lead to consistent tagging across companies.

Huang: I think that the current Inline, I think that the most important thing, it is actually quality. And, now, because the metadata, right? XBRL is front and center, with the disclosure itself, I certainly hope even the auditors can get involved.

Maybe, the SEC can consider making this sort of audited vacuum it, right? Because people sort of question, "Can I trust the XBRL data?" Now it's in the same fashion, I hope that actually can be audited. And then, as the data consumption company, I always want more, more data, right?

It's not just the current facing financial and open knowledge, can that be expanded into other really interesting and important sections, like in MD&A, risk factors, even the business overview section? Can those also be enabled with the XBRL to be included? Then I think they'll be fantastic.

Starr: In our view, and ... I spent ... 30 plus years as an auditor of public companies. XBRL as it exists today is not at all auditable. And the reason it's not auditable is twofold.

One is that the tagging is inconsistent. And two is the references in the taxonomy are not complete or completely accurate. And, Inline will be helpful, but there need to be some revisions to the taxonomy to enable the auditability of XBRL data. And it really goes back to making sure that there is consistent compliance with the reporting requirements under U.S. GAAP.