Reference Linkbase, XBRL Taxonomy Building

While building an XBRL taxonomy, Reference linkbase at first glance appears to be very useful to describe business facts, however it comes at a cost few realise at the outset. Some practices have also arisen in its implementation that seem to make sense, but on further consideration appear less so. Let us consider the use of the Reference linkbase at all. There is no doubt that providing pointers to external authoritative literature is a good thing, but it has its limitations. 

1. Using same reference for more than one concept:
Some taxonomies use the Reference linkbase as the only definition of a concept. This is useful only if the references provided are all unique and the reference itself clearly defines the concept and distinguishes it from all other concepts in the taxonomy. A cursory review of several major taxonomies reveals that this is not always the case. In many taxonomies there are several items that all share the same reference, so that the only distinguishing metadata is the standard label. This may be appropriate in some cases where the text of the reference clearly describes each of the different concepts using those labels, but it would appear that this is not often the case. It is also not the role of the standard label to be the definition of a concept, so care must be taken whenever one uses something for a purpose for which it is not intended.

2. Referencing to disclosure requirement as definition:
In many taxonomies, particularly those based on IFRS, the reference is quite often a reference to the disclosure requirements of the concept, not a definition of it. This leaves a user with knowledge of how to display the fact, but no understanding of what it is. These taxonomies rely on assumed knowledge of the fact based purely on the label supplied. This, once again, puts the role of definition onto an artefact that is not intended for it and also introduces the well known dangers of reliance upon assumptions.

3. Taxonomy Authors don't have control over external references:
Another issue with using external references is of course that they are external and not, or rarely, under the control of the taxonomy author/owner. This results in significant effort ensuring that all changes to the external literature are kept up to date – both in terms of the text describing the concept and in the numbering system. It is not unheard of for standards and legislation to be renumbered, which would require every affected element in the taxonomy to be adjusted so that the references continue to point to the same paragraphs. A wrong reference is worse than no reference at all, so if you are not prepared to put in the continuous effort required then it would be wise not to start.

4. Users may not have access to external reference materials:
Pointers to external references also suffer from the fact that they point to external material. This means that the material is not within the taxonomy itself. The risk is therefore that users do not have access to the material at the time they need it – either because they do not have it, cannot find it, or have to pay for it and are unable or unwilling to do so. Even if they do have access to it, they must leave the application they are in, go and look up the reference, read and understand it, then come back to the application and apply what they have learned. If the reference material were included as a “documentation” or “definitionGuidance” label within the taxonomy then it would be available to the user along with the other taxonomy artefacts within their application.

The downside of this approach is of course that the label linkbase would become very large as it would contain many pages of text. The trade off between taxonomy file size and the benefit of fully described/defined elements needs to be carefully balanced.

5. No 'standard' way of presenting references:
For those taxonomies that do use references, a very common practice is to split the reference itself into its component parts – for example IFRS 9  p 5.7.2 would be split into “Reference Parts” as follows:
Name: IFRS
Number: 9
Chapter: 5
Paragraph: 7
Clause:2

This seems like a good idea until you try to articulate a business reason for doing it. None of the components makes any sense on its own nor can any be used on its own to find out any external material. In order to find the external reference one must consider the whole reference in its entirety. Why split something up if you have to recompile it in order to use it?  Some might say it does no harm, but it does introduce the risk that it is recompiled in the wrong order. If a programmer decides that clauses come before paragraphs, then the reference would be presented to the user as IFRS 9 5.2.7 which would be wrong.

There is also no “standard” for using these parts. The same reference could quite easily have been captured in the Reference linkbase as:
Name: IFRS
Number: 9
Paragraph: 5.7.2

Which further limits any potential benefit of splitting it up and creates difficulty in recompiling it. 

In summary, the Reference linkbase is a useful tool but should not be an automatic requirement when building a taxonomy.  Careful consideration of the long term costs and benefits should be undertaken before implementing it and, if it is deemed worthwhile, the business requirement for its use should drive the design decisions.