Introducing Inline XBRL
Last week marked a momentous change for the UK accounting industry. On April Fools Day 2011, it became mandatory for UK companies to report their statutory accounts and tax computations in a new format called Inline XBRL. This change transformed the way in which organizations report to HMRC in one fell swoop, simultaneously ending the centuries-old practice of filing on paper and unsanctimoniously booting PDF filings out of the door (except in very particular circumstances). As of now, every company in the UK must file electronically using a structured data format.
Inline XBRL, otherwise known as iXBRL, is an incredibly elegant solution to financial reporting. A derivative of XHTML, iXBRL allows users to produce human-readable documents that can be rendered in web browser while also allowing them to embed additional structured data. When processed by a compliant processor, an iXBRL document is transformed into an XBRL instance document–a format used by governments, regulators and analysts worldwide. For those of you that don’t work in the world of financial reporting, iXBRL really is a very neat option: the very same data that is read by human eyes can be transformed into an XML-based machine-readable format by any iXBRL compliant processor, allowing a single source document to be used by analysts and BI tools alike.
For the average user, iXBRL means that the documents seen on-screen are comparable to the Word documents, Excel documents or even PDF documents which they are replacing (and in many cases, the documents from which they were generated). Provided it doesn’t hinder machine-readability or require duplication of data, this familiarity can only be a good thing. The fact that iXBRL also hides away the hideous angle-bracket-and-slash-infected nature of XBRL doesn’t hurt either. XBRL may well be a great format which is ideal for consistent, comparable, and processable financial reporting, but it’s miles away from anything an accountant would actually want to use or understand.
On a global scale, iXBRL is going to be a big deal primarily because it solves the kind of problems that the US have been enduring for years. The largest corporations in America have to file their 10-K and 10-Q reports to the SEC, but they have to file two copies of their returns: one in XBRL format, and one in HTML format. One provides structured data, and the other merely allows the analysts who have been relying on readable returns for decades to continue doing their jobs. This leaves us in a horrible half-way house, with duplication of effort (and data!) plus a boring, tiresome job comparing the two documents to ensure that they are consistent. Worse, it means that everyone can ignore the XBRL filings for a few more years and work with the same HTML EDGAR filings they’re already comfortable with–reducing the impetus for companies to produce high-quality XBRL returns.
In the UK, the sharp charge to iXBRL has delivered all of the benefits of HTML and XBRL formats while cutting out the drawbacks of being forced to prepare both. I’d be willing to bet that even though the UK is the first country to make the leap to iXBRL, it won’t be the last.
Welcome to the world stage, iXBRL. You’re a welcome addition to the stable of financial reporting formats, and I bet you’ll also be one of the most durable.