OIM Taxonomy in Practice: Exploring the Emerging Possibilities
XBRL International is working a strategic modernisation of the XBRL standard, and that’s what OIM Taxonomy is all about. In this two-parter, we set out where we are, what we’re aiming for, and where – with your help – we’re going next. Both posts are based on internal presentations by Paul Warren, XBRL International’s Technical Director.
In the previous post, we outlined six high-level goals for OIM Taxonomy, our core endeavour in modernising XBRL for the needs of today. As we work towards publishing a first Public Working Draft, this post explores some of the emerging practical capabilities that will make the new taxonomy model simpler, more flexible, and more useful across a much wider range of reporting contexts.
A taxonomy model that reflects reality
We’ve recognised that taxonomies serve different roles, and an updated model should embrace that rather than treating all taxonomies the same way.
In practice, we see three main types of taxonomy:
- definitional taxonomies, such as the IFRS Accounting Taxonomy or XBRL International’s currency and country codelist taxonomies, that provide a shared set of re-usable definitions for a particular domain
- reporting requirements taxonomies, like the EU’s ESEF Taxonomy, that assemble those concepts into a framework for filers
- entity-specific extension taxonomies, which individual organisations create to add their own concepts alongside the base taxonomy
By explicitly recognising these different roles, OIM Taxonomy can provide better support for each of them.
For example, data collection authorities often want to constrain how filers use extension taxonomies, and how much an entity-specific extension can modify the base taxonomy. Such rules protect comparability, for example by preventing the use of new labels for existing concepts. OIM Taxonomy will cut reliance on lengthy, separate filing manuals and make these constraints part of the taxonomy itself. One useful tool could be a “final mechanism” that would allow specific components to be marked as non-modifiable by extensions.
Smarter imports and selective loading
OIM Taxonomy will also introduce a much more sophisticated approach to how taxonomy imports work.
It is difficult today to efficiently reuse specific components from a larger taxonomy, so we are creating clearer, more standardised mechanisms. Taxonomy authors will be able to specify which parts of an imported taxonomy are made available to downstream users – so, for example, if the ESEF Taxonomy imports the IFRS Accounting Taxonomy, it will be easier to control precisely which IFRS concepts are provided to filers.
Selective loading mechanisms will enable processors to make informed decisions about what to load, or which bits of a taxonomy to prioritise. When an import clearly declares its contents – for example, that it is a label bundle for a particular language – a processor that doesn’t need that component can simply skip it. This promises significant improvements in performance and to the overall developer experience.
There’s also a new requirement for supporting “add-ons” for a taxonomy. Under the current specification, the taxonomy for a report is fixed by the links from the report to the taxonomy, but there are often cases where it is desirable to dynamically add additional taxonomy components, such as translations of labels in different languages, or taxonomies containing data quality rules. OIM taxonomy will provide support for these taxonomy add-ons, including taxonomies published by third parties.
A general-purpose properties mechanism
OIM Taxonomy will include a general-purpose properties mechanism that allows structured key-value metadata to be attached to taxonomy components. This provides a standardised way to capture things like deprecation flags for concepts that are due to be retired, including date information, in a form that tools can read and act on consistently, rather than as free-text strings that vary from taxonomy to taxonomy.
Supporting a broader range of reports
XBRL is increasingly being used well beyond traditional periodic financial statements, including sustainability reporting, energy reporting, real estate reporting and supply-chain reporting. OIM Taxonomy formalises support for these and a broader range of use cases.
For example, the advent of xBRL-CSV has allowed greater use of XBRL for record-based reporting. We are working to ensure that the model is genuinely fit for purpose across several distinct types of record-based data, including:
- event data: records related to specific event which must be anchored to a specific date and time, such as a security incident or a corporate action
- reference data: data that doesn’t change or changes very slowly, like entity identifiers or stock symbols
- position data: values reported at a point in time, such as balance sheet figures, credit risk positions, or VAR (value at risk) compliance numbers
- listing data: facts about individual items or units, such as assets in an inventory
- time-series data: repeated measurements at regular intervals. These could encompass everything from regulatory reports about open derivative contracts at the end of day across an entire year, to hourly records about sunshine falling on solar panels
That also means we need standardised mechanisms for people to do things like specifying mandatory and optional fields within a record, adding uniqueness constraints to specific fields across a set of records, and defining primary key/foreign key relationships between different parts of a report. These capabilities exist in various forms today but will be brought into the core taxonomy model in a consistent way.
More broadly, a core goal for OIM is to make the taxonomy model more flexible and more generic, in order to provide support for a broader range of reports.
Richer declarative constraints
Finally, we’re working towards a significantly more capable constraints model. This includes the ability to mark elements as mandatory – a basic but very useful feature – as well as conditional constraints, record-level requirements, and co-constraints that express relationships between facts, for example, “if this fact is reported, that fact must also be reported.” These come in handy, for example, in a scenario where company size determines which sustainability disclosures it needs to make.
The practical benefit for preparers is considerable. When a reporting tool knows which fields are required and what rules apply, it can guide users through the process of preparing a report proactively, surfacing requirements and potential issues as they work rather than presenting a list of validation errors at the end. Better guidance means better data, and that benefits everyone in the reporting chain.
Shaping the specification together
The ambition is a taxonomy model that is truly modern: simpler and with fewer barriers to engagement; accessible to developers, analysts, regulators and AI tools alike; and expressive enough to support the full range of ways XBRL is used today and in the future – all while building on and preserving the considerable investment the community has already made.
We’re working to cement all those goals in a first draft of the specification. We will soon need your input in the process of reviewing, testing and refining each draft release if we are to meet the full range of needs across the diverse digital reporting community. We are particularly keen to hear your real-world experience from diverse use cases, and your perspectives on the scenarios being addressed, for example around modular reporting requirements and the interaction between extension constraints and imported taxonomies. Let us keep you in the loop on progress here.
