The XBRL specifications, by their very nature, are generic and designed to accommodate a range of reporting requirements. However, the XBRL professional need to understand the finer details of specifications to create a robust XBRL reporting environment. Taxonomy, as we all are aware, is designed to reflect the reporting requirements. Given that taxonomy authors have multiple ways of designing a taxonomy, it is extremely important to ensure that only valid reporting combinations are modeled in the taxonomy.
Let us take an example of XBRL taxonomy which models two data sets – a Statement of Financial position (also known as the balance sheet) and Asset quality (based on the items that are reported in the balance sheet). These two data sets share the base reporting concepts like deposits, investments, advances, etc. while some concepts like share capital and reserves are strictly not to be used for the second data set. Since all the concepts are defined in the same schema or belong to the same DTS, technically it is possible to use all items of the balance sheet for asset quality, if no restrictive mechanism is built.
Now, how do taxonomy authors restrict the usage of elements not applicable to the entry point or form? There are a couple of ways in which this can be achieved using the XBRL specification as well as a method to handle this outside the specification. In this blog, we would be explaining the impact of importing a common schema in an entry point and how to countervail this impact. There are also examples of different methods which can be adopted by XBRL implementers.
Definition Linkbase
Any concept defined in the definition linkbase as per Dimension 1.0, needs to comply with the dimension relationship when reported in the instance document. The challenge here is to create a dimensional relationship that can never be complied with within the instance document. This can be achieved through the creation of an ‘Empty Dimension’. All the ‘not to be reported’ elements need to be linked to a Hypercube which would have further had one Explicit Dimension, however, no domain members would be attached to the dimension. Since the dimension hierarchy is not further expanded to domain and members, this is referred to as the ‘Empty Dimension’.
The structure of the Empty Dimension is given in the below
-
Abstract
-
HyperCube
-
Dimension
-
Prohibited Element 1
-
Prohibited Element 2
-
Prohibited Element 3
-
Prohibited Element n
-
-
-
Dimension 1.0 requires a valid dimension and domain member combination as per the definition of linkbase in the dimensional context. Since the empty dimension does not contain domain members, a valid dimensional context cannot be created in the instance for prohibited elements. By this arrangement, the taxonomy authors can prohibit elements imported from other schemas which are not relevant for specific entry points. This then becomes an integral part of the taxonomy and would always work with Dimension 1.0 validations. For example, the 1.4 version of Corep/Finrep Taxonomy uses empty dimensions to meet the above purpose.
Formula Linkbase
The use of the formula specification is a second method to take care of this requirement. For example, a business rule can be incorporated in the formula linkbase which checks for the existence of prohibited elements. The formula so created has to be specific to an entry point. One of how a formula can be created is to define a value assertion. These value assertions would include a fact variable, which in turn would have an ‘OR’ filter. The ‘OR’ filter can include a list of all concepts ‘not reported for the specific entry points. The expression to be used can be ‘not empty’. The value assertion would fail if the instance document reports prohibited elements. Constructing a formula in this manner can validate if there is the presence of unacceptable elements in the instance documents.
Filing Rule/Manual
A filing Rule/Manual is a document generally made available to filing entities stating the rules to be followed while preparing instance document. A generic rule can be mentioned in the filing manual which states entities are prohibited from using concepts not explicitly defined for the entry point. Since this validation is outside the XBRL specification, there would be custom validation to be built into the application generating /accepting instances documents. MCA-India 2012 and EBA 2013 taxonomies have mentioned such validation in their filing manual.
As we have seen, there are multiple ways of doing the same thing, and each has its pros and cons. The XBRL system implementer has to choose the alternative best suited for the purpose.
