Two years ago we started work on a little experiment to see if XBRL could be used to build a standardized financial dataset with minimal dependence on human collection. If possible, this would potentially be the biggest development in financial data since John Moody wrote the first Moody’s Manual in 1900. For the past 113 years data has been collected manually and, as a result, this data (a) has not been very timely and (b) is prone to input or classification errors.
Two years into this experiment we’re making good progess but the road has been full of diversions and dead ends. We’re in the process of mapping every filer’s financial statements to our standardized dataset and during this process we’ve learned a lot about XBRL, its strengths and weaknesses. (Note: these comments are based on our experience with XBRL data from the SEC since that has been our focus to date.)
Strengths
One of the clear strengths of XBRL is the potential to reduce data collection times and costs, both of which are critical to democratizing financial data while opening it up to new uses and users. Once a company is mapped to our standardized dataset our system is capable of converting an SEC filing into usable, standardized data within minutes of the filing. With this unprecedented timeliness it would be a shame to see XBRL not be required for all earnings releases and proxies given the heavy demand for this time-sensitive data. I believe this expansion of XBRL into time-sensitive information should be one of the biggest priorities in the XBRL community. Playing to your strengths is required for success, and delivering time-sensitive data is XBRL’s killer app.
Data comparability between filings is also a key strength of XBRL. Companies have been fairly consistent in their selection of tags between filings which makes comparing data across periods very effective. This ensures that our company-specific maps are delivering consistent data to the investment community.
Weaknesses
A lot has been mentioned lately about the quality of XBRL data. We’re actually reasonably happy with the quality of the data for a technology at this stage of its life-cycle. That said, we do run into errors, each of which require an analyst to troubleshoot why the quality assurance checks were not achieved. This extra time spent by an analyst delays the delivery of data to the investment community which is bad for both the filer and for a market that is based on information.
When we identify a material error in an XBRL filing we notify the filer through their investor relations contact and ask them to forward the issue to the appropriate person. We do this not to scare the filer, but to make them aware of the issue so that future filings sail through our process and into the hands of the investment community. The most common error we’re seeing right now is with the account types used in the cash flow statement (ex. debit or credit) not being consistent with their presentation. For example, if a filer presents a positive value for an operating cash flow item in their HTML filing they are presenting that this is a debit to cash. However, if they use an XBRL element that is a credit account type and leave the value in their instance document as positive it will calculate as a reduction to cash instead of an addition to cash. To fix this, we manually “flip” the sign so that the cash flow statement is accurate. This is something that each filer or service provider should spend more time validating. We’re seeing this issue occur with large and small filers, with some of the former having been filing XBRL financials since 2009.
Another weakness we see with XBRL is its user friendliness, or lack thereof. It’s taken us two years to develop a system capable of converting XBRL into usable and standardized data on a reliable basis. While this steep learning curve is a good barrier to entry for our company and will likely encourage data consumers to use our data instead of collecting it themselves, we want to see XBRL succeed. If we are one of only a handful of companies using XBRL data, the data we are using to build our company is not likely to be around in 10 years. The technology required to re-create a core financial statement such as a balance sheet is not an elementary task. In order to identify which statement is the balance sheet requires one to look at various pieces of the filing. Our development time would have been reduced dramatically if, among other things, filers were required to identify their core financial statements in a standardized fashion.
Taxonomies are creating another challenge with using XBRL. We believe the sheer size of the taxonomies are actually detracting from their value. Virtually identical companies are often not comparable because very few of their tags overlap or because the filers are choosing to use extended concepts. During our standardization process each of the more than 18,000 concepts in the US GAAP taxonomy as well as every extension used in the core financial statements are mapped to one of our 500+ standardized items spanning 6 industry-specific templates. The delay in adding IFRS filers into the mix is also concerning to us. Instead of requiring each filer to select tags from these often overwhelming taxonomies, we believe a better approach would be to require the filer to simply use unique descriptive codes for each item in their filing, placing the burden of classification on the end user or data company. This would make the US GAAP vs. IFRS taxonomy argument a moot point while reducing the burden placed on both filers and regulators. In addition, we believe this taxonomy-less approach will accelerate global XBRL adoption with little downside since comparing companies already requires substantial effort from the end user, even for virtually identical companies (ex. Mastercard and Visa).
The last issue we are seeing with XBRL is the lack of consistency between the data structures required by the regulatory organizations. As a result of this inconsistency, adding another country to our database will be a major undertaking instead of the proverbial flip of the switch. The leading regulatory organizations should work together to merge their requirements and structures which will ultimately make XBRL the de-facto global standard for financial reporting. Better standards between regulators will reduce the time and effort required to deploy XBRL, ultimately accelerating the global deployment of the technology. In addition, regulators should work together to standardize the entity IDs of the filers to allow for better comparison. Mapping the various entity IDs (ex. tickers, CIK numbers, etc.) with other data sources is another barrier to widespread adoption and cross-comparability between countries.
The Second Inning Stretch
Even with these challenges XBRL has come a long way in recent years, but it’s clear there is still a long way to go. I believe we are in the second inning of the game. Here is something to help put that statement into perspective. Next month will mark the 4th anniversary of the SEC’s XBRL mandate. Imagine how much advancement has occurred in microprocessor since 1972(1), four years after their invention in 1968. Imagine how far airplanes have progressed since 1907(2), four years after the Wright brothers’ first flight in 1903. XBRL is still in its infancy and the next 10 years will determine the technology’s long-term trajectory. If we work together to leverage XBRL’s strengths while addressing its weaknesses, there is no stopping the spread of timely, accurate and transparent financial data.
(1) In 1972 Intel released the 8008 microprocessor with a speed of 0.5 MHz. In 2013 Intel will release their latest microprocessor with a speed of 3.5 GHz and 4 cores, 28,000 times more powerful than the 8008.
(2) In 1907 the world records for an airplane were an airspeed of 37.85 mph, range of 24.2 miles, and a maximum altitude of 82 feet above the ground. In 2012 Gulfstream announced the G650 which is capable of traveling 7,000 miles at mach .85. This is 292 times the range of the 1907 world record at 15 times the airspeed.