This document defines requirements for the OIM Taxonomy Model. OIM, or Open Information Model, is an initiative to modernise XBRL by providing a syntax-independent model of XBRL semantics. The first phase of the OIM initiative was the OIM Report Model, which underpins the xBRL-CSV and xBRL-JSON report formats.
The OIM taxonomy model aims to extend this modernisation to encompass XBRL Taxonomies. Although this project shares the "OIM" name, the scope for change is significantly broader than the earlier OIM Report initiative. Whereas the OIM Report Model took the approach of providing a simplified view onto existing XBRL report functionality, the OIM taxonomy model is expected to introduce much more substantive changes to existing XBRL taxonomy functionality.
This requirements document remains under development and will be updated in the future to include additional requirements.
Reviewers are encouraged to send feedback to oim-feedback@xbrl.org by 16th February 2026.
The core functionality currently provided by XBRL taxonomies is defined by the 2003 XBRL v2.1 specification, and extended by a number of additional specifications:
The OIM taxonomy model should provide:
A technical specification for a syntax-independent XBRL Taxonomy Model. This should define the information represented by an XBRL taxonomy without reference to a specific syntax.
A technical specification for a standard syntax for representing an XBRL Taxonomy. This will be the default format for publishing or exchanging XBRL taxonomies.
The term OIM taxonomy model is used to refer to both of these deliverables.
The two deliverables may form a single specification, or may be modularised as required.
The OIM taxonomy model should achieve the following high-level goals:
XBRL taxonomies play a crucial role in defining the meaning of an XBRL report, but XBRL 2.1 taxonomies are inherently difficult to consume. This results in consumers often failing to make full use of XBRL data.
The OIM taxonomy model should make consumption of the taxonomy information accompanying an XBRL report a straightforward process.
Users are increasingly looking to leverage Large Language Models (LLM) to consume XBRL reports. Investigation has shown that XBRL report data, particularly in xBRL-JSON format, is readily consumable using such tools, but the supporting taxonomy information is not effectively usable in its current format.
The OIM taxonomy model should enable optimised consumption of XBRL reports and the supporting taxonomy information using AI tools.
Developers will often attempt, at least initially, to understand XBRL data without reference to the specifications. Typically this is done by inspecting the XBRL reports collected and published by a regulator. XBRL 2.1 taxonomies are very hard to understand from such an inspection, resulting in consumers either making false assumptions about the data, or ignoring much of the information in the taxonomy.
XBRL taxonomies using the OIM taxonomy model should be intuitively comprehensible to a developer with minimal prior XBRL knowledge.
Current production taxonomies often feature a large number of definitions, and are often modularised across a very large number of files. This, coupled with the processing and memory overhead of XML and XLink syntax, can lead to poor performance when opening taxonomies.
The OIM taxonomy model should facilitate the performant loading of large taxonomies.
XBRL 2.1 provides a great degree of flexibility, enabling different approaches to modelling particular reporting requirements. This results in inconsistency between different XBRL implementations, which in turn limits the extent to which XBRL software can be re-used in different environments.
The OIM taxonomy model should promote a single, preferred approach to modelling a particular reporting requirement.
A key use case for XBRL is regulatory reporting, where reports are submitted to a data collection authority. Such environments will invariably have rules that a report must adhere to in order to be accepted. XBRL 2.1 currently provides limited functionality to support this, other than XBRL Formula. Although XBRL Formula is powerful, there is benefit in capturing simple constraints in a declarative format, as it enables tools to guide users to create valid reports, and reduces the need for separate, human-readable rule definitions.
The OIM taxonomy model should provide stronger declarative validation capabilities in order to reduce the reliance on unstructured filing rule manuals, and rules-based validation such as XBRL Formula.
REQ-GEN001-OIM-Compatibility The OIM taxonomy model should be consistent with the OIM report model, as currently defined. An update to the OIM report model may be considered if it enables a significant improvement to the OIM taxonomy model.
REQ-GEN002-Completeness. The OIM taxonomy model must be able to provide functionality equivalent to that of XBRL 2.1 constructs that are in common use and consistent with current XBRL best practice. It is not necessary for the OIM taxonomy model to represent everything that is currently possible within XBRL 2.1's XML syntax.
REQ-GEN003-Ordering. Where the OIM taxonomy model specifies a component as being a collection of items, the model must explicitly state whether the order of those items is semantically significant.
REQ-GEN004-BackwardsCompatibility. It should be possible to convert existing XBRL 2.1 taxonomies into the OIM taxonomy model, provided that they use functionality within scope of the OIM taxonomy model (see REQ-GEN002-Completeness).
Due to the different modelling approaches in use in existing taxonomies (see Section 5.5), the conversion process may require some configuration in order to define mapping into OIM taxonomy model constructs.
XBRL taxonomies are used in different roles, with different requirements. XBRL taxonomies can also be comprised of multiple component taxonomies using the XBRL extension mechanism.
This section describes use cases and requirements for these different roles, and for the taxonomy extension mechanism.
XBRL adoption has, to a large extent, been driven by regulatory data collection systems. In such a system, a data collection authority publishes a set of reporting requirements that reports submitted to them must comply with.
XBRL taxonomies provide a standardised way of communicating these reporting requirements in a structured format.
Reporting requirements taxonomies include constraints that reports must adhere to in order to be accepted by the data collection system. XBRL 2.1 taxonomies have limited scope for capturing such constraints in declarative format, and are often accompanied by "filing manuals" that describe additional filing rules. The OIM taxonomy model should aim to increase the scope of rules that can be captured in a taxonomy, and thus reduce the reliance on separate filing manuals.
CSV is often used to publish large datasets. Using xBRL-CSV for this purpose retains the simplicity of the CSV format whilst providing structured XBRL taxonomy metadata, such as descriptions, translations, links to authoritative definitions, and domain hierarchies.
In this use case, there is no reporting requirements taxonomy, as the taxonomy is selected or created by the same entity as the data publisher.
In some filing scenarios, an XBRL report will need to use concepts, dimensions or members that are specific to that entity, and which are therefore not included in the reporting requirements taxonomy. In this case, the report preparer will create an entity-specific report taxonomy that adds the additional definitions.
In such an environment the reporting requirements taxonomy is the taxonomy on which the report taxonomy is based.
The data collection authority will typically wish to constrain the types of extension permitted in the report taxonomy. For example, the filer may be permitted to add new concepts and labels, but not to modify or remove the labels for existing concepts.
Taxonomies will often import common components from other taxonomies. For example, XBRL International publishes taxonomies containing definitions for the Legal Entity Identifier (LEI), and code lists for ISO currency and country codes. Re-using these definitions prompts consistency between different reporting environments, and reduces effort required to create taxonomies.
Similarly, one reporting domain may make use of definitions from another. For example, sustainability reporting may make use of some financial reporting definitions. When building an XBRL taxonomy for such a domain, it is desirable to re-use (rather than redefine) definitions from an authoritative taxonomy, such as the relevant accounting standard taxonomy.
A data collection authority may create a reporting requirements taxonomy by importing other taxonomies. For example, the European Single Electronic Filing (ESEF) system publishes an ESEF reporting requirements taxonomy that imports the IFRS accounting standard taxonomy. This use case is similar to the previous use case; the difference is that in this case, the imported taxonomy provides the vast majority of the reporting definitions, and the reporting requirements taxonomy provides a small number of additional concepts needed by the filing system.
REQ-EXT001-RestrictExtension. It should be possible for a reporting requirements taxonomy to constrain the ways in which an extension can modify the taxonomy model. Such constraints include:
It should be possible to define such constraints at the component level (e.g. allowing extension of some domains, but not others).
Labels for taxonomy definitions are often translated into different languages. A particular user will typically only require labels in a single language. It is desirable to avoid unneeded labels, or to defer loading them until they are requested. This is not currently possible as, under the XBRL 2.1 discovery process, any imported file may import other components of any type.
In some cases, translations of taxonomies are developed by third parties, and may be published after the publication of the underlying taxonomy. Users should be able to easily add additional labels that are released separately from the main taxonomy. XBRL 2.1 does not provide a mechanism for adding additional resources to a taxonomy; the DTS is effectively fixed by the set of taxonomy URLs referenced by the report.
Data quality rules are automated rules that identify potential issues with the data in an XBRL report. Unlike filing rules, a failure of such rules would not generally lead to a rejection of the filing, and the rules may be maintained by a third party. It should be possible for users to selectively apply such additional rules, in order to test for comformance with data quality rules. In XBRL 2.1, XBRL Formula rules form part of the DTS, which is effectively fixed by the set of taxonomy URLs referenced by the report. As, such there is no standard way to augment the DTS with additional rules.
REQ-EXT005-ExtensionBundles. It should be possible to define a taxonomy that provides additional resources for another taxonomy. Such a taxonomy is referred to as an add-on bundle.
REQ-DIM001-HypercubeDimensionConstraints. It should be possible for a hypercube to define any dimension other than the concept core dimension as being required, optional or prohibited (the concept core dimension is required for all facts). These constraints control which facts are included in a hypercube.
This extends the functionality in XBRL 2.1 by:
REQ-DIM002-CoreDimensions. It should be possible for a hypercube to constrain core dimensions, such as period, units and entity, in addition to taxonomy-defined dimensions. The constraints should include specifying dimensions as required, prohibited or optional for a hypercube.
Note that although entity and period must be reported explicitly under XBRL 2.1 syntax, the OIM Report Model treats them as optional. The OIM taxonomy model should be consistent with the OIM report model on this point.
REQ-FP001-Relationship. It should be possible to define relationships between fact positions and other taxonomy components.
A common scenario in financial reporting is to disclose a figure that is the total for a particular breakdown, and also disclose that the total amount is attributable to a component of that breakdown. This is often done implicitly by omitting a separate figure for the total. This creates a challenge for XBRL reporting, as tagging the figure as either the total or the component risks losing information.
Allowing relationships to be associated with fact positions would allow the definition of a relationship to associate the fact position with the domain member representing the specific component to capture this information.
REQ-TF001-TaxonomyFacts. It should be possible to include facts in a taxonomy. This is intended to support facts that would be common across all reports using a taxonomy, such as a tax rate.
REQ-PROP001-PropertyModel. The OIM taxonomy model should support a general-purpose mechanism for defining properties for associating key/value metadata with taxonomy objects.
REQ-PROP003-CollectionTypes. Properties should support list and set-based datatypes.
REQ-PROP005-PropertyExtensibility. It should be possible for extension taxonomies to define additional properties, or extend the applicability of existing properties, subject to any restrictions imposed by a reporting requirements taxonomy.
REQ-ATT001-FactAttributes. The OIM taxonomy model should provide a mechanism for defining structured attributes that may be associated with facts. Attributes allow additional, non-dimensional information to be associated with a fact value.
There are a number of use cases where it is desirable to attach additional information to a reported value. Such information is a property of the value, and does not alter the fact position. These include:
REQ-REL001-Relationships. The OIM taxonomy model should support relationships between taxonomy components.
REQ-RT002-RelationshipTypes. The OIM taxonomy model should define relationship types as objects that can be used by the same taxonomy, or re-used in other taxonomies.
XBRL 2.1 is used for a wide variety of different report types, but the specification has a number of features designed to meet the specific requirements of financial reporting, such as the balance attribute and the mandatory period dimension (the period dimension is considered optional under the OIM Report Model).
The OIM taxonomy model should provide support for a broad range of different report types. Any features that are specific to a particular type of report should either be optional, or should be omitted from the specification and implemented using defined extension features, such as custom relationship types.
REQ-NFR001-RecordData. The OIM taxonomy model should support reporting of record-based data. Record-based data is data that consists of repeating sets of facts.
The OIM taxonomy model should support the following features related to record-based data.
The OIM taxonomy model should support the following types of record-based data.
REQ-NFR006-EventData. Event data is data where each record relates to a specific event. Records will include a mandatory field containing the date and time of the event.
REQ-NFR010-PositionData. Position data is data that is reported at a point in time.
REQ-NFR011-ListingData. Listing data is data that that is reported about individual items or units.
Reporting requirements frequently include a number of facts that must be included in all reports, such as the reporting entity's name.
REQ-RC001-MandatoryElements. It should be possible for an OIM taxonomy model to specify certain fact positions as being mandatory, indicating that facts must be reported for those fact positions in a report.
Existing specifications provide functionality for representing the multi-dimensional model of XBRL 2.1 as two dimensional tables. These existing specifications provide different, but overlapping functionality:
The functionality provided by these specifications supports a number of important use cases, including:
This document does not provide detailed requirements for the functionality provided by the specifications.
REQ-TAB001-TabularReporting. The development of the OIM taxonomy model should yield a roadmap for future development of specifications that provide a coherent set of tabular reporting features.
REQ-TECH001-XMLSchema. The OIM taxonomy model may make use of the XML Schema data type system. The OIM taxonomy model must not depend on XML schema complex content models, or other parts of the XML Schema specification.