XBRL provides a very effective way of capturing certain types of data. XBRL’s built-in dimensions, such as period and units, augmented by taxonomy-defined XBRL Dimensions (XDT), provide structured data that is ripe for automated processing and analysis.
The obvious next question is, “what technology should be used to do this processing?” and the obvious answer is “XBRL is XML so let’s use XPath.” Unfortunately, life’s not that simple. XPath is great at navigating a “traditional” XML hierarchy, but one of the features of XBRL is that it doesn’t use XML in the “traditional” way. The data in an XBRL instance document is represented by a very flat XML structure, and the relationships between facts are captured using XLink hierarchies (often spread across multiple files), rather than element nesting. Both of these make processing XBRL with XPath a real challenge. One approach to the problem is to convert XBRL into a structure of XML that is more suited to processing with XPath. Mark Goodhand has discussed this approach before and it works very well in some environments, but for others we want to work with the XBRL directly.
To understand the challenges in doing this, let’s consider some really simple examples. Take the following assertion:
Income = Revenue – Costs
Let’s assume that the three things in this assertion map directly to three XBRL concepts. It’s very tempting to try and write an XPath expression for this assertion. Something like:
//Income = //Revenue - //Costs
Unfortunately, life’s not that simple. XBRL instance documents often report the same concept more than once. For example, all three concepts might be reported for 2011 and again for 2010. To a business user, the sensible thing to do is obvious: apply the assertion to the three 2011 facts, and apply it separately to the three facts for 2010. Unfortunately, in XPath, it’s rather less obvious. We need to rewrite the expression so that we only use Revenue and Costs facts with the same period as the Income fact we’re testing, and doing that in XPath turns out to be really complicated. In XBRL, the dates form part of the context, so you need to dereference the contextRef attribute, and then do a date comparision on the start and end dates. To do it properly, you need to deal with different representations of the same dates (e.g. 2010-01-01T00:00 vs 2010-01-01, or the different interpretations applied by XBRL to start dates and instant dates).
That’s just the tip of the iceberg. What if the document contains facts for different entities? In different currencies? For different regions? At this point, you have to accept that you haven’t got the right tool for the job. You have three options:
(I’d hope you’d join me in discounting the second option, although sadly I have seen software that takes this approach).
We’ve investigated the approach of augmenting XPath, but the results are somewhat unsatisfactory, as you end up with much of the important information about your expression being captured outside of the XPath assertion itself, and you find yourself asking just what benefits you’re gaining from the use of XPath.
Building a new expression language from scratch is not something we undertook lightly, but we believe that it yields the best results, and thus Sphinx was born.
So what does our simple assertion above look like in Sphinx?
Income[] = Revenue[] - Costs[]
That’s it.
Sphinx’s default behaviour is to do the “lining up” that is obvious to a business user. This assertion will be applied for each period in which the facts occur. If there are multiple entities in the document, it will be applied for each of those. If your document contains a geographic breakdown of these facts, it will be applied within each region, as well as to the total.
Aside from the addition of some empty square brackets, that expression really is a pretty natural and accessible expression of the assertion we’re trying to apply. You might reasonably wonder what the square brackets are for. We describe Sphinx as a “native” XBRL expression language, because its view of the world is based on a logical, dimensional model of XBRL. The square brackets allow you to navigate that model. For example, suppose I only want Revenue in US dollars:
Revenue[unit = unit(iso4217:USD)]
Or for 2010:
Revenue[period = duration("2010-01-01", "2010-12-31")]
I also have direct access to XDT dimensions. Assuming I have a CountryAxis dimension with a UnitedKingdom member, I can get UK revenue:
Revenue[CountryAxis = UnitedKingdom]
So let’s take this one step further and look at another simple example, a roll-up by region:
Total Revenue = sum of Revenue for all Countries
In Sphinx this becomes:
Revenue[] = sum(Revenue[CountryAxis = *])
Again, all the other dimensions that aren’t mentioned explicitly, such as period, units or entity will be lined up automatically, meaning that this expression gets applied for each period, unit or entity.
As a point of detail, “CountryAxis = *” selects everything except the default, which is what we want, as the default will be the total. If for some reason I wanted to include the default, I could use “CountryAxis = **”. Once again, we can see that a native XBRL expression language gives us syntax that maps intuitively and concisely onto the data model that we’re working with.
Sphinx 1.0 was released on 22nd April 2011 after 18 months of intensive development. We built it because we had customers with real requirements that were unsolved by existing solutions, and because we believe that it’s the right answer. Simple expressions about XBRL documents should be simple to write, and complex ones should be only as difficult as they need to be.
So, you’ve finished tagging your iXBRL accounts, but what happens if others need to review them off-line prior to sign-off? Till now that hasn’t always been easy if senior management doesn’t have access to your tagging service. With Seahorse, it’s a problem solved.
Seahorse lets you export an Excel spreadsheet detailing every line item in your iXBRL document, showing the line item description, who tagged it, the concept label, the confidence level of the chosen tag, the suggestion ranking and whether the tag belongs within the Minimum Tagging Set. It’s particularly useful for reviewing the consistency of your work and providing an explicit audit log for your filers.
iXBRL has been a reality since April, but post-mandate it’s clear that companies are still struggling to cope with HMRC’s requirement for iXBRL filing. During a series of recent iXBRL webinars we questioned delegates about their filing plans. Many had filed early to avoid the issue – for this year at least – and others had outsourced the problem, but a significant percentage claim little understanding of iXBRL and remain ill-prepared to meet the new filing obligations. Most expressed concern about the amount of additional time they would need to spend on the conversion process.
Mindful of this prevalent view, we have been constantly evolving our Seahorse tagging tool to cut the conversion time.
From the beginning Seahorse included a unique autotagging facility, suggesting tags for each concept in the financial tables and letting you then review and confirm the appropriate tag. This process has always been quicker than traditional ‘drag and drop’ methods, but the new Bulk Review facility in the latest Seahorse release has made it even faster. No longer do you have to review suggestions line by line, you now have the option to confirm all ‘high confidence’ items – or even all items in the table. Three clicks are all you need. Seahorse also now interprets simple column headers containing only a year (e.g. ‘2011’) and expands these to the correct reporting period, saving you even more time.
To speed up the process still further, Seahorse now immediately alerts you if a tag you are about to create has already been used elsewhere to report a different number.
Are you prepared for iXBRL?
HMRC organised a highly successful iXBRL Solutions event at the Chelsea Football Stadium on June 30th. With a wide array of vendor exhibits, there was a solution for everyone. The interest in Seahorse was phenomenal. We appreciated the attendees’ obvious interest, as well as the air of conviviality and general willingness to squeeze in among the throngs who gathered all day long to look at our demo and talk about how Seahorse converts accounts from Word or Excel into iXBRL. Those who made themselves known to us ranged from sole practitioners to enormous accounting firms and FTSE companies. It was also great to see people who had introduced themselves at previous events returning to have another look and chat about the finer details. The demand for Seahorse is clear!
One of the positive things[1] about spending a lot of time out of the office is the opportunity to hear what companies are really wondering about. So, we’ve tried to answer some of the most frequent questions we’ve heard from companies soon to be filing to HMRC, albeit with an acknowledgement that some of the nuances may be further refined by the relevant authorities in due course. We include pertinent links to regulatory websites too.
If you have comments on the content, or if you would like to suggest other questions for inclusion in our FAQ, please use the comment facility, or e-mail
us at info@corefiling.com.
If you’re not an HMRC Filer, you might be interested to explore other similar pages dedicated to Regulators, SEC Filers and SBR Projects, where we’ve described the issues currently facing these groups and offered some perspective on the solutions now available.
[1] The downside, of course, is that we don’t have a lot of time to blog 
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.