Fixing XBRL
As we close 2015 and look forward to 2016, its time to assess just where we are in the task of creating a viable and vibrant electronic versions of financial reports. If we also include notes to financial statements and all the newly mandate electronic version of mandatory reporting to the SEC, we can see a wealth of data just waiting to feed analysts software programs. The present treasure chest of financial data, if all things were perfect, should be generating breakthrough financial analysis and insight. Think about having the ability to dissect industry segments in seconds for things like trends in operating earnings, increases or decreases in capital spending, leverage increases of decreases and so much more. This was the promise of XBRL when it was first introduced in the early 2000’s. So what went wrong?
XBRL’s Unfulfilled Promise
XBRL as defined by reports filed with the SEC works and it doesn’t. The good news is that XBRL has been a vital part of financial reporting since the first mandated filing back in 2009. The new format was rolled out in phases so that both reporting companies and software vendors could adjust to the requirements while the system evolved. Just as financial reporting teams had to change to reflect the new requirements, the SEC evolved its rules and its acceptance software to eliminate obvious errors. Software vendors have kept pace, leading the way to producing higher quality XBRL filings to the SEC. Still something is missing.
Jo Guo, Head of Fundamentals, Equity Data Operations, Morningstar investment research gives several interesting observations about Morningstar’s use and non-use of XBRL data. While Morningstar takes full advantage of XBRL data used in reporting in both Taiwan and Japan, they have elected not to use XBRL data sent to the SEC. The reasons include:
- Inconsistencies with the use of HTML
- Missing/erroneous values
- Unmanageable taxonomy
- Too many extensions
- Value inconsistencies
The inconsistency of HTML stems from the fact that companies are still required to report in both HTML format and in XBRL. Management needs to take extra measures to ensure that both versions of the filings with the SEC are consistent. Missing or erroneous values are a quality problem because neither the SEC nor the software used to prepare XBRL filings are set up to look for errors of omission or for amounts that are clearly out of a normal reporting distribution (trillions instead of millions). The unmanageable taxonomy comment begs further explanation from Morningstar. US GAAP is complex and extremely deep. Taxonomies that attempt to capture both depth and complexity need to be rich and robust or they will not work as intended.
The extension issue is real. Financial software that is built to consume XBRL data needs to understand both the meaning and intent of a data element. If the extension needs human intervention, the advantage of the metadata backing up XBRL elements is lost. As for value inconsistencies, the present method of checking validation only allows egregious errors to enter into the SEC database. The software receiving the filings must learn to do some basic audit checks to ensure that major errors will not pass into the system. All too often the technical side overweighs the accounting and silly errors that are obvious to the trained human eye pass into the system without a blink.
Recently PriceWaterhouseCoopers (PwC) published a report on the XBRL submission process. The front page summary included the following:
- With the chicken-and-egg problem of XBRL out of the way, users -and- uses of XBRL-formatted financials are increasing. But users are finding that report quality varies wildly.
- Report quality is management’s responsibility, and it cannot be delegated; but management is relying on vendor’s promises of automated validation.
Agreeing that there is an XBRL problem with report quality, PwC concludes that “Pervasive XBRL report quality problems can and should be overcome.” The answer (according to PwC)? Plan, train, involve management, benchmark, and insure that new guidance, best practices and adequate controls on the process are firmly in place.
The CFA institute on November 4th 2015 hosted an XBRL open panel discussion entitled “Improving Financial Analysis through Structured Data” where panel members addressed the US XBRL inconsistency issue. Companies represented included Bloomberg, Credit Suisse, S&P Capital IQ, and the CFA Institute. Bloomberg stated that they are just now, in late 2015, beginning to use XBRL data generated in the USA. Credit Suisse indicated that they are not using US XBRL data due to the high error rates and inconsistencies inherent in the US SEC filings. S&P Capital IQ said they are using US XBRL data today but it requires human intervention to work out the errors prior to use. Every panelist agreed that XBRL data was in far better shape in Korea, Japan and other non-USA markets due to the use of standard taxonomies that do not allow extensions.
Could we substantially improve XBRL by disallowing extensions? Panelists would not support that assertion due to the complexity and variation permitted in US GAAP. Each panel member held out hope for the new XBRL US quality initiative as a means of eliminating errors that will improve the usability of XBRL. Although additional guidance and quality check rules will help perhaps we need to take a fresh look at how to keep the complexity of GAAP but at the same time eliminate the inconsistencies. I will leave that juicy topic for a future blog.
What’s Next?
For SEC filers using software providers such as DataTracks the path to improvement is simple, stay the course. Our quality ratings continue to climb as measured here. Consistently reducing reporting errors including basic accounting checks will help management teams to achieve even higher levels of XBRL quality. The DataTracks family will consistently lead the pack with high quality XBRL filings now and in the filing seasons ahead.
About DataTracks: 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.