Thursday, December 19, 2013

Good Intentions are Not Enough: The Problem of SEC Mandated XBRL Reporting

Public companies have been required to supply financial reports since the Depression, but gathering and analyzing this disclosure has had its challenges. In the 1990s, the SEC began uploading 10-K’s and 10-Q’s to the internet, greatly simplifying the data collection task. These electronic reports were not standardized, creating the need for downstream users to write complex parsing algorithms and/or use manual processes to harvest the financial statements.

In the late 1990s, accounting and technology firms devised a standard called XBRL – eXtensible Business Reporting Language – to streamline the data acquisition process. XBRL disclosures rely on a common system of tags that consistently identify financial statement elements. The universe of elements differ amongst accounting standards, such as US Generally Accepted Accounting Principles (US-GAAP) and International Financial Reporting Standard (IFRS). An XBRL taxonomy lists all the acceptable financial statement elements for a given accounting standards.

Beginning in 2009, the SEC started requiring public companies to file 10-K and 10-Q disclosures in XBRL using a US-GAAP taxonomy – maintained by the accounting community and approved each year by the SEC.

Recently, I worked with UK-based OpenCorporates to gather SEC XBRL disclosures and harvest data from them. The goal was fairly simple: walk through all the XBRL documents and gather some basic parent company data points (like total assets, total liabilities, total revenue and net income) for the latest fiscal year from these disclosures.

This task proved surprisingly difficult because of a lack of standardization between XBRL documents from different companies. For example, many companies did not report a value for Total Liabilities. One might “back into” this value by subtracting Shareholders’ Equity from Total Assets, but this doesn’t always work. A small percentage of XBRL reports even lacked a Total Assets field. On the income statement side, the dispersion was even greater, with Total Revenue, Operating Income and Net Income often unavailable.

Finding data for the latest period also proved challenging. XBRL files can contain numerous contexts. Each context refers to a reporting period (e.g., a particular quarter or year) and a scope – which may be the parent company or a particular segment of the corporation (e.g., a subsidiary). Contexts contain period elements and an optional segment element indicating which timeframe and what scope the context covers. To find the latest year’s parent company data, it is necessary to develop a program to walk through each context.

These examples suggest that processing SEC mandated XBRL disclosures is less than straightforward. Indeed, the industry group XBRL.US reports finding 1.4 million errors in the universe of XBRL documents filed thus far.

A recent letter from Darrel Issa (R-CA) to the SEC notes that the agency itself is not using the XBRL files it requires corporations to file. Instead, it continues to rely on commercial data aggregators. Electronic disclosure won’t improve unless numerous eyes are scrutinizing it and reporting issues. Data sets need to be exercised; otherwise they remain unfit.

The lack of XBRL utilization represents a major threat for transparency advocates. If we ask for more accessible disclosures and then don’t use them, filers can be expected to push back. In the case of SEC XBRL, the filings are sufficiently complex to require the use of third party XBRL submission firms. In other words, it is too difficult for most companies to prepare XBRL submissions themselves – they need to use an independent preparer, just as individuals often need to hire professionals to file their annual tax returns. Corporations would undoubtedly like to economize on this cost, and can be expected to resist the XBRL reporting requirement if the filings are not used.

From my perspective, a big problem with the XBRL rollout is that it started with large public companies. By 2009, many data aggregators already had mature processes for assimilating the traditional SEC disclosure. As a result, fielded public company financial data has become a commodity; individuals can access these data for free at Yahoo Finance and many other portals. The incentive for aggregators to use XBRL is thus limited because the problem has already been solved at some level, and because the data are widely available, there is little benefit to potential new entrants.

XBRL can provide much greater benefits for data sets that have not received as much attention. I became interested in XBRL back in 2001 because I was hoping to get a standard source of private company data at my bank. The idea was to provide unlisted corporate borrowers with an XBRL template to provide quarterly disclosure.

Another high impact application for XBRL is state and local government financial reporting. When XBRL was growing up in the 1990s and 2000s, US municipal bonds were generally perceived to be safe. That perception started to change in 2008 with Vallejo’s bankruptcy filing and the collapse of the municipal bond insurance industry. Subsequent municipal bankruptcies culminating with that of Detroit in 2013, have reinforced the perception that municipal securities are risky. Government financial statements, which may have been ignored previously, now have significance as investors search for the next bankruptcy candidates.

However, the rollout of XBRL to other areas – such as local government – may now depend on its successful implementation in existing areas: especially the high profile SEC US public company application. If the SEC is unwilling or unable to engage, the community would be well served by collaborating to implement its own improvements. Although XBRL filing companies compete with one another, they all have an interest in the success of the XBRL standard. Thus, as an industry group, these companies can propose and implement improvements to SEC XBRL filings that will make them easier to use. For example, they can develop an enhanced XML Schema Definition which provides additional checks over and above those legally mandated. Such a schema should ensure that filers always include common financial statements such as Total Assets and Total Liabilities. It should also ensure that, within any given XBRL file, the latest period’s parent company filing is easily identified.

XBRL was and remains a good idea. Transparency advocates need to ensure that it does not become an idea whose time has come and gone. To keep XBRL on track, its public company instance needs to be refined so that implementation costs are reduced. Further, it needs to be applied to other areas – such as US local governments – which stand to gain greater benefits from its adoption.

No comments: