How XBRL differs from other XML standards

Developers familiar with XML standards often look at XBRL and ask the same questions:

  • XBRL looks different: how does it differ?
  • Why does XBRL differ?

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.

XBRL is a framework, not an implementation

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.

XBRL models tables of data

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.

XBRL reports are defined in several parts

Where a schema is usually sufficient, XBRL requires a definition in several parts:

  • The general structure of an XBRL report is defined by the schema for XBRL.
  • The concepts which may be used in a report – the items and tuples – and any datatypes are defined in a taxonomy schema.
  • Relationships between concepts and about concepts are stored in taxonomy linkbases for flexibility:
    • The label linkbase gives various human-readable labels for concepts, often in several languages.
    • The reference linkbase points to authoritative documentation for concepts.
    • Hints about how to present concepts in relation to one another – those indents in the business report – are provided by the presentation linkbase.
    • Statements about how concepts should sum to other concepts are provided by the calculation linkbase.
    • Miscellaneous – and infrequently used! – relationships are given in the definition linkbase.

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.

XBRL uses some uncommon XML technologies and techniques

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.

XBRL is typically quite flat

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.

But why?!

It’s all about extensibility:

  • Allowing multiple accounting standards within the same framework.
  • Allowing extensions to accounting standards by adding new concepts with new labels and references while changing relationships.
  • Removing concepts from presentation views.
  • Removing concepts from calculations.
  • Permitting labels for concepts in new languages.
  • Inserting new concepts into a report, changing the existing presentation and calculation relationships.

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.

Further reading

Check back for further articles as we explain how XBRL works in detail. You can also see our paper XML Flattened.

Initial test of TRAX – Collaboration for XBRL

Recently we signed an MOU with XBRL-US, providing a new collaborative taxonomy tool called TRAX to help business experts review the work of taxonomy developers. The tool has now been launched and is ‘on trial’ through to the end of the year. Other parts of this site give you plenty of information on the tool. What follows is part justification, part theory: to put it into context.

Some of the most powerful new technologies today are loosely termed “social tools”. They provide a mechanism for collaboration. Our hope is that by bringing on-line collaboration into the middle of the process of creating XBRL taxonomies, project teams will build an increasingly familiar process.

It should become more than a process. It should be a ceremony – a set of steps that everyone involved in the exercise understands and expects everyone else to follow. Ceremony is a term that I’ve borrowed from the security folk, who are now using it to describe what is required to grant an electronic identity to someone. A good term, with wider application. What does it mean in the context of XBRL taxonomy development?

Not long after we started CoreFiling, we began to discuss taxonomies and, specifically, taxonomy review. The parable goes something like this:

The acolytes spend many days and long nights labouring over the construction of a set of definitions, that, once mangled with tools, scripts, or notepad, becomes a taxonomy. And they consider it good, if in need of some fresh eyes. Thus, each time that a taxonomy gets created a great hue and cry goes out. “Please review this!” beg the acolytes. Generally, although not always, their beseechings fall on a silent multitude of accountants, accounting standards setters, analysts and preparers. And then there is gnashing of teeth and tearing at hair amongst the acolytes. “We have built it. And yet they haven’t come,” they call out. And then (finally) there is some review by some people and the acolytes try to tell each other that it will be enough. But often it isn’t.

It seems to me that to create a standard, (and a taxonomy is a very specific kind of standard) you need subject matter experts to reach agreement about what the standard should say. Just as importantly, you need an authority that will publish it and maintain it. For the moment, let’s assume that authorities are easier to come by than subject matter experts. A topic for a later note, no doubt.

So, why is it difficult to get business experts to look at XBRL taxonomies to see if they will meet their needs? Well, there have been a bunch of reasons, including the rather obvious fact that until recently, quite a lot thought it would be a waste of time, as they didn’t want to create reports using XBRL. The tide in that area is changing quite quickly, so now there are very good reasons for business experts to review them. However, I think there are a couple of other important reasons they might continue to hold out, if it were not for TRAX (and no doubt its successors): Accessibility and Trust.

Subject matter experts tend to be much in demand, so, among other things, it’s necessary to ensure that they don’t have to waste time understanding something they don’t need to. Something like XBRL. Equally, subject matter experts are very unlikely to be able to spend very much time together, so it would make sense if they could collaborate over the internet. Combined – the need for the materials to be available in a form that is easily understood, and the need for the materials to be available at all hours of the day or night, anywhere on the internet, captures what I mean by “accessibility”.

Finally, subject matter experts need to trust that, if they are going to put effort into reviewing something, their comments will be used and not ignored. Transparency in the comment process is really important to their commitment. Nothing seems to put people off faster than not seeing how their contributions have made a difference. That’s trust.

So, TRAX, which came about following some discussions internally, and then with our good friends at both WebOrganics and the one and only Galexy, is the result. It’s kind of nice that this collaborative tool was built collaboratively! We hope that TRAX will make the process more accessible, since we can skin it to make even XBRL seem reasonably straightforward, and since it is a creature of the web, merely subject to continuity of power at a very big, very red building in the London Docklands, it should be nearly ubiquitously available. And we hope that trust will be pretty straightforward, as you can always see “My Issues” and how they have been dealt with by other commentators as well as the project moderators. Creating a whole new set of incentives.

