The XBRL specifications, by its 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 in order 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 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 - Statement of Financial position (also known as 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 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.
Any concept defined in 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 which can never be complied within the instance document. This can be achieved through creation of 'Empty Dimension'. All the ‘not to be reported’ elements need to be linked to a Hypercube which would have further have 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 as 'Empty Dimension'.
The structure of Empty Dimension is given in the below
- 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 definition 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 schema but 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 dimension to meet the above purpose.
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 existence of prohibited elements. The formula so created has to be specific to an entry point. One of the way in which 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 list of all concepts ‘not be reported’ for the specific entry points. 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 presence of unacceptable elements in the instance documents.
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 in 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 having its own pros and cons. The XBRL system implementer has to choose the alternative best suited for the purpose.