What is taxonomy extensibility?

To recap from the first post in this series, “an XBRL taxonomy is the formal definition of a financial or business reporting vocabulary for a given jurisdiction or reporting domain, imparting meaning to the concepts which describe the facts being reported and providing a framework within which reports are structured. It defines the ‘contract’ between reporter and regulator”.

It may be that a reporting requirement can be explicitly and completely stated a priori, in which case the regulator’s taxonomy is all that is required. However, not all reporting requirements are so clear-cut. In particular, company financial statements can be very diverse, reflecting the diversity of companies and company accounting in general. Therefore, unless some other aspect of the reporting regime restricts what needs to be reported in XBRL to the concepts in the taxonomy, accounting taxonomies sometimes or always need to be extended in practice.

The ‘X’ in XBRL stands for ‘eXtensible’ of course; technical extensibility is built in to XBRL from the ground up, enabling a ‘base’ taxonomy to be extended, possibly multiple times, by parties other than the original author. Whether a taxonomy should be or needs to be extended in practice, however, is a matter for the regulator and the manner in which the regime operates.

Therefore, all three taxonomies we’re considering are capable of being extended, but they are designed for environments where the requirement to extend or the need to extend is very different.

The IFRS taxonomy

The IASB’s philosophy is that its IFRS Taxonomy provides building blocks that users (both taxonomy extenders, such as regulators, and instance document preparers) can employ in extension taxonomies to represent the data they want to report.

The default position from the outset is that extension is the norm (because the taxonomy as it stands is not adequate for most practical purposes), but there is no effective control over how the building blocks are used and how extension is undertaken. Users have total freedom to extend.

This is likely to result in poor comparability between instance documents that utilise different extensions unless extension in a given jurisdiction is rigorously enforced over the preparers in that regime. Even then, any reasonable degree of comparability would be restricted to that jurisdiction.

Only relatively recently has the IASB issued guidance for regulators that contains “best practice” advice on extension style and architecture, but this only goes so far to avoid filing system implementations that are incompatible with each other, somewhat destroying the intent and benefits of an international standard. It almost certainly won’t result in consistency and comparability between instance documents produced in different jurisdictions.

Even more recently the IASB has issued guidance for preparers but it has little to say on maintaining the consistency and comparability of instance documents when preparer extension is permitted in a given jurisdiction, threatening even comparability between instance documents within a jurisdiction.

The US GAAP taxonomy

The US GAAP Taxonomy was designed with preparer extension in mind, whilst at the same time pursing a goal of limiting the need for extensions to facilitate period-to-period and cross-industry comparability. This approach is reflected in the large number of reportable concepts and dimension members in the taxonomy, which is in part an attempt to cover the broadest possible range of information within the bounds of practicality (as well as a consequence of the sheer breadth of US GAAP itself). Nevertheless, experience has shown that the majority of SEC filers find it necessary to provide their own additional concepts (as part of the mandatory filer extension taxonomy) to supplement their instance documents. The goal of general comparability has clearly not been met (as yet).

“Design for extension” is incorporated in the taxonomy’s Logical Model, a key principle of which is “Disciplined Extensions”. This appears to be based on design rules that ensure an internally consistent taxonomy that others will need to extend. However, this is a necessary but not sufficient principle to ensure disciplined extension. What is needed are rules or guidelines for extenders to follow, but this is precisely what is not offered by the taxonomy architecture: It is beyond the scope of the architecture to create a formal expression of extension rules to facilitate “disciplined” or “channelled” or “managed” extensions within systems that use it. (from section 1.3, Logical Model). Instead it is left to implementers of software systems to build such formal expressions, so it is little surprise that the approach has met with limited success.

The UK FRS taxonomy

The UK FRS Taxonomy provides no specific support for extension, nor any encouragement for it, but equally it does not preclude it. The coherent nature of its data model, as we have already seen, along with the inclusion of exemplars of the use of typed analysis and grouping dimensions, suggests particular ways in which the taxonomy could logically be extended.

The presence of the analysis (“breakdown”) and grouping dimensions and the way in which they are employed in the taxonomy may well preclude the need for private extensions in the first place if the primary goal of an extension is to provide more detail (as opposed to new reportable concepts or different arrangements of dimensions). However, this is an approach that goes hand in hand with other aspects that may not always be practicable or available in a given jurisdiction.

The UK FRS Taxonomy has been created for use in an environment where Inline XBRL is used for company financial reporting. As a consequence, the ability to extend is not one of its primary goals. Experience has shown that in the presence of Inline XBRL, preparers and filers have not felt the need to extend the scope of the marked-up data that they disclose, preferring instead to disclose such information in the human-readable view only. Given this, the ability to extend is not promoted by the UK FRS taxonomy documentation in the same way as it is with the other taxonomies.

Conclusion

Again, we see a spectrum of capabilities that reflect the growing experience of taxonomy designers over the generations, this time in terms of extensibility. The oldest taxonomy design is the most promiscuous – just about anything goes with the IFRS taxonomy but the IASB has at least issued guidance and best practice advice. Both later taxonomies each take a much more controlled approach in their own way and to suit their intended audience.

As a single-jurisdiction taxonomy US GAAP is more likely to be subject to private rather than public extension, for the purposes of entity-specific disclosure. Its disciplined extension approach is designed to constrain extensions in an attempt to preserve comparability as much as possible, but it lacks any kind of policing to enforce it.

The UK FRS taxonomy is designed to operate in an environment where entity-specific disclosure is not, in general, expected to be tagged as XBRL, but instead made available to human consumers as HTML content. Entity-specific extensions are therefore largely unnecessary and very uncommon. It does, however, provide capabilities for entities to extend tagging to provide more detailed breakdowns or to provide arbitrary groupings of facts without the need for entity-specific taxonomy extension.

With each generation, taxonomy designers learn more about the uses to which their taxonomies are put and develop or acquire techniques to steer extenders in a direction that helps to preserve the underlying comparability and consistency of data.