Friday, 12 August 2011

XBRL and Me

Right from the early days of collecting data, I could imagine a time when data would be extracted automatically from annual reports for analysis. Back then I assumed this would be achieved by clever machines using OCR and AI techniques (Some of the software I've built recently has attempted to use similar methods). In those days, we didn’t sell structured data, just standardised financial statements and ratios on bits of paper. The widespread adoption of computers allowed for the migration of this standardised data into structured databases. But often you were putting square pegs into round holes. Our solution was to expand the data set, so whatever was reported could have its own "hole", to create the world’s first as reported database. In practice, it only had 1600 data items (compared to nearly 16,000 tags in the XBRL US-Gaap Taxonomy!) so the description "as reported" was always stretching it a bit, but we were applying that old 80:20 rule and so more often than not a data item was as described. We even had an equivalent of company defined taxonomy extensions, where if a data item didn’t fit, it would be stuffed into a tagged “other” item (ensuring it all still added up) and broken out in a custom labelled table.

To cut a long and rather dull story short, I love the thinking behind XBRL. It’s a great idea. I have though become more than little curious with regards to it's implementation.

Thursday, 4 August 2011

Why was XBRL invented?

"Progress isn't made by early risers. It's made by lazy men trying to find easier ways of doing something" - The science fiction writer, Robert Heinlein


Before the advent of XBRL, comparative analysis would require the mass re-keying of data. As a man who once did this for a living, it's a enough to make you want to roll over and go back to sleep! Not only is it laborious, it's error prone, expensive (we did like to get paid!) and time-consuming (leading to long lags between publication of company financial data and it appearing on a screen near you). The Architects of XBRL were trying to solve these problems and also eliminate one further stage, invisible to user, in the production of accounting data - the transfer of the data from the accounting system to the prettified published accounts. Indeed in the science fiction world of XBRL, the numbers in the back office accounting system may not have been keyed in at all but arrive in the form of an XBRL enabled invoice.

So as ever, it's about saving time and money with the added advantage of being able to have greater confidence in data which has been untouched by error prone human hands.

Tuesday, 2 August 2011

Why XBRL for Analysis?

The purpose of this blog is to record my thoughts and observations about the usefulness of xbrl published data in the process of preparing company data for investment or credit analysis and in so doing aid those considering the use of xbrl data in their analytical models. Is it the panacea that it's proponents claim or does it fall short? I've started this blog now because as of today 2,106 US companies have filed xbrl data so we are quickly reaching a point where comparative analysis of xbrl data becomes a valid option.