Moving from paper-based reporting to digital one has been gaining strength in the last few years. And with the many benefits XBRL has to offer, it has become the leading choice for a digital reporting standard, especially in the regulatory space. Over 100 regulators across 60 countries have already adopted XBRL and transformed their compliance and regulatory reporting due to the many benefits it offers.
While many regulators are adopting XBRL, several are also realizing the need for easy maintenance once their implementations have been in place for some time. Is this possible?
Taking a Proactive Approach to XBRL Taxonomy Development
The XBRL taxonomy forms the foundation of any XBRL implementation and defines the reporting concepts, their interrelationships, and validation rules, all in a standard and structured manner. Any change in taxonomy involves alterations – some that are superficial and easier to manage compared to others that require a change in the taxonomy architecture level itself.
Some typical causes for a taxonomy revision include a change in the underlying accounting principles, additional disclosures, and business requirements, or an increase in the scope of entities being covered under the framework. If any of these changes are significant, there is no option but to update the taxonomy. But some changes can be handled outside the taxonomy as revising the entire taxonomy to accommodate them may seem like a lot of work.
Naturally, the question arises – Can the taxonomy be designed to adapt to a certain level of change in business requirements, without having to undergo a full revision?
Business Requirements that can be Addressed Without Revising the Taxonomy Architecture
Some changes in business requirements for an existing implementation can be easily modeled without a revision and only necessitate an update to the existing structure. For example:
- Updating labels, references, documentation, and guidance notes
- Changing values in a predefined list (enumerations)
- Including additional domain members in a hierarchy or removing some existing ones
In this post, I will take the example of domain members to explain what could constitute dynamic information and also ways of handling it.
Let me explain what I mean by domain members by taking a reporting scenario. Table 1 gives an extract of a sample reporting template for loan maturity.
Table 1: Sample Reporting Template for Loan Maturity
The most common method of modeling this data in the taxonomy is to use XBRL Dimensions.
The concept ‘loan’ which is the base reporting item can have values under several maturity buckets which are referred to as domain members in XBRL. Since the maturity buckets in this table are limited and can be pre-defined, these are included in the taxonomy as members of an explicit dimension.
While framing the initial business requirements, the regulators may suggest the extent of data they require for this particular item. In this case, assume that they have finalized the granularity to be as depicted in the table for 3 members only i.e. 0-90, 90-180, above 180 days. Considering there are limited buckets that need to be defined under this concept, taxonomy authors restrict the concept ‘loan’ to only expect 3 values under these 3 heads.
Once the XBRL reporting framework is implemented and the regulator starts receiving data from various entities, they realize the need for more granular data. They approach their XBRL vendors with a requirement to extend the maturity buckets and have 5 instead of the original 3 categories – 0-30, 31-60, 61-90, 90-180, and above 180 days. To them, it seems as easy as inserting a few additional columns into a spreadsheet. At least, that’s how the discussion starts.
Yes, the change is easy, but it means releasing a new version of the taxonomy and that comes along with things like versioning, updating the technology platform, communicating with stakeholders, etc.
To avoid such issues regulators look for a solution that is not tightly coupled with creating a new taxonomy version.
Using Typed Dimension to Meet Changing Business Requirements
One workaround for this example is to define the aging buckets as an open list and hence as a typed dimension. With typed dimension, the need to define the exact aging buckets in the taxonomy goes away. The filers can define the aging buckets as per their reporting patterns. However, the concern in keeping an open list is that filers are given unlimited flexibility to provide classification buckets as they wish.
To ensure standardization, the expected aging buckets can be communicated through other channels such as a filing manual or a list outside the taxonomy that can be referred to while creating the XBRL data. And to ensure complete adherence, business rules can be built for validation to ensure that all filers are using the same maturity buckets.
We have implemented this for a few regulators such as the Reserve Bank of India and the Bank of Mauritius and it does work well. Regulators are usually happy with this solution because it provides the flexibility to change the classification/break-up without the need to create a new taxonomy version. With this, they gain control over their data needs while ensuring that consistent and clean data flows into the system.
The solution is a workaround and is software dependent. As it lies outside the XBRL framework (read taxonomy), it is not universal even if it works well for the regulator. This workaround also limits the use of some basic attributes of XBRL such as multi-language labels, references, robust dimensional modeling, intelligent validation rules, version control, etc.
However, workarounds are necessary sometimes to avoid cost and time implications.
And given this is a universal requirement and many implementations possibly have some workaround already weaved into them, we might well see a new XBRL specification for this in the future. At least I hope so.
XBRL implementation is tricky and requires plenty of experience to ensure that appropriate methods are used right at the beginning. Instead of relegating it only to taxonomy definition and platform development, regulators must think through and debate their entire digital reporting strategy and only use best-in-class practices.
With more than 15 implementations in 9 countries worldwide, we have a wealth of experience to gauge every regulator’s business requirement – something they might find difficult to do themselves at the outset.
You may reach out to us to know more about how we can help you defining your digital reporting strategy.
Or mail me at revathy.ramanan@irisbusiness.com with any comments you have.
