XBRL: A case study in complexity

Accounting isn't my strong suit. So I read Following the Money to learn what a team of financial academicians think really happened with Enron and WorldCom, and what should be done about it.

Accounting isn't my strong suit. So I read
Following the Money to learn what a team of financial academicians think really happened with Enron and WorldCom, and what should be done about it.


The Enron Failure and the State of Corporate Disclosure, the book introduced me to a realm of standards wonkery that's way outside my comfort zone. Will the Financial Accounting Standards Board (FASB) merge US GAAP (Generally Accepted Accounting Principles) with the International Accounting Standards Board's (IASB's) IFRS (International Financial Reporting Standards), or will IFRS instead supersede GAAP? Beats me. Web services has nothing on these guys when it comes to slinging acronyms.

I reached more familiar ground when I read the authors' recommendation that XBRL (extensible business reporting language) should play a crucial role in future reform. Their proposed regulatory initiatives include "encouraging, possibly requiring, public firms to file their financial statements, prospectuses and other relevant information in XBRL formats in order to accelerate the use of XBRL by companies, investors and analysts."

Speedier information flow, transparency -- what's not to like? I wonder, though, if the authors have actually read the 151-page XBRL spec. Here's a taste:

"4.10 Equality predicates relevant to detecting duplicate items and tuples. There are several different senses that are relevant to detection of duplicates in XBRL instances: Identical, Structure equal (s-equal), Parent equal (p-equal), Value equal (v-equal), (XPath)-equal (x-equal), Context equal (c-equal) and Unit equal (u-equal). These different equality predicates are polymorphic and formally defined in a recursive fashion. They are all symmetric predicates, ie the result of X (predicate) Y = the result of Y (predicate) X."

Uh-oh. I thought BPEL4WS (business process execution language for web services) was a brain exploder, but it's a walk in the park compared to this stuff. The XBRL spec describes how the parts of an XBRL instance interrelate, using state-of-the-art XML technologies such as XLink and XPointer. And it talks at length about the syntax and semantics of "taxonomies" that abstractly define chunks of financial reports. No sign of any actual financial data, though. And the link to a sample page at xbrl.org, returned a "404 Not Found". I'm not surprised. The poor bloke whose job it was to produce that sample must have suffered a polymorphic recursive brain meltdown.

This isn't what the authors had in mind when they endorsed XBRL. They're right to point out that financial data published on the web today in HTML and PDF formats resists transformation and analysis. And they're right to say that "XML permits the tagging of individual data elements, and thus allows the users to rearrange or manipulate them". But you can't get from the Model T of today's HTML and PDF reports to the intergalactic cruiser of XBRL in one turn of the evolutionary crank.

Consider RSS. In 1999 I published my first RSS feed. It was (and is) an XML format so simple that I could (and sometimes still do) write it by hand. Five years later, RSS is wildly popular, as XML formats go. But hordes of people who should be using it have yet to figure it out. If the RSS spec looked like the XBRL spec, nobody ever would -- except vendors who regard Sarbanes-Oxley financial compliance as a growth industry. If we really want transparent data flow, let's keep it simple.

Udell is lead analyst for the InfoWorld Test Center.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags Development ID

More about EnronWorldCom

Show Comments