Two years ago I wrote an unflattering report on XBRL (eXtensible Business Reporting Language), an emerging standard that aims to improve the speed, accuracy, and transparency of business and financial reporting. I applauded its goals, as we all should in the wake of Enron and other scandals, but worried about the complexity of the 151-page XBRL specification, its aggressive use of esoteric features of XML, and its reliance on accounting "taxonomies" defined by committees.
I've too often seen these kinds of ambitious efforts stumble and give way to simpler approaches. SGML gave way to XML, for example, and although XML itself offers many advanced features, its most successful application -- RSS -- uses none of them. Would XBRL wind up being used mainly by what one wag called a "master race" of consultants and accountants?
I received several excellent responses. In an exchange quoted on my blog, David vun Kannon, one of the editors of the spec, noted that the problem domain that XBRL tackles is inherently complex.
Carol Brown, who teaches accounting at Oregon State University, agreed. "For accountants, 151 pages is nothing," she said, adding that because XBRL has the backing of a consortium of heavyweights in the accounting world, and because regulators have the power to mandate use of XBRL, its broad adoption was more likely than I gave credit for.
It seems she was right. The FDIC's XBRL mandate, which went into effect last October, has produced dramatic speed and accuracy benefits, according to a white paper from the Federal Financial Institutions Examination Council. And other countries, including Germany, South Korea, and Australia, lead the U.S. in XBRL adoption.
To update the story I invited Brian DeLacey, a former Harvard Business School researcher whose company delivers XBRL solutions, to join me for one of my Friday podcasts. Brian in turn invited Charlie Hoffman, the CPA who invented XBRL in 1998. Today, Hoffman continues to evangelize XBRL and, as a director of UBMatrix, helps develop software to implement it.
We had an excellent conversation from which I took away three key points. First, XBRL aims to capture not only the vocabulary and syntax of business reports but also the semantics encoded by standards such as GAAP (Generally Accepted Accounting Principles) and IFRS (International Financial Reporting Standards). Plans that require groups to agree on taxonomies tend not to succeed. But thanks to regulatory pressure and the will of cooperating entities to prevail, this might prove to be a welcome exception to the rule.
Second, Charlie Hoffman's vision encompasses more than just frictionless exchange of data. To the extent that domain knowledge can be represented in XBRL, every accountant who uses XBRL software has access to world-class expertise. That's a dream worth pursuing.
Third, Hoffman and others don't dispute XBRL's reputation as a complex beast, and they hope to tame it with better tools and education. There's a huge opportunity for an open source XBRL engine, so vendors can focus more on authoring, analysis, and reporting applications. On the education front, we agreed that more emphasis on modular and incremental adoption of XBRL would be helpful.
Color me a skeptic, still -- but now I'm a cautiously optimistic one.