So while the system gets put through its paces (and there are a number of new features that will get added during the course of the trial, and no doubt a number of bugs stamped out as well), we’ll be most interested to see if it helps make it easier for subject matter experts to give a little of themselves. And perhaps a new type of ceremony will start to get created.

If you would like to contribute to the review of the XBRL-US Broker-Dealer taxonomies, please contact Brad Homer (bhomer) at (at) the AICPA (aicpa dot com). If you have your own taxonomy project and would like to experiment with TRAX, please drop me (john turner at corefiling dot com) a line.

FFIEC project starts in October…

This is a reprint of my September column in the Business Wire newsletter, but, given the importance of this project, I thought it bears repeating!

At a recent meeting of XBRL-US, the covers started to come off the long awaited “Call Report Modernisation Project”, a ground breaking XBRL project that goes live on 1 October. Otherwise known as the FFIEC (Federal Financial Institutions Examinations Council) call report project, this is the first project in the world to mandate the use of XBRL for regulatory reporting. The FFIEC is a co-ordinating body for the US bank regulatory agencies. It’s going to mean better information gets into the hands of the market, and regulators, much faster.

The FFIEC call report project upgrades the ageing quarterly reporting process required of the 8000+ US banks. The main benefits that the FFIEC are seeking are to improve the speed, efficiency and accuracy of their data collection, reducing the time that it takes to provide UBPRs (Uniform Bank Performance Reports) to bank supervisors working in the Fed System, the FDIC and the OCC. Many people in the markets are salivating at the thought that UBPR data will be published in around half the time previously achieved by these agencies.

By using XBRL taxonomies to define concepts, and an (admittedly semi-proprietary) formulae linkbase to define validation rules (or ‘edit checks’ in FFIEC speak), the project has pushed the task of providing accurate data back where it belongs – the supervised banks. Previously, error checks were carried out by staff within the regulators, with corrections and follow-up sought over the phone, slowing down the publication process by something like 60 days.

Clear thinking

By publishing their validation rules, the FFIEC continues to lead the bank regulatory world in transparency. This philosophy, of publishing requirements and publishing the individual responses of regulated institutions, is something that other prudential regulators around the world tend to look on as revolutionary. Many regulated organizations, outside the United States, have long considered the publication of their performance on a range of risk measures as commercially sensitive.

But consider the virtuous cycle that the systematic release of this kind of information into the public domain creates. It provides incentives for staff inside the regulators to carry out great analysis, as they don’t want to be caught out when an industry pundit calls out a problem. Most importantly, it provides great incentives for executives of regulated institutions to pay attention to risk-based performance measures, since their peers will be comparing results.

It provides a simple, market-based mechanism for regulators to force management to look beyond growth and profitability, and examine the sustainability of their performance, based on asset quality, liquidity and the efficiency of their capital allocation. Of course, this philosophy of market-based transparency has been adopted in the Basel II capital accord reforms so, as they start to be implemented, much of this information will start to become available for the first time.

The provision of XBRL data from bank to regulator, and insurer to regulator, provides clear benefits to regulators. Many regulated institutions ask “What’s in it for me?” The answer, as the FFIEC is showing, must include the publication of each supervised institution’s reports, in XBRL format, making analysis a process focussed entirely on creating new insights into business performance and comparison, instead of the manual collection and collation of data itself.

Crossing the chasm

Over on the Gilbane Report Blog, Bill Zoellick’s July 26 post about the FFIEC project is, as usual, insightful. Bill argues that this kind of very focussed application of XBRL is exactly the way that technologies move beyond the early adopter phase.

It seems unarguable that, with some of the largest regulators in the world now using XBRL for these kinds of “closed form” reporting arrangements, other agencies, looking to improve the accuracy, timeliness and relevance of their reports will follow suit. And the evidence, from around the world, is very much in tune with this.

At CoreFiling, this is exactly the way we look on the technology. Closed reporting solutions using XBRL are now mainstream, with several referenceable implementations and good support from a range of vendors. No regulator, bank, insurer or large corporate that has to collect large quantities of complex performance data should contemplate implementing systems that do not support the standard.

Voluntary Filing Program

Since April, the poster child of XBRL-US has been the SEC’s Voluntary Filing Program, boosted this month with the announcement that N-Q and N-CSR filings by mutual funds will be accepted in the new format. While the tools and techniques to support filing of full financial statements have not yet reached the level of maturity needed to make this simple, the benefits, in terms of reputation, visibility and messaging are clear. Generally, initial take up should be from leaders that understand these benefits, realising that production of XBRL materials will take some effort the first time around.

In fact, supporting those organizations that want to grasp that first-mover advantage is one reason that we have set up a specialist consulting group in New York, to assist registrants that seek to file their accounts in XBRL.

More on this next month… Stay tuned!

Too many tags? No!

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:

  • finding the right taxonomies,
  • matching the right tags to their performance measures; and
  • publishing the right values inside those tags, together with a few other bits of key information, like which company, date and currency that disclosure relates 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.