Inline XBRL – Worth the Wait?
There has been much talk about Inline XBRL in the past few weeks. From endorsements by SEC commissioners and the SEC chair to letters from Senators on both sides of the aisle, Inline XBRL has received considerable attention. In this blog post, we will explore what the buzz and the substance behind the buzz is all about.
What is Inline XBRL?
In our April 27th blog “Introducing Inline XBRL” we explored the basics of Inline XBRL. Worth repeating is the assumption that Inline XBRL can bring certain advantages to the table including consolidation of XBRL reports and presentation formats in a single document. We also explored where in the world Inline XBRL is being used.
Recently, however, the momentum behind Inline XBRL has experienced significant political support that will result in action by the SEC. Will Inline XBRL be the answer the SEC and investors been waiting for? Let’s go a bit deeper and find out.
SEC Endorsement
The endorsement of Inline XBRL has been a long time in the making. Back in August of 2013, The SEC issued a Request for Quote asking for vendors to help them modify their systems to accept Inline XBRL. On June 5, 2014, Fujitsu America announced that it is providing technical services to the U.S. Securities and Exchange Commission (SEC) to create and support an Inline XBRL eXtensible Business Reporting Language® (XBRL®) software solution. Trintech was also chosen to partner with Fujitsu. With nearly fourteen months of development work behind them, the SEC is getting ready to make the functionality of Inline XBRL available.
Very recently, Commissioner Kara M. Stein on April 29, 2015 spoke about Inline XBRL while addressing the proposed pay for performance proposed rule.
The current proposal is to have pay versus performance disclosure tagged in XBRL. It is my hope and expectation that this disclosure would be tagged in Inline XBRL once available, which would allow companies to file the required information and data tags in one document rather than repeated in separate exhibits. I understand that Inline XBRL is not yet available on the SEC’s Electronic Data Gathering Analysis and Retrieval (EDGAR) system, but soon will be. When that day comes, Inline XBRL should be used for pay versus performance and all other parts of the proxy statement.
Also on April 29, 2015 SEC Chair Mary Jo White added to the evidence concerning the SEC’s foray into Inline XBRL with the following comment:
Staff is now considering how the use of an “inline” method for providing structured data might improve the filing of financial information in a structured data format. Such a method of filing would allow companies to integrate structured data into their filings containing financial statements, such as the Form 10-K, rather than present it in an exhibit. Eliminating the requirement to file certain structured data in an exhibit separate from the company’s traditional format financial statements may ease filer burden and 2 enhance the quality of the structured data submissions.
The Senate Weighs In
On July 21, 2015, Senators Warner and Crapo authored a letter to Mary Jo White, chair of the SEC, stating that
Most of the corporate disclosures currently collected by the Securities and Exchange Commission (SEC) have yet to be transformed from disconnected documents into open data. In 2014, however, we were pleased to note that you and other Commission leaders promised that the agency would soon make progress in this area, specifically with regard to the considered adoption of inline eXtensible Business Reporting Language (XBRL). We are writing to ask you to provide a clearer view of when such progress may occur.
The letter went on to say
However, because the Commission has continued to require corporate issuers to file two versions of every financial statement –once as XBRL-formatted open data and again as an old-fashioned non-searchable text document- the original goals of the XBRL rule have not been realized.
The senators also note that because there are two versions of the documents, the SEC has continued to focus their reviews of corporate data on the text document version, not the open data version. Senators Warner and Crapo perhaps have not heard of the good work started by Dr. Craig Lewis, and continued under Mark J. Flannery the chief economist and director of the Division of Economic and Risk Analysis (DERA).
Both Lewis and Flannery have used XBRL versions of corporate filings extensively within the SEC for analysis and enforcement identifications. In this writer’s opinion, the idea that if the SEC was forced to use the electronic version for analysis then they would get serious about XBRL quality ignores the fact that they are already using XBRL data.
Setting Things Straight
- Inline XBRL is not XBRL meets TurboTax™
- TurboTax™ and similar software take data entries and apply same directly into authorized IRS forms. Where Inline XBRL will be different for US filings is that there still will be hundreds or even thousands of different acceptable formats that are US GAAP compliant. In other words, fill in the blank does not work because there are multiple ways to represent XBRL and US GAAP for the same item. Just because a human can read a financial statement doesn’t mean the XBRL tags underneath will be correct. All the same due diligence required today will still be required with Inline XBRL.
- Inline XBRL by itself does not improve XBRL quality
- XBRL quality contains three major elements; 1. Technical XML and XBRL validation, 2. Adherence to SEC EDGAR Filing Manual rules, and 3. Valid US GAAP reporting. Asking the user to embed tags into a visual document using iXBRL makes it easier for a user to read the surface financial statement but does precious little to help a document that contains XBRL errors.
- The preparer effort can be saved by unifying XBRL filings into one filed document.
- Not much time saved because all the same matching issues will be present when the underlying XBRL is consumed into analysis software. Companies will still be working to make sure the resulting XBRL faithfully represents their financial reporting.
Inline Definition from XBRL UK:
- Under Inline XBRL, all XBRL data is contained within ordinary, human-readable files. These files are presented in HTML, the format of the web. This enables a single iXBRL report to operate as both a standard set of accounts which may be viewed on screen or printed, and as a file of XBRL ‘tagged’ data which can be analysed automatically by software. An individual company can thus present its accounts in exactly the way it wishes. No additional mechanisms are required to convert an XBRL filing into a human-readable form, saving complexity and cost. A company simply creates its accounts in a normal way and uses software to embed computer readable XBRL tags within the report. The accounts are then said to be ‘tagged’ in XBRL. http://xbrl.org.uk/resources/whitepapers/UKcompanyReporting-XBRL-v1.pdf
Conclusion
The SEC is currently under pressure to improve the usefulness of XBRL filings. Pressure is coming from the Senate and from the investing public asking for simplification and increased quality. Inline XBRL is a small step in the right direction but will not solve the XBRL quality issue. Filers will need the help and expertise of companies like DataTracks who has been ranked as the first and only generator to have crossed the 90% score in quality and who understands XBRL and will help you stay ahead of the curve. If and when the SEC begins to accept Inline XBRL filings, DataTracks will continue to help you create high quality XBRL filings.
DataTracks US is part of DataTracks Services Limited, leaders worldwide in preparation of financial statements in EDGAR HTML, XBRL and iXBRL formats for filing with regulators. With a track record of over 10 years, DataTracks prepares more than 12,000 XBRL statements annually for filing with regulators such as SEC in the United States, HMRC in the United Kingdom, Revenue in Ireland, ACRA in Singapore and MCA in India.
To find out more about DataTracks, visit www.datatracks.com or send an email to enquiry@datatracks.com
The views expressed are that of the author’s and DataTracks is not responsible for the contents or views expressed therein. If any part of this blog is incorrect, inappropriate or violates the IP rights of any person or organization, please alert us at ceo@datatracks.com.We will take immediate action to correct any violation.