XBRL is not difficult. It’s like most things in that it’s easy if you know how – all you need to do is learn the basics and then practice to become good at it. As you encounter difficult situations your basic knowledge and practice enable you to learn further and become an expert. This is the journey our team has been on – some for as long as 20 years. I here explain one of the basic principles you need to master for a robust XBRL taxonomy that many taxonomy authors still get wrong. I hope you learn from our experience.
Difference between XML and XBRL
One of XBRL’s key strengths is its separation of semantics from syntax. In XML you need to put all the human understanding of the concept into the element name and perhaps a comment item near it. This is using the element name for 2 different purposes – a unique code for the computer and a human language description for the user. Mixing different meanings in one thing almost always ends up in conflict and XBRL founders were very clever in separating the concerns.
‘Element Name’ is an underutilized phenomenon in XBRL Taxonomy Building
However, many XBRL taxonomies ignore this powerful feature and persist in using human language element names. “What’s the harm in that?” many ask. The answer lies in what I call “the synonym problem”.
Every human language uses different words to describe the same thing – or what people infer to be the same thing – but a computer will view any slight deviation as being a different thing. One only needs to look at early versions of the IFRS Taxonomy to see the impact of this.
Over 500 changes to the element names were made between the 2006 and the 2008 versions to “improve” the wording. This had absolutely nothing to do with the processing of the elements by computer applications, yet over 500 changes to programs would have been required to cope with them – for no processing benefit whatsoever.
Had XBRL been used “properly” then only the labels would need to have been changed and the element names would have remained constant. The humans would have got what they wanted – improved wording of what the element represented – and the computer would have got what it wanted – no change to the unique identifier for the concept.
It is said in jest, but there is more than a grain of truth to it, that the most powerful human emotion is not love or hate, but the overwhelming desire of one person to amend another’s draft. No matter which word you choose as an element name – there will be somebody who comes along after you who deems another word to be most appropriate and the temptation is there to change it because it looks “silly” to have the label and the element name look different.
‘Element Name’ the Fundamental Analogy
Our approach is to continue with the barcode analogy that is so often used in XBRL. Barcodes are not even human-readable and even the thing they represent, the Universal Product Code (UPC), is simply a number. With a few trivial exceptions, one number is as meaningful a business identifier as another, so there is no temptation to want to use PE002168 instead of PE006653 as the element name for “Net Assets”. This insulates you from changes that affect the computer when the need for the change relates to humans only.
The element name is for the computer to read, not people. The labels are for humans to understand, not computers.
Just like with barcodes, the code is attached to the descriptions the humans need. When you search the aisles of your supermarket for the things you need, you look at the labels and descriptions on the packets to decide which one is for you. When you take it to be scanned at the register, the computer only looks at the barcode to decide what to do with it. It’s the same with XBRL – humans look through the lists of labels, references, and documentation to see which one is right for them. They then associate that with the data to take to the computer application, which only uses the element name to decide what to do with it.
It makes perfect sense, so why don’t people do that all the time when building XBRL taxonomies? We can only guess, but it may be that they are from the old XML background and have not adjusted to the new world of XBRL yet. It may be that it seems like a benign thing to do that makes coding easier, but they have not been in the game long enough to see what problems this seemingly harmless decision can cause in the long run. The same goes for restricting the use of elements across data sets, but I leave that here for further discussion.
Like flying a plane – anyone can do it when you’ve leveled out and the skies are clear, but when things get tricky you want people at the wheel who has seen it all before.
If you need any help in defining Your digital reporting strategy or building XBRL taxonomy, write to us at shilpa.dhobale@irisbusiness.com or click below.
