Building XBRL Taxonomies is a relatively new art. I say “art” and not “science” because there are very few (if any) “laws” that have evolved to guide the practitioner in this domain. Because of this, most have taken the natural path of designing the taxonomy to replicate the format of the paper form it is typically based on.
This, of course, works. The paper form has been used to gather the data so far and so anything that emulates it will do just as good a job … and this is the key point – it will do just as good a job, but is unlikely to do a better job.
This is the opportunity lost.
Many of the design decisions of the paper form are made with the physical constraint of A4 in mind. I may want the breakdown of assets by country of location, but I cannot fit the potential number of countries (about 200) onto a page, so I try to guess at the most common or make arbitrary regional aggregations as a compromise. With XBRL there is no need to compromise.
You can gather all the data and aggregate or filter on receipt. It is very easy to aggregate raw data – it is near impossible to break down composite data.
At IRIS, our team has built taxonomies for different types of regulators – tax, prudential, business registrars, etc – in many different countries and cultures, so we know firsthand that there is not one “view” of the common data collection that pervades. A taxonomy design optimized for one form rarely fits the requirements of another user who wants the same data.
The answer lies in designing taxonomies based on what the data is, not how it looks.
Our processes tease out the underlying meaning and purpose of the data being collected so we can build robust data models that work for many different users. Rather than take a short-term view of building a taxonomy for a single requirement, we look at the longer-term future of the taxonomy and ask who else might want to use this.
The benefit of XBRL, like any standard, is only realized when it is in common use. For this to occur it necessarily means that there must be more users than the one we are building the taxonomy for, so it is the only sensible way to ensure our clients get the benefits they are paying for in the longer term.
Switching from paper (or PDF or HTML or any other format) is disruptive – it takes time, effort, and money. If all you have at the end of this is just another way of doing the same thing, then you have to ask yourself why you bothered. If, on the other hand, you take advantage of the disruption to learn a new and better way of doing things, then you may find the effort was worth it.
