The benefits of XBRL as a standard electronic format for the exchange of financial information are enormous. Electronic analysis of traditional paper reports requires expensive, error-prone re-keying. PDF and HTML reports are only slightly more accessible; data extraction is ad-hoc and imperfect. In contrast, XBRL reports are structured and machine-readable. If you can process one, you can process them all.
XBRL instance documents carry the data: a set of dimensionally qualified facts. Each monetary value is tied to an ISO currency code, and every fact is rigorously defined by a concept in a supporting taxonomy. The taxonomy defines the reporting vocabulary and provides a wealth of metadata, which supports validation, guides interpretation, and facilitates comparison. The instance document tells you that Apple’s total current assets on the 26th of September 2009 stood at 31.555 billion US dollars. The taxonomy tells you which other figures contribute to that total.
The flexible nature of financial reporting is addressed in XBRL through taxonomy extensibility, which allows users to augment and customise taxonomy metadata. While this provides significant power, it means that consuming taxonomy metadata is very much a runtime consideration rather than something that can be tackled once at dev-time. Amazon’s income statement contains a custom concept for “Technology and content” expenses. Google’s balance sheet includes a custom concept for the “Total number of shares of Class A common stock subject to repurchase”. This flexibility can be frustrating for technologists, but it’s an inherent and necessary feature of financial reporting. XBRL is like a box of chocolates; you never know what you’re going to get.
Unfortunately, XBRL’s semantic power is matched by its syntactic complexity. Data and metadata is spread across multiple files, and though XBRL is XML, it is not conventionally structured, so it is not amenable to processing using traditional XML tools such as XPath, XSLT, XQuery, and Schematron.
At the XBRL instance level there is very little hierarchy. You have a flat set of facts, with dimensional information split out to xbrli:context elements, which sit at the same level as the facts.
At the XBRL taxonomy level, hierarchies are represented not as XML trees, but using XLink linkbases, which are complicated and expensive to process.
To assemble a complete and accurate picture of an XBRL report, specialist processing code is essential. Libraries such as our True North XBRL Processor can efficiently compile XBRL into a set of objects, accessible through Java or .NET. Unfortunately, this isn’t much consolation to an XSLT-savvy analyst, or the architect responsible for an XML database. XBRL is XML, but for common analysis and transformation tasks it may as well be binary.
There are two ways to address this problem:
The first is to define a set of XPath extension functions, backed by an XBRL Processor. The main obstacle here is that the extension functions must be integrated with every XML application in your processing chain. A secondary, though potentially critical consideration is that the cost of XBRL processing will be paid repeatedly, in each system that has been XBRL enabled. Finally, there is the impact on the XPath expressions themselves. The XBRL tree structures are exposed, but not as an axis, so you lose the elegant path-based navigation that makes XPath so compelling.
The second, fundamentally different approach is to transform the XBRL into a format that’s easier to manage.
Our Composite XBRL representation brings all of the XBRL data and metadata together in a single document as traditional, hierarchical XML. XPath once more comes into its own. Operations that were practically impossible to express against the source files, and cumbersome to express with extension functions, become trivial and natural. The cost of XBRL processing is paid once, up front, and downstream processing can be handled by vanilla XML tools, without the need for extension libraries. The impact of XBRL on your processing chain is minimised and localised.
We believe this approach has huge potential, and to support it we have produced TNT: the True North Transformer. Contact us for further information.
The CoreFiling Seahorse team is “Demystifying XBRL” all over the UK this week and next with the ICAEW and HMRC. Following the success of the London event on December 17th, which was packed to capacity, the ICAEW regional roadshows kicked off yesterday – aptly enough – in Manchester City Football Stadium. More than 80 people attended. Who would ever have predicted that XBRL would have such mass-appeal! Drama was heightened further by a brief emergency evacuation of the venue mid-morning; it seems that their smoke detectors are fully-functioning.
As the Manchester event wrapped up, one of the panellists drew the attention of the audience to the e-mail addresses of all the speakers listed on the Programme with the caveat that any hard questions should be sent to our very own John Turner! That’s fine by us, and if the questions are the kind of ones that might be of interest to lots of people, we may publish the answers, so please send them in or place them in the comments here.
Today’s venue is the Birmingham Botanical Gardens. On Monday, we have two sell-out events scheduled back-to-back in the splendid Chartered Accountants’ Hall in London’s Moorgate. On Tuesday, you can see us at The Bristol Golf Club. Then we travel to the north of England for a breakfast seminar on Thursday morning in the Ramside Hall Hotel, Durham.
The purpose of the Demystifying XBRL events is to help accountants understand what the iXBRL mandate means for them. We dispel fear and discuss solutions. The speakers cover everything from the high-level technical lingo to the finer details of the regulation itself. There’s also an opportunity to preview Seahorse, our iXBRL solution.
If you’re attending any of the events, please say hello to the Seahorse team!
Today we round out our review of some of the main answers to Why should you use Inline XBRL?.
Inline XBRL means a simplified review and improved control. It is probably obvious, but the review of an Inline XBRL document is considerably easier than that of a native XBRL document, simply because you can skip a step – you can be confident that the facts that have been marked up are the same as the “original” because of the single document aspects of the format. It is still necessary to determine whether the document has been prepared using the right taxonomy, whether the facts have been marked up (tagged) with the right concepts and using the correct dates and other context information such as dimensions, but users are very much more comfortable dealing with an Inline XBRL document that you can look at and “touch”, rather than the somewhat more abstract idea of an XBRL formatted rendering of a document. Naturally, Magnify (Touchstone) can deal with either format.
Let’s recap.
Securities regulators, company registrars and stock exchanges should all consider adopting Inline XBRL as part of their transparency initiatives.
The other day I asked the question, Why use Inline XBRL? A key reason is that is easier for Accounting Software Vendors to implement.
Many accounting software vendors, the firms that produce most of the GL systems, accounts production packages and ERP systems on the market, don’t use XML (let alone XBRL) on a day-to-day basis. Many systems are starting to, but the majority of vendors are hugely reliant on databases and third generation languages in the construction and maintenance of their software, which has often been working reliably for decades.
Inline XBRL is simpler for most vendors to deal with than raw XBRL, in part because it is generally a two step process:
Those tags, of course, use the XBRL mapping that is a fundamental part of coming to grips with structured business reporting. Note that many of these vendors don’t need to deal with extension taxonomies, as their target market is the small and medium sized business. Those that do will still need to construct them appropriately. Hey it’s good, but it’s not a magic wand!
In the next blog we’ll round this mini-series out by suggesting that Inline XBRL simplifies the review process and improves the controls for companies as they prepare their accounts.
The other day I posed the question Why use Inline XBRL? Another key reason is that an Inline XBRL document is easy for the preparer to understand.
There is one major concern that we hear from regulators around the world as they introduce XBRL. It is that controllers, CFOs and FDs that are providing XBRL information that relates to a financial report (as opposed to a form, where this concern doesn’t exist) don’t know how to be sure that the “bag of angle brackets” that they are producing accurately represents their financial statement.
Modesty doesn’t stop me from mentioning that tools like our very own Magnify (Touchstone) help resolve this issue, but nevertheless, the use of Inline XBRL takes away almost all of those concerns. It makes this process much simpler. The information that is marked up can, almost trivially, be identified and, vitally, the marked up information is exactly the same as the information that you read, simply because it is the same information. It works for text as well as for numbers. Inline XBRL also lets you incorporate web friendly navigation. You can, for example, have a report span multiple pages of HTML but be collated on the fly at the time of consumption into a single XBRL document.
Some regulators, by the way, have been getting around this problem, with what is in effect a parallel process i.e.: by asking companies to file a PDF document with full visual fidelity at the same time as the XBRL document. After all, the PDF looks and feels the way the preparer wanted it to and the XBRL is structured and contains the same information in a format that can be easily analysed. Honestly, this is not a great idea. It adds work to already overworked finance and compliance teams and, perhaps worse, creates uncertainty – what do you do if you have inconsistencies between the documents? Inline XBRL solves these problems.
My next article will look at why Inline XBRL is easier for Accounting Software Vendors to implement.
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:
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.
So now the hard work really begins. The SEC’s decision today to require
registrants (ie: companies with listed securities) to start filing their
financial statements in XBRL format is pretty similar to the proposed rule
announced in the middle of the year. As widely expected, there is a slip in the
timing. It will start for company filings (quarterly or annual) as from 15 June
2009, ie: 2009-Q2 10Qs instead of the larger and harder 2008-Q4 10Ks as
originally anticipated. They’ve also pushed back the timing for the roughly
8,000 mutual fund risk/return summaries to 1 January 2011, instead of the
middle of 2009.
The Commission is not unanimous on the liability arrangements. Commissioner
Aguilar is voting against the entire proposal because he wants the liability
and the assurance arrangements contained in the proposals greatly
strengthened.
For what it’s worth, I think that the liability carve-out arrangements are an
attempt to ease the transition costs – the change management involved in a
complex new technology – and the SEC (particularly the Chairman) are relying
on new SEC leadership to reinstate them. We need to wait for the final rule to
see the details, but there appears to be a phase-in arrangement for liability
(and therefore assurance) in any event. This should be a relief for a lot of
auditors.
Commissioner Aguilar is pointing out that the current economic climate is the
exact moment at which the regulator could simply reject the need for a
carve-out. Since the requirements for audited financial statements in ASCII or
HTML are not going away, and the liability and assurance arrangements for them
remain, I suspect the issue is almost moot.
However, I think, from an accuracy and consistency perspective, we should be
looking for XBRL filings to be in iXBRL (embedded inside web pages) format.
This should happen very quickly and at that point, the liability arrangements
must be uniform. Cox seems to have made this point, right at the end of
the meeting.
A number of the other details will be in the rule. Final SEC rules tend to be
published a week or so after these open meetings. Stay tuned.
I think this decision today is much bigger than most people realise. Thanks and
congratulations to the SEC, particularly Paul Wilkinson, Jeff Naumann, David Blaszkowsky and (more recently) Walter Hamscher, all those involved in the US
GAAP XBRL taxonomy project at XBRL US under Mark Bolgiano and Campbell Pryde,
as well as the extraordinary international collaboration that XBRL continues to
represent, especially at XBRL International.
Ever sat in a traffic jam in the evening, on a road that is narrowed by a lane filled with orange cones and silent bulldozers, as the workers have all gone home? I sit there fuming, calculating in my head the cost of all the additional fuel that is being burnt by cars moving at a snail’s pace, plus the average cost of everyone’s time. Surely, if government was "by the people, for the people", the cost/benefit analysis for work on major roads would include those costs. The result would be that an awful lot of road work would happen 24×7.
The reality is that not that many parts of government work in a way that takes account of people’s time and money. But here’s an area that does: S.B.R.
Standard Business Reporting projects are based on the unusual notion that government should change the way that it works so that things are just a little bit easier for the private sector. We’ve recently added the Australian Government’s SBR project to our list of major clients. Their counterparts in the Netherlands have been important customers for some time.
What are they up to? They are working across government agencies, and even across levels of government, harmonising the way that business reports to government. The problem is that government is complex, and it needs lots of information from the private sector in order to be able to operate. But the provision of that information is complicated, burdensome and duplicative. How burdensome? Well, according to the SBR projects’ analyses, about 2.5% of GDP in most countries is devoted to compliance costs. Two point five per cent??? That’s USD48 Billion in the UK, or a gobsmacking USD333 Billion in the USA. In the Netherlands and Australia, both countries are dealing with smaller economies, with the burden in the order of USD12 Billion each, and both looking to save around 8% of that. Which is still really worth doing.
So, SBR aims to shave a bit of that burden down. Even small improvements, when you are talking international telephone numbers, really help!
How many government initiatives can say that they are working to save taxpayers hundreds of millions without cutting back on the services being provided?
As one senior official in the UK put it recently, rather than dealing with the symptoms of duplication and complexity, for instance, by trying and often failing to create cross-governmental databases, SBR aims to deal with the root of the problem, by getting different agencies to agree on definitions. This results in the construction of a single set of structured requirements that are much easier for small, medium and large businesses to comply with, and (crucially) for their accounting software to report with. The technology behind these initiatives? You guessed it: XBRL.
You can find more information about SBR on the Dutch and Australian websites. Stay tuned. These projects are worth doing.