I’ve been meaning to put some effort into introductory XBRL materials to place on this site, but we have been busy. Now it looks like Josef MacDonald’s team over at the International Accounting Standards Committee Foundation (IASCF) are producing such good quality stuff that we won’t need to. The diagram is an adaptation of a slide that Walter created years ago and that has become a bit of a staple for XBRL International talks. But this is heaps better! And the glossary is terrific. Congratulations to everyone involved.
Developers familiar with XML standards often look at XBRL and ask the same questions:
In this article, Steve Baker, Director of Product Development, explains how and why XBRL differs from most other XML standards.
Check back for later articles on how XBRL works and how to work with it.
Most XML standards provide a schema that defines fairly tightly what structures and datatypes are allowed. If a standard is extensible, it is only in defined places and often in only narrow ways.
XBRL is different: an XBRL report is defined to contain contexts, units and concepts but the XBRL standard does not provide any concrete concepts one can use. Instead, XBRL is defined in terms of the two types of concept: items and tuples. Concrete items and tuples are provided by XBRL taxonomies.
By leaving items and tuples to be defined by domain experts in taxonomies, XBRL provides a great way to model typical business reports in a uniform way, while allowing preparers to report whatever they need to.
A typical business report will have a column of labels on the left, indented to indicate structure. A table is formed by providing the data for those headings for each of several periods in time: the rows are the facts, the columns are the different periods or instants. The units of the report are given, as is the name of the business entity to which the facts refer. Additionally, footnotes are added, and certain facts typically sum to subtotals.
Sketch these features in a spreadsheet and hand them to a dozen XML gurus and you will get at least a dozen different designs. And remember we didn’t tell the gurus what we would actually be reporting!
XBRL’s big win is that it takes these typical features and gives us one design so we can move forward.
Where a schema is usually sufficient, XBRL requires a definition in several parts:
The way these components of the definition are brought together varies, but typically a report points to a taxonomy schema and the taxonomy schema points to all the other components. Taxonomies often point to other taxonomies.
In addition to the now run-of-the-mill XML technologies like namespaces and XML Schema, XBRL has some uncommon features.
Nothing could work without substitution groups. The schema for XBRL reports says, “you can put items here” but it makes items abstract: you can never use an item directly. Taxonomies declare concrete items that can be substituted wherever XBRL allows an XBRL item. Don’t worry: we’ll be coming back to this in a later article!
A quite arcane part of the landscape of XML standards is XLink. XLink allows the definition of arbitrary networks, or graphs, of relationships between things of any type. XBRL takes XLink and applies it to good effect: all the linkbases use XLink to relate concepts to one another and to other information.
IDs and IDREFs have always been available in XML, but in XBRL they are indispensible. Taxonomy schemas give every concept an ID to which links can refer out of the linkbases. Footnotes use IDs on reported facts with IDREFs to add that extra information to the report.
No doubt you are used to seeing deeply-nested elements in XML documents: tags within tags within tags. In XBRL, reports are usually quite flat. Most of the structure is in the linkbases.
XBRL is not completely flat. Contexts use structure to lay out entity, period, segment and scenario information and units are structured. Tuples can contain other concepts – that is, items or tuples – so they can reintroduce as much structure as is necessary.
It’s all about extensibility:
As you can imagine, flexibility and extensibility are available in XBRL to a degree unseen in most standards. Thankfully, all this change happens within the same defined framework, so tools and applications can still get on with the processing.
Check back for further articles as we explain how XBRL works in detail. You can also see our paper XML Flattened.
There are a few commentators that feel that XBRL contains “too many tags”. I think they are wrong… XBRL models a complex human system (accounting) with lots of small components (disclosure rules).
So, a number of these “too many tags” kind of comments are creeping into articles being printed about XBRL. Interesting. Fundamentally flawed, but interesting. In particular, I mean this part:
Industry commentators have said that too many taxonomies have been created within XBRL, making it too complicated, time-consuming and costly for companies to use in its current guise. From Kevin Reid in Accountancy Age.
The unnamed commentators are usually one of a few usual suspects who have just come at this technology from the wrong angle.
Do this: download a financial statement from a leading company, listed on the stock-exchange of your choice. Count the number of different accounting disclosures.
Just at random, I’ve downloaded the annual report from BP, admittedly a company with a reputation for quality and quantity in their investor relations. The Excel file available from here contains just the financials, required accounting policies and certain non-GAAP statistics about the company’s exploration activities.
Sixty-eight pages of performance information. At a quick glance, there are at least 20 different concepts on each page, 1400 different concepts.
Companies don’t go to the expense of publishing this many performance concepts unless they have to (it’s a requirement of the accounting standards they work with) or they want to (they believe that their investor relations message will be enhanced or made clearer). Accounting authorities don’t include reporting concepts in their accounting standards that are unnecessary or useless. So those (at least) 1400 concepts published by BP make up a package of information that either the company itself, or the accounting authorities, consider will be analyzed by market participants.
The point about XBRL is that each of those 1400 concepts either already has been, or can be, encapsulated in a taxonomy. Making comparison between companies a task that can be largely automated, or, just as importantly, making comparisons of a single company across time, something that can be dealt with by computers, instead of people. Freeing up people to think about what those comparisons mean, instead of manipulating spreadsheets and summary databases, (or worse) retyping 1400 concepts before being able to make those comparisons at all. Those comparisons are only possible through the use of taxonomies. They define what each disclosure means, link them to related disclosures, determine how they are calculated, impose validation rules around them and add references to relevant authoritative literature.
The number of taxonomies that exist reflects the diversity of economic life. The US has a different accounting framework to that used in Europe. Oil and Gas companies need to disclose different performance measures to those that matter in Aerospace. BP has different investor relations objectives to Shell. So you just can’t get away from the fact that XBRL has lots of taxonomies, and each of those taxonomies contains lots of tags. But are there too many? Nope. Just the number in use in corporate life in the naughties. Is it too hard for companies to use? Nope. While you wouldn’t want to approach it from first principles (that specification is a nasty read), implementation right now means using tools that others have already built. Most companies just want to be able to publish performance data in a format that is an unambiguous interpretation of their financial or business performance. For them, the task amounts to:
There are a whole bunch of tools (granted not as many as some of us would like), and some talented people, that can help them do that.
The task of XBRL has never been to change the way that accounting works… and that is the only way you would reduce the number of tags. Technology usually models human systems. In fact it tends to fail when it tries to change them. And the accounting system, while venerable, is both highly regulated and critical to the global economy. XBRL is just a better way of communicating performance.