In Depth XBRL logo

Published on November 6th, 2013 | by


XBRL: How to Save a Good Idea from a Bad Implementation

If the problems with the U.S. Health Insurance Marketplace website have taught us anything, it is that implementation problems can overshadow the good ideas underlying government initiatives. The same problem is occurring right now with the Securities and Exchange Commission’s (SEC) adoption of XBRL, and critics must take care not to reject the idea of open financial reporting standards in light of a flawed implementation.

Publicly-traded companies must disclose financial statements to the SEC on a quarterly basis.

These disclosures include a wide range of variables, such as income, expenses, investments and cash flow. The SEC uses these reports to monitor activities and enforce U.S. securities laws against fraud, insider trading and other financial crimes.

In an effort to modernize these disclosures, the SEC mandated in 2009 that companies must submit their electronic filings in both plain-text as well as XBRL format. XBRL, which stands for eXtensible Business Reporting Language, would allow the SEC (along with investors, analysts and other government agencies) to conduct data-driven analysis of business filings, cutting transcription costs and enabling better fraud detection and smarter investments.

However, the SEC’s XBRL adoption has been marred by the fact that the XBRL filings are not audited like the plain-text filings. As a result, investors and analysts consider the XBRL data to be more error-prone and less reliable than plain-text filings and so they still rely on the ordinary filings. Moreover, some users, such as investors and analysts, are hesitant to switch to XBRL because they lack easy-to-use analysis tools for the data, and they do not want to incur the costs of developing ad-hoc technical solutions

The root of the problem is that the SEC does not consider the XBRL filing the authoritative filing by a company. Since the SEC was not penalizing companies for making errors in their XBRL filings, companies had no incentive to devote attention to the critically important machine-readable data releases.

These complaints can all be addressed through prudent policy revisions on the SEC’s part. First, the SEC should eliminate plain-text filings by 2015. The longer-term purpose of requiring machine-readable filings is to enable computer-aided analysis and searching, not simply a supplement to plain-text filings. This will only occur if XBRL filings are mandatory. Second, the SEC should begin immediately subjecting XBRL to the same level of auditing as plain-text files and require companies to correct XBRL errors as they are discovered. Third, the SEC should expand the machine-readable reporting requirement to include more types of filings, thereby expanding the range of data available and encouraging users to develop easy-to-use analytical tools that will in turn foster greater data usage.

Government agencies of all stripes should learn a lesson from the SEC’s XBRL difficulties: an exclusive focus on releasing data overlooks other important data policy issues such quality and adoption of standards. Otherwise, it is just “garbage in, garbage out” and the good ideas behind better use of data in government may end up going to waste.

Tags: , , , , , ,

5 Responses to XBRL: How to Save a Good Idea from a Bad Implementation

  1. plega says:

    There is no doubt that the SEC should be doing more to test and enforce data quality. However, the irony is that academic research into the corpus of SEC filings data shows consistently that data extracted from the XBRL is MORE accurate than data pulled together from conventional sources by the big online investor sites. So the answer seems pretty clear…

    • Travis Korte says:

      Certainly agreed that the answer seems clear. This post mostly addresses those stakeholders are already nervous about data quality pre-aggregation, though.

  2. David Vun Kannon says:

    I agree with ‘plega’, who I assume is Phillip Allen of CoreFilings. The article mistakes the alternative to direct use of XBRL. It is not the HTML filing, it is CompuStat or some other intermediary’s database. The irony is that some of these intermediaries are moving to using the XBRL and then selling the result. But it is correct that at this moment there is academic reseacrch showing higher level of error in commercial databases than in the XBRL. I discuss an example of this on my blog at and subsequent posts.

    Filers are legally liable for mistakes in their XBRL. This does make for an odd situation in that the XBRL is not included in the audit opinion. Of course, there is no audit opinion on quarterly filings, but there is still XBRL, so just including the XBRL in the audit is ot going to help much.

    Saving XBRL at the SEC is a matter of expanding its use and improving the rules. There are other filings, such as the 14D proxy statement and the 8-K earnings release, that would be eas to tag and greatly benefit the market. The current enforcement of quality rules should be tightened, and the SEC should work with the FASB on simplifying the core US GAAP taxonomy, which offers a confusing number of choices for basic elements.

    As the main author of the XBRL spec, I am well aware of its problems and the problems of most implementations. They are small compared to the alternative.

  3. David Vun Kannon says:

    Another point that hinders the call to make the XBRL the authoritative version of the filing (and not simply an exhibit, as it is today) is that the XBRL does not tag the entire filing. In the 10-K, the very important Management Discussion & Analysis is not tagged. Tagging the MD&A is a prerequisite to making the XBRL the authoritative source. It can be done.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top ↑

Show Buttons
Hide Buttons