BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries in Leaf level extension (1)

XBRL Extension: Three Reporting Models, Not Just Two

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.