This document is a review draft. Readers are invited to submit comments to the Best Practices Board.
Table of Contents
1 Introduction
Taxonomies are the domain-specific dictionaries used in XBRL reporting. They define the specific concepts used for individual facts (such as “net profit”), their attributes, rich metadata and their interrelationships. The metadata includes multi-language labels, links to authoritative definitions, such as accounting standards or relevant local laws, and validation rules.
XBRL Taxonomy development typically involves a set of standard steps and decisions. This taxonomy quick start guide provides a checklist of various aspects and steps to consider in the taxonomy development process. Where available, the checklist links to detailed guidance. This guide is aimed at taxonomy owners, architects, and authors. This guide assumes that the data collector has made the decision to collect reports in XBRL and is looking for guidance on how to to develop a taxonomy.
2 Taxonomy development – key steps
After answering these checklist questions and noting the steps involved in taxonomy development, you will have the necessary background to make informed decisions for creating a workable plan for a taxonomy development project.
Figure 1: Decisions and steps involved in taxonomy development-
Taxonomy objective definition (see Section 3.1)
- What is to be reported – determining the scope.
- Reason for reporting – understanding the expected use of the report for the end users so that taxonomy can be designed accordingly.
-
Overview of roles involved (see Section 3.2)
- Business specialists – those who understand reporting requirements.
- XBRL-taxonomy expert for taxonomy design, testing & implementation.
- Taxonomy governance – groups to be involved and decisions to be taken.
- Taxonomy users, including vendors and data providers.
- Decision: Do you have the requisite skills, capacity and diversity of viewpoints in house or do you need to pull in external assistance?
-
Functional requirements (see Section 3.3)
- Can an existing taxonomy be reused in whole or part to meet the data requirement?
- How is the report to be structured? For example, like a chart of accounts (hierarchical) or alternatively a set of templates (tabular).
- How will data be used?
- Is it needed, preferred or permissible that the filer extends the taxonomy?
- Is it needed or preferred to implement business rules within or external to the taxonomy?
- Is it needed, preferred or desirable to define a representation of the data or report rendering? For example, XBRL reporting templates.
- Definition of mechanisms for testing the business definition. For example, reporting and validation completeness.
-
Technical Requirements & Development (see Section 3.4)
- Selection of software tools to build the taxonomy.
- Taxonomy architecture decisions.
- Typical taxonomy authoring tasks:
- Dictionary creation
- Data modelling
- Taxonomy building
- Testing
-
Lifecycle management (see Section 3.5)
- Versioning strategy.
- Publication & notification.
- Public testing and external consultation before production use.
- Updates and bug fixes.
- Communications for news and plans.
3 Taxonomy development – a detailed overview
This sections includes a detailed explanation of steps noted in the Section 2.
3.1 Taxonomy objective definition
It is necessary to define what information must be collected in XBRL and thus scope the taxonomy accordingly. For example, a listed entity may be required to report a range of information. However, the taxonomy under consideration may include only one or a few reporting areas, such as quarterly financial statements, voting results or employee stock purchase plans.
Another important consideration to define is how that information is expected to be used, whether it be re-published for public use or consumed only internally, what insights are required to be derived or what processing needs to take place. The end use of data considerably drives taxonomy content, design and granularity. Examples of the final intended usage of the taxonomy include:
- Representing or replacing existing spreadsheet-based or other reporting formats;
- Formalizing the reporting elements in a set of reporting principles;
- Providing a specialist taxonomy module to be reused within other taxonomies; and
- Providing information around data relationships and connectivity.
3.2 Overview of roles involved
Taxonomy development requires a range of expertise. Consider including taxonomy team members having business, XBRL and information technology background. Business or domain specialists who understand the reporting requirements and end use of the information collected are required. XBRL taxonomy experts are needed to model the business requirement in taxonomy. IT specialists are required to support the taxonomy publication, integration with the data collection platform, other systems involved, and business intelligence applications. The availability of XBRL taxonomy experts in-house determines if an external expert needs to be consulted. The taxonomy development should also set up a governance group to include internal and external (data users, software vendors) stakeholders to review taxonomy decisions and development.
3.3 Functional requirements
Before starting the taxonomy design and modelling, a few decision points need to be worked out.
The most important step is to determine whether the reporting requirements are "open" or "closed", as this will drive the choice of XBRL report format, and other key architectural decisions. Read more about the difference between open and closed reporting environments here:
A closed reporting environment does not provide flexibility in reporting, all data to be reported is prescribed by the collector, and the report layout is standardised. In such cases, a taxonomy author may want to consider providing a rendering format using XBRL reporting templates (table linkbase). If the data collector decides to collect data as an xBRL-CSV report, the taxonomy author may consider defining JSON metadata for specifying aspect values for facts. Read more about XBRL formats here:
In the case of an open reporting environment, data reported varies according to the entity’s specific situation, and the layout of the report may differ as well. In such cases, taxonomy modelling may require considering allowing for entity-specific disclosures, such as including common practice elements. Read more about taxonomy modelling here:
In an open reporting environment, the data collector must also decide whether preparers can extend the taxonomy to tag entity-specific disclosures. If the consumer of the reports is only intending to perform automated analysis on data tagged against the base taxonomy, then it may be sufficient for any entity-specific disclosures to be left untagged, and available only in human-readable form.
Inline XBRL is the preferred data format for an open reporting environment and can reduce the need for extensions in some cases. For a more detailed discussion of taxonomy extensions, see here:
A taxonomy author should consider to what extent existing taxonomies can be reused. More detailed guidance on the considerations for taxonomy reuse can be found here here:
The taxonomy team should define the validation rules required to ensure the data quality of collected reports. Validation rules can include business rules backed by requirements from the underlying business domain and technical requirements of the filing platform. The taxonomy team should consider mechanisms to build validation rules in the taxonomy and plan for incorporating rules that may not be possible in the taxonomy. The following guidance can help in this area:
- Implementing business rules details
- How to specify mandatory facts for an XBRL report
- How to prepare and publish filing rules
- Checklist for XBRL report filing rules
- Checklist for taxonomy extension filing rules
The team should decide on the taxonomy testing strategy, using real-world reports and engaging selected filers and data users early in the taxonomy testing process.
3.4 Technical Requirements & development
Deciding on the taxonomy architecture is a key step in taxonomy building. The following aspects of taxonomy architecture need consideration:
- Modularisation taxonomy to cater to current needs and scalability of the taxonomy. These would include the logical and physical structure of the taxonomy. For example, taxonomy modules can be based on industry or underlying reporting requirements.
- Versioning strategy to be adopted, read more about taxonomy versioning here:
- Label style guide to be adopted. Read more about labelling taxonomy components here:
The effort-intensive part of the taxonomy development is data modelling for each disclosure or reporting requirement. The taxonomy and domain experts need to work together to arrive at data modelling best suited for the purpose. The expected use of data greatly drives modelling choices. Read more on guidance on a few specific modelling topics:
- How to model information relating to multiple entities
- How to define a list of allowed values
- How to identify dimensionally invalid data points in a taxonomy
- Dimensions Technical FAQ
- How to add structured data to taxonomy components using property references
The data model needs to be translated into required taxonomy components and interrelationships. Tools help create technical taxonomy files from the data model. The taxonomy team will be required to choose taxonomy creation tools.
The taxonomy development involves incorporating validation rules as XBRL Formula Rules and, where required, creating XBRL reporting templates and metadata definitions for xBRL-CSV reporting. Read more here:
Technical testing, business content and taxonomy validation testing are critical processes in taxonomy development. XBRL reports created with real-world data would ensure that the taxonomy meets reporting requirements. Read more here:
3.5 Lifecycle management
The taxonomy needs to be published for stakeholder consumption. Consider how stakeholder will be notified. Read guidance on taxonomy publication here:
The taxonomy should be accompanied by supporting documents such as an architecture guide, sample reports, and a preparer guide. Read more about it here:
The taxonomy should be made available for public consultation before being used for data collection. This is to gather feedback from wider stakeholders and catch issues early, if any.
It is essential to note that the taxonomy will need some management after it has been placed in service; it may have some updates, bug fixes and new versions. A taxonomy governance team must be defined, which may be the same as in the first section. Read more about taxonomy maintenance here:
- 'Planning taxonomy releases’ section of How to manage taxonomy versioning
- How to communicate the changes between taxonomy versions
This document was produced by the Best Practices Board.
Published on 2023-12-06.
