The Inline XBRL specification will go to recommended status in the next few weeks. Over the last three years we’ve been very busy in this field: coming up with Inline XBRL, prototyping it, and designing the specification. Then nursing the Specification through the standards-setting processes, testing it exhaustively and improving it along the way. Working in collaboration with a number of other vendors, as well as a number of key projects around the world, not to mention implementing it in our own software, seems to have consumed an awful lot of time at CoreFiling. However, it is just the end of the beginning. In fact, it begs the question: Why use Inline XBRL? I thought I’d set out a few ideas here.
Fundamentally, Inline XBRL provides a way of intermingling XBRL with an HTML document. You lay out the information in HTML, whatever way you like. Want that table in 8 point, right justified, Comic Sans? In green? HTML has got you covered. The facts, though, are wrapped up inside Inline XBRL instructions. Let’s say the document says “Tax deductible donations to the Society for the Prevention of Facial Wrinkles, €3,000”. That amount can be wrapped up in an instruction that says, in effect, “The IFRS concept that marks up ‘3,000’ at this point is Charitable Donations”. In addition, there are some further instructions that point out that the amount is in Euro, relates to 2010 Q1, and that it is being made by ACME Corp. All of that information is hidden from the person who reads the web page. It can be used (together with the value 3,000) and converted into valid XBRL by the systems that consume the web page.
So, to go back to the question again, Why would you want to use Inline XBRL?
Here are a few reasons:
- Incorporate company-specific formatting decisions
- Easily understood by preparers
- Easier for Accounting Software Vendors to implement
- Simplified review, improved control
Over the next few days, I’ll post a short entry about each of these reasons for using Inline XBRL.