Last week I gave a talk at the 16th International XBRL Conference here in Vancouver. XBRL is an XML-based system for packing up companies’ financial information, and I think it’s real important. But its take-off has been kind of protracted and arduous. I was there as an Ambassador From the Web. Here’s a quick XBRL news overview.
Why XBRL? · Right now a huge number of people in the finance business get PDFs of company reports of various kinds and spend substantial error-prone time copying numbers into spreadsheets, so they can think about them properly.
If you package up the numbers in a machine-readable form, everyone can skip that step, which is A Good Thing.
But the big story is the never-ending war between accountants and investors. In any given industry sector, 50% of the companies are performing below average. Historically, they have been systematically dishonest about reporting this; “creative accounting” includes a huge variety of practices for putting reporting lipstick on various parts of financial pigs. Investors, on the other hand, want the truth.
If you have a strict and fairly formal machine-readable wrapper for your financials, that gives investors another club to beat accountants with, which is A Good Thing.
XBRL News · The good news is that the development of all the bits of XBRL you need to do comprehensive US financial reporting is about done, as of last week.
The bad news is that less than 100 big public companies (not including Sun, sigh) are currently reporting in XBRL, and that there isn’t much in the way of tools to, you know, actually do anything with the data. Even view it.
Now, XBRL is complicated, and that’s at least partly because public-company accounting is complicated. It also relies heavily on Linkbases, a piece of XLink technology (disclosure: with some of my fingerprints on it) that hasn’t had much adoption, so there’s not much software out there to do things with it.
I’m actually not too worried. Near as I can tell, the SEC, under the leadership of Chris Cox, is hell-bent on squeezing XBRL out of public companies whether they like it or not; and once that information resource is available, tool-builders will arise to do something with it. The Americans are well along but lots of other governments are taking this bit between their teeth. So, given the existence of the chicken, there will be possibly-golden eggs. Stay tuned.
Contributions
· Business (125 more)
· Technology (90 fragments)
· · Publishing (160 more)
· · XML (136 more)
Comment feed for ongoing:
From: Mark (Dec 12 2007, at 23:05)
I'm kind of surprised that you support XBRL. Whatever happened to YAGNI? Originally it was a nice, tight little spec, but it's grown into a monstrosity like WS-*. It's main purpose now is to be so complex to deal with that you need to buy expensive software and services from one of several large corporate sponsors of XBRL.
"XBRL is complicated, and that’s at least partly because public-company accounting is complicated." I think that's a rationalization. XBRL is trying to boil the ocean and solve world hunger. An 80 percent solution is enough. A 99 percent solution is more than enough. A 99 percent solution would be an order of magnitude less complex than the current XBRL. XBRL only needs to allow high level "diagnosis" -- in the end you have to go to the 10-K or 10-Q anyway.
[link]
From: Bud Gibson (Dec 13 2007, at 04:21)
A year ago, I had some students attack XBRL in a mash-up. The problem was that it was hyper-complex, a sort of standard with many loop holes.
As you point out, financial accounting is really a story of how much obfuscation you can get away with. That runs counter to the idea that a better data format is all that is needed to improve communication.
Instead, I think you'd be better off with a reporting service that digested all the obfuscated crap and emitted it in a standardized format.
[link]
From: Bob DuCharme (Dec 13 2007, at 07:14)
XBRL (which has taken over 7 years to achieve the minor level of adoption that you describe) is second only to W3C Schemas in the number of people it's inspired to say "sure it's complex, but don't worry--there'll be tools to take care of that!" A key problem is that is that it's so customizable and flexible that it's difficult to put together something that can perform similar processing on multiple arbitrary XBRL documents. Compare DITA, which allows two different documents to appear structurally very different, but has open-source software to abstract away the differences to let us treat the documents as having an equivalent structure. (Of course DITA has a simpler, more straightforward domain, so there's no ocean to boil.)
When XBRL has an open source equivalent of the DITA Open Toolkit, I'll be ready to take another good look at it. Until then, as with so many standards, without free software that lets us do stuff with data that conforms to the standard, I don't see much incentive for conformance to the standard, except of course for regulations.
[link]
From: Ross (Dec 13 2007, at 07:48)
Hmm, so XBRL is useful as a club to beat on corporate accountants by those investor/analyst types (and regulatory agencies). Implementing XBRL depends on adoption by ... corporate accountants. Where's the surprise at the slow adoption rate coming from?
@Mark: True "it's complicated" is usually a cop-out, but in the case of corporate accounting, it is complicated, and the cost of getting it wrong is very high: The SEC (and equiv. in other markets) have very big sticks they thwack companies with when they find the lipstick getting a bit too thick. In fact, the SEC saying 'make it so' is probably the only way this is going to get done.
[link]
From: John Turner (Dec 17 2007, at 03:47)
For a long time there was debate about whether this would involve the Chicken-Regulator or Egg-Investor. It's now quite clear that Regulators win. Something about all those clubs they have to beat people over the head with. But expect the Investors to start demanding more and more information in machine-readable, unambiguous and instantaneous form from now on in.
I just want to clarify something for those that don't understand this about XBRL. XBRL is about expressing business reporting semantics in XML, at least as much as about expressing business reporting data in XML.
If we were only dealing with forms, ie: static containers with well defined definitions, then we would have been done a long time ago. As it happens lots of successful implementations, like the ones within the UK (200K+ individual voluntary filings per year from very small companies) and Belgium (300K filings from all companies) and US banking supervisors (all 8000+ US banks every quarter) are complex forms, using XBRL because it provides well described semantics that are capable of dealing with change (a constant in any kind of reporting).
But we are not. The overriding use case for XBRL is the ability to mark-up complete business reports, such as financial statements. This has taken a long time to come to fruition, but it is now happening, with Securities Regulators in the US, Japan and Canada requiring or encouraging listed companies to use XBRL for exactly this.
Every other environment that you are used to dealing with takes for granted that systems dealing with standardised XML messages will have a common understanding of the semantics of the message. With XBRL you cannot make that assumption.
The business need is to be able to convey the easily comparable stuff (90 or 95 per cent of a message) as well as those aspects of business performance that are regarded as unique, or special. That's the way that accounting works, and we are modeling accounting (not changing a 500 year old system that everyone understands).
In practice that means that 95% of an instance document contains facts marked up using elements contained in a base or official taxonomy. Some small proportion will be marked up according to an extension taxonomy, created by the preparer, that the receiving system needs to process, but has never seen before. Typically, this will involve a human interacting with that system, deciding whether to (a) throw away a new concept the next time it is seen, (b) store a new concept because it it useful for a time series analysis or (c) map that concept to some other concept, because in the eyes of the beholder it is not as unique as the preparer might hope. This is only possible because we can express rich definitions inside these machine readable taxonomies.
XBRL is becoming more web friendly: the inlining of XBRL instance documents inside XHTML (similar to MathML and SVG) is proving a popular idea and is the subject of a soon to be released spec being developed largely inside the consortium.
Tim has suggested at three XBRL conferences that I've been at that we should stop. Indeed that some sub-setting is in order. We are not far from stopping. But efforts that have fallen short of the needs of the real world (the millions of accountants out there) have never succeeded in the past. From where I sit, XBRL is succeeding because it is meeting those needs.
Full disclosure: I'm an insider. I run CoreFiling, an XBRL vendor, and am involved in a number of aspects of the XBRL International consortium's governance, including as the Chair of the Standards Board.
[link]