Digital Financial Reporting

I used to think that there were two models for extension of XBRL taxonomies for reporting using XBRL: static and dynamic.  Now I think there are at least three. Let me summarize the three XBRL taxonomy extension models one might make use of for reporting:

• Static: By static I mean that the extension of your XBRL taxonomy is not allowed at all. This reporting model is what amounts to a form.  Tax forms is one example.  Basically the user fills in all the boxes on the form.  This type of reporting is easy to implement in XBRL as you don't have users making modifications to the XBRL taxonomy so users there is less for them to learn.  Also, because the report is a form software applications are easier to build.
• Dynamic: By dynamic I mean that extension of your XBRL taxonomy is allowed.  This reporting model is more like SEC reporting by public companies.  Users can extend existing relations and concepts or add entirely new relations and concepts.  What users add in terms of an extension needs to be consistent with the XBRL taxonomy they are extending.
• Leaf level extension: I don't quite know what to call this yet, so for now I will call it "leaf level extension". What I mean by that is rather than giving those that report to you the ability to add new relation structures, they can only add new relations and concepts to existing structures.  Extension is allowed but there is less that the business users need to understand about XBRL taxonomies.  Users are not allowed to add new structures, only add things to existing structures.  What can be added can be more easily controlled by software as the existing XBRL taxonomy serves as a guide to adding the new leaf relations and concepts.

I am not making any judgements here about which XBRL extension model one should use in any specific case, this is more about pointing out the spectrum of options which you have. I can see scenarios where say a regulator did not allow extension within their reporting model (i.e. static reporting, a form) but really would like to allow business users to do some extension as it would improve the reporting scheme or system.  Allowing leaf level extension provides some additional flexibility, but not increasing complexity to the degree that complete dynamic reporting would entail.

And it is not that these three models need to be used in isolation.  For example, if you look at say SEC XBRL reporting using the US GAAP taxonomy, there are areas of the XBRL taxonomy which you would want to work like a form (i.e. the user cannot change those areas at all), there are some areas where you want the users to be able to add leafs to existing relations and concepts and finally there are certain occasions where the user will need to add entirely new relations and concepts, providing complete flexibility to the business user.

It is up to the business domain to determine the needs of their reporting scheme.  Just realize that you have options and that each option brings a basket of characteristics to the table.  You have to mix and match what you need with how you implement XBRL taxonomies within your system.

I was very fortunate to participate on the team that created the US GAAP Taxonomy Architecture.  Part of this is how could you not learn a lot discussing things with people like Walter Hamscher, David vun Kannon, Campbell Pryde, Paul Sappington and Cliff Binstock (i.e. the other co-authors of the architecture).

Part of what we discussed and to a degree addressed in the US GAAP Taxonomy or realized that we could not address was the notion of extension points and extensibility rules.  These topics had come up before, we drilled into them in greater detail in creating that architecture.  Here are general definitions of these two terms:

• Extension points: logical points in a taxonomy where extension makes sense. These are generally technical in nature.
• Extensibility rules: rules relating to where a taxonomy can be extended.  These are generally domain related and have to do with semantic meaning.

Looking at a taxonomy will help make the difference between the two make more sense.

Extension points

Take a look at the figure below (for more information see the "Calculation" metapattern on this page, number 3):

The green areas in the graphic are extension points. It makes sense to add new members to a domain, new periods, perhaps new units, and a new concept to the list of concepts which make up some total.  For example, on row 10 above, it makes sense to add the concept "Airplanes" to an extension taxonomy and put it in that precise location in an XBRL taxonomy which extends another taxonomy. Likewise, it makes NO sense to do things like add a member as a child of the concept "Land".  These extension points are incredibly helpful to understand for a lot of different reasons.  One reason is that software can be built to make creating or extending an XBRL taxonomy a whole lot easier if these extension points are known, they are consistent, and they are communicated in some manner by the creators of a base XBRL taxonomy which someone else is extending.  I could go on and on pointing out good and bad examples, but I think you probably see the point here.

In the US GAAP Taxonomy does have extension points, even though they are not formally communicated.  For example, see section 4.5 Implementing Tables in the US GAAP Taxonomy Architecture document (page 34).  Realizing this can help you to more easily create appropriate extension taxonomies.

Extensibility Rules

Extensibility rules are different from extension points, but they can be very helpful in another way.  So, as an example, imagine the US GAAP taxonomy. (Or you can go look at it here.)

Consider the concepts "Assets [Abstract]" and "Liabilities and Stockholders' Equity [Abstract]". From a financial reporting business domain perspective, what sense does it make to add a concept into the US GAAP Taxonomy as a sibling to those two concepts?  What would that concept be?  Well, it doesn't make sense in this particular case, a balance sheet has two things which when added up the totals should be the same: total assets and the total of liabilities and equity.  That is why it is called a balance sheet.

There are other areas of a taxonomy where this same thing is true, extensions make no sense. For example, a cash flow statement breaks cash flows into three categories:  operating, financing, and investing.  That is dictated by the financial reporting literature.

What other areas does it make sense to not allow extension or two allow extension?  Should users of the US GAAP Taxonomy be able to add balance sheet line items?  Well, there are actually pros and cons to that.  On the one hand, what line item would they possibly want to add?  If it should be there, it probably already exists in the US GAAP Taxonomy.  On the other hand, it was not the case that things like Goodwill or Intangible assets ever existed on anyone's balance sheet.  But, finance reporting standards evolved, and these line items are in the financial reporting rules.  Allowing extensions at certain points really relate to financial reporting standards, not XBRL.

Generally it is the case that the deeper you get into a tree of concepts, the higher the probability that extension should be allowed.  The higher you are in a tree of concepts, the less likelihood that you would need to extend the US GAAP Taxonomy.  There are plenty of excepts to this rule, but in generally, that statement is fairly accurate.

How do you communicate extension points and extensibility rules?

Well, there is no standard way to do that now and there is no formal articulation if this information. This holds true for the US GAAP Taxonomy, the IFRS taxonomy and any other taxonomy which is out there really.

But why WOULD you communicate this information? Well, say there were a way to automate the process of detecting when a user extended a taxonomy in the wrong area (violated an extension point) or that the put a net tree of concepts on the balance sheet as a sibling of assets and liabilities and equity (violated an extensibility rule) and you could point this out to the user.  Or even better, the application simply would not let you make that mistake.  Or how about if a wizard lead you through the process of extending or building a taxonomy because the wizard had knowledge of such extension points and extensibility rules.  Wouldn't that be helpful to users?  I think so.