Digital Financial Reporting

This post discusses a common situation which many who create XBRL taxonomies seem to have which is the need to add additional metadata to the taxonomy. 

An example of this can be seen in the US GAAP Taxonomy.  Go to this taxonomy schema file.  Open the file in your browser and search on the following: "us-gaap-att:deprecatedDate".

That attribute which is added to a number of concepts in the US GAAP Taxonomy was added by the creators of the US GAAP Taxonomy. There is likely documentation which explains what the attribute is and why it was added, but that is not the point here.  The point is this: 

Is there a standard way to add this type of metadata, what are the pros and cons of different options to adding this type of metadata, and what determines the best approach to use.

Since I have been creating taxonomies it commonly is the case that the creator of the taxonomy wants to add additional metadata which is not specified by XBRL. One way taxonomy creators have added this additional information is to use, say, a Microsoft Access database to contain the additional information and then somehow create a pointer from the database to the XBRL taxonomy.  The problem with this type of an approach is that it is proprietary, you have to have Microsoft Access (or an application whatever database format you use), and you have to build a lot of infrastructure for maintaining the links between the XBRL taxonomy and the other metadata storage mechanism.

Storing, or at least making the additional information available in an XBRL format provides significant leverage.  If this is done correctly, you can have the flexibility you need, you can make the additional metadata available to others in a standard format, you can write less code because you can use XBRL to provide the infrastructure for maintaining the links between the taxonomy and the other metadata, and other such benefits.

What I see generally is that taxonomy creators rarely consider the users of the taxonomy when they make this decision. Further, I would point out that like many things in XBRL you have so many different options for adding this additional metadata that there is both no one standard approach and XBRL software cannot make use of the metadata without modification to the software application.  Basically, there is no standard way to add this additional metadata.

Keep this use case in the back of your mind as I walk you through the different options.  Consider the US GAAP Taxonomy.  Suppose you wanted to add information about the "audit risk" of each financial concept in the taxonomy.  Let's leave it at that for now, I will add other subtleties in the different sections below.

These are the different approaches that I can see for using XBRL to add this additional metadata to an XBRL taxonomy (I am not mentioning the proprietary approaches):

• Use a custom XML Schema attribute
• Use the reference linkbase
• Use context segment or scenario
• Use the definition linkbase
• Use labels
• Use the generic linkbase

Granted that some of the approaches mentioned above are a "hack" but they are in the list because they work and because they help one see the issues relating to adding additional metadata to an XBRL taxonomy.  Here is a little bit more detail about these different approaches.

Use a custom XML Schema attribute

This is a commonly used approach for adding additional metadata to a taxonomy. But there is a problem with this approach, and this can be a significant problem. While it is the case that XBRL allows for such attributes to be added to an XBRL taxonomy it does not require an XBRL processor to understand or even do anything with that additional attribute. Further, once the additional metadata is added using this approach, you loose the ability to modify the metadata. This is why, for example, XBRL puts a lot of things into linkbases and not into the taxonomy schema. So, the bottom line here is that this approach really looks appealing in its simplicity, it does have some fairly significant down sides.  Basically, just because you add it does not mean that an application will read it or support it and your ability to leverage one of XBRL's important features which is extensibility is given up. Also, once a taxonomy is published these sorts of attributes cannot be added so using this approach after a taxonomy is published will not work.

Specific to the use case I mentioned above, you cannot add an "audit risk" attribute to the taxonomy using this approach because the taxonomy has already been published.  Likewise, no software applications would likely support that attribute even if it were added.

Use the reference linkbase

Now this is an admitted hack, but it is listed for three reasons.  First, it works.  Second, it shows something which might be missing from XBRL.  Third, it is practical and if you are using this approach internally it can provide very significant benefits.

The way the reference linkbase works is that the reference resource can have "parts" defined in a taxonomy schema and then any of those defined parts can be used in the reference resource.  XBRL International defines a bunch of parts.  These parts make sense in terms of references which might be provided, things like "Name", "Chapter", "Section", and so on.  If you define a new part, there is a very good chance that any taxonomy tool will read new parts that you define because XBRL says that they need to be able to read reference parts.

