In my last blog, I posed the question Why use Inline XBRL? Of course, one of the key reasons is that you can incorporate company-specific formatting decisions in your report.
Inline XBRL allows people that want to get a business report across to one or more users, to format that document in exactly the way that they want. This might seem obvious but, to be honest, when XBRL was first being designed this very important – human – aspect of business reporting was not really captured. Most XML standards assume that it’s important to separate data from the rendering rules. That’s fine for an XML-based SWIFT standard that transmits information about a payment or receipt of monies, or a format like UBL, which allows the exchange of information about invoices, purchase orders and goods delivery. But business reporting actually involves not just the facts and figures but the way that information is presented. The vitally important thing for those producing the report, and indeed for many of the people consuming it, is the way it is laid out…
So Inline XBRL allows just that: XBRL business reporting with full visual fidelity.
Make sure you come back tomorrow, for the next motivation for using Inline XBRL: it’s easily understood by preparers.
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.
First of all – do you want to know what Inline XBRL is? Have a look at this article, or this article written by Andy Greener.
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.
Earlier this week XBRL International’s Rendering Working Group published the Proposed Recommendation for Inline XBRL. The standard is now on a track which will reach Recommendation by the end of March, in good time for HMRC’s Corporation Tax filing service to go live in the autumn.
Inline XBRL – or iXBRL – will be required for most of the Corporation Tax returns after April 2011. And, down the road, we expect Companies House to mandate iXBRL for filing of Accounts. What will this mean for the companies who have to file ?
I don’t think that the UK is going to see joint filing – making a single filing which will handle both Companies House and HMRC obligations in one go – for some time, if at all. Current legislation provides different filing dates for the two agencies and different filing content. Thus, for instance, companies which are allowed to file Abbreviated Accounts with Companies House will generally need to provide full income statements to HMRC.
But Inline XBRL does provide a neat way to simplify the filing.
Inline XBRL is an HTML document – a web page, if you like – which contains extra information, the extra information that you need to convert the data you see in your browser into an XBRL report. But financial reports are sometimes so large that they won’t fit into a single HTML document. So an iXBRL filing is allowed to consist of, potentially, a series of related HTML documents. This complete “document set” is used by the government agency to generate a single XBRL report.
Inline XBRL doesn’t mind much what goes into each part of the document set, so long as all the information is there. Equally, it doesn’t stop individual components of the document set from being complete document sets in their own right. In simple terms, iXBRL document “A” might be an income statement, and iXBRL document “B” might be a balance sheet. Together they would represent the full Accounts required by HMRC. Document “B”, on its own, would represent the Abbreviated Accounts required by Companies House.
In a world where major accounting firms routinely download clients’ Accounts from Companies House to make sure they have the correct version when preparing the tax return, the ability to use a single document set for different purposes is an important aid to clarity and accuracy.