XBRL: mash-ups for accountants

This first appeared in Techleader, June 2008

I’m grateful for search engines, but I still find it hard to accept living with Dead Text. Letters and figures on a screen. Not able to be mined, found, unlocked, extrapolated into meaning. What irks me in particular is tables of figures, especially financial information, that you would have to re-key into excel or some ERM system to actually use. The web is two way traffic, and in age of openness about data (open source, openID, APIs etc) it rankles me that business information is locked in a bordered, left-aligned and decimalled cage.

All the financial information offered by companies to the markets tends to be of this nature. Analysts and journalists will get the printed annual report or results announcement and ofttimes have to re-key the figures in to develop scenarios and what-ifs. The announcements that listed companies file with the JSE Stock Exchange News Service (SENS) are submitted and viewed as ASCII text. Open Notebook (on a PC), throw an income statement in there and send to the guy who does your tax: it’s brain dead on usability and minimal on usefulness.

XBRL (eXtensible Business Reporting Language) is the format that will fix this. About 10 years in the making, it essentially enables all accounting jurisdictions (read: countries on a local level, and GAAP and IFRS on a macro level) to define their own taxonomy and map every single item in their ledger or statutory reports with a pre-agreed tag.

For developers: It’s XML, where the schema is the accounting taxonomy. Your XML doc is your financial statement, and the elements are pre-agreed tags with the values being, well, the figures.
For accountants: It’s choosing line-items from an agreed list and mapping them to your figures. And SAICA has endorsed it. Oh, and SARS too.
For other knowledge workers: Text in Notebook has no structure or meta data with it. But, in Excel, it at least has co-ordinates (eg: A3:C1) and may be part of a sum or total. If you do not prepare financial statements, it will probably be underlying your SAP, Oracle or even your general ledger.

Because every figure in your financial statements has an underlying tag, and is referenced in a structure, guess what? You have an API (application programming interface). This allows one to build middle-tier programs that can slice and dice these financials and make them jump through hoops. The business implication is impressive. It means that, through collating and comparing, XBRL-prepared financials, business and investment analysts can compare hundreds of companies where they previously only had time and resources to follow the top leaders in the sector.

China, having mandated XBRL years ago, is now in the pretty situation of having its companies analysed and earmarked for investment in New York and London, because XBRL allows you to compare statements done in different accounting jurisdictions.

Great strides have been taken in South Africa with XBRL South Africa. Recent changes in US listing policy means those South African companies listed in the States have to start filing as XBRL. Not a simple task, remember: you’re now filing XML as opposed to ASCII. It will roll out in South Africa in time, given the JSE’s enthusiasm.

This could open up new markets to companies who prepare their financials, as a matter of course, in XBRL. It could also bring the skills of PHP cowboys to bear on creating viewers and mash-ups and richer documents, and lend some impetus to the Enterprise 2 ideal.

About Derek

My key interests are online investor relations, websites, social media, enterprise 2.0 and intranets, and XBRL. Speak to me if you need a solution in any of these disciplines, or follow my knowledge links on this site and others. Find me on Twitter, LinkedIn or in recent conversations.