Well, let us say you want to add our audit risk metadata to your taxonomy within the reference linkbase by defining an "audit risk" reference part.  Can you do that?  Absolutely.  How much coding is involved.  Zero!  That is why this approach is so attractive.  Standard off the shelf tools will be able to read the information, edit it, just link any other thing in your XBRL taxonomy.

One drawback.  Clearly "audit risk" has nothing to do with references.  Oh will.  Yes, this is a hack, but you see the point if you tried this approach out.  What this shows is the value of some sort of generic "additional metadata" linkbase for XBRL.  You could use this much like the reference linkbase, but it would be not for references, but for any data you want to add.  Another advantage of this approach is that you can add it after a taxonomy is created, it allows for XBRL's extensibility features to prohibit and change something.

One more thing worth pointing out.  In this chase we are assuming that the audit risk would be assigned at the US GAAP Taxonomy level.  However that may not be a good assumption.  Audit risk is unique to industries and even to individual companies.  So, it could be the case that audit risk might be better defined as a characteristic of not the taxonomy, but of the XBRL instance.

Use context segment or scenario

Remembering the issue which I pointed out in the prior option, is the audit risk a characteristic of the XBRL taxonomy or a characteristic of each XBRL instance?  Different use cases could have different needs.  This is not about audit risk for our example for which you can make arguments for either approach.  This is more communicating the idea that it could be the case that the information should be in the XBRL instance and not in the taxonomy at all.  If you are going to put this in the XBRL instance, either XBRL Dimensions or your own XML Schema could be defined to provide this metadata within the XBRL instance.  XBRL Dimensions is a more standard way of doing this and will work in the vast majority of cases.  If you need more flexibility, create your own XML Schema. The down side of writing your own XML Schema is that off the shelf applications may not support what you need.

Use the definition linkbase

The definition linkbase was created for adding additional metadata to an XBRL taxonomy.  In our case, you might create three concepts such as "high audit risk", "medium audit risk" and "low audit risk" as an example and then create an arcrole "has audit risk of" and then assign relations between concepts and audit risk in the definition linkbase.

This is a very flexible approach, XBRL applications will support it, it allows you to use XBRL's extensibility features, the information can be added after the taxonomy is created.  All in all this is a very flexible approach. However, why did the US GAAP Taxonomy not use this approach for the attribute they added?  Can't tell you that.  Not many others seem to use this approach either.  However, this is a very attractive approach all things considered.

Use labels

Another hack is to use the label linkbase to add additional information to an XBRL taxonomy.  "Labels?" you say. Yes, here is the hack.  A label can contain certain XHTML markup.  Use XHTML to define a table, and put your additional data into that XHTML table.  You can put attributes on that table to define the table of information.  Perhaps the table is only one row of information.  Or, maybe you don't even need a table at all, just one or two XHTML elements of one sort or another. This would be the case for our simple example of adding audit risk in the taxonomy.  In that case you may not even need XHTML at all, you just add the information as a label.

The good thing again is that no programming is involved in the case of our simple label.  With the XHTML you might run up against some programming to create the information, you certainly would need to program something to use the added information.  You can add this information after the taxonomy had been published.  Extensibility features can be used.

Use the generic linkbase

The generic linkbase could be used to define whatever you want. That is the good news.  The bad news is that an XBRL processor may not be able to even read what is defined in that generic linkbase.  Because you can literally define anything, both the input and use of the additional metadata can be challenging for XBRL processors and off the shelf XBRLapplications. Rather than hacking the reference linkbase or the label linkbase to make those work, the generic linkbase is likely a better way to add additional metadata.  Although there is a cost.  You will need to do some programming in order to express or use even basic additional metadata such as our simple audit risk example.

Conclusion

So there you have a basic analysis of different options that I know about to adding additional metadata to an XBRL taxonomy.  The approach you pick all depends on the characteristics of the syntax into which you express your additional metadata.  It is not necessarily that one case is good and another is bad; but it is the case that in certain situations where you have specific desires and needs, you need to understand how what you create will work.  The important drivers seem to be your need for compatibility, extensibility, adding metadata after a taxonomy is published, programming resources available, and hour pallet for hacking as a practical option.