Table of Contents

1 Introduction

This guidance explains how reusing an existing taxonomy can be beneficial to taxonomy authors and users. It explains what is meant by reuse and covers business and technical considerations that can be considered best practice. The guidance is primarily provided for taxonomy architects incorporating pre-existing taxonomy(s) in a new, distinct taxonomy.

2 What is reuse?

Reuse means importing components from an existing taxonomy into your own. Reuse may cover any part of a taxonomy, including taxonomy elements, labels, references, formula functions, data types or a presentation tree. It is an alternative to replicating or redoing modelling when an acceptable solution has already been developed.

In this document, we consider the case where the new taxonomy includes additional content as well as other taxonomies. We also assume the normal case where any taxonomies being reused are published separately and by a different owner.

Other methods of reuse, such as those below, are not considered within this document:

• Only adding new labels (e.g. in another language).
• Other repackaging of a taxonomy with no additional elements.

3 When should you reuse?

Usually, the decision to reuse is made by taxonomy architects and authors during the initial stages of taxonomy development. If they can identify an existing, publicly available taxonomy that contains components that meet their requirements, then it is recommended that they make use of these pre-existing components in preference to writing their own.

Reuse is recommended when it is beneficial to guarantee consistency with a pre-existing taxonomy. The alternative is to redefine similar items, which requires the taxonomy users to determine if the concepts are exactly the same.

Good examples of reuse are given below:

• The European Securities and Markets Authority (ESMA) requires public listed companies to provide IFRS financial statements in iXBRL under the European Single Electronic Filing (ESEF) system. The ESEF taxonomy imports the IFRS taxonomy published by the IFRS Foundation to reuse their concepts, thus guaranteeing to users that these concepts are the same.

• The European Insurance and Pensions Authority’s (EIOPA) Solvency II reporting requirement, and the European Banking Authority’s (EBA) CRD IV reporting requirement are built on a common technical framework. Taxonomies for both of these import the EuroFiling taxonomy in order to reuse the interval arithmetic calculation logic and data point modelling concepts. This saves time and effort and ensures calculation consistency amongst all taxonomies that use this logic.

A good example of a taxonomy specifically designed for reuse is the LEI taxonomy published by XBRL International, which provides a standard method for incorporating Legal Entity Identifiers (LEIs) and related functions into XBRL reports.

4 Why is reuse beneficial?

In general, reuse saves time and effort for all stakeholders. Reuse leads to consistent and more standardised report definitions. The way in which this is achieved for different groups is described below.

• For taxonomy authors, reuse means that they can benefit from the efforts of other taxonomy authors for both development and maintenance of the copied elements. Reuse reduces technical risk and software costs because the taxonomy being reused has been tested, usually in live reporting environments. Also, when reusing a taxonomy provided by a standard setter, there is additional assurance that you are following the appropriate standards.

• For data collectors, reuse means that the data becomes more interoperable. This allows to collect data that can be passed through to other parties and potentially to avoid collecting the same data multiple times.

• If preparers see reused definitions, they know that they can apply existing logic to prepare their report.

• For consumers of the data, reuse improves comparability. When facts in two XBRL reports use the exact same reportable concepts then the person using the data can be sure that these facts report the exact same item and are directly comparable.

• For software vendors, reuse lowers the effort required to create software to support the new taxonomy, making it more attractive to support the preparers in that domain. This will, in turn, benefit preparers by having a larger offering of tools and services.

5 Specific considerations

This section covers specific considerations for reusing taxonomies, all of which should be understood and addressed.

5.1 How do you maintain the original meaning of reused components?

In order to get benefits from reuse, it is important that the original definition of any reused component is retained. Strictly speaking, the full meaning of any component is a combination of all relationships within its taxonomy. For example, the position of an element in a calculation tree contributes to its definition and may easily be changed through reuse, losing any intended benefits of defining this relationship. However, in most cases, full benefits can be realised through ensuring that the essence of the element’s definition is retained.

This is usually achieved by importing linked components along with the specific concept to be reused. It is recommended that linked labels and references are imported along with the concept to ensure that the essence of the concept’s definition is maintained across the taxonomies.

5.2 How to import a taxonomy for reuse

Importing refers to the technical mechanism by which taxonomy components are reused. The correct method to reuse all or part of the taxonomy is to use "import" statements to import designated entry points. The import statements must refer to the official location of entry points.¹.

Taxonomies designed for reuse may have specific entry points designated for that purpose. The taxonomy author may provide a list of these with descriptions of what they contain, usually as part of a technical guide or the taxonomy architecture document.

For example, in some taxonomies, the data types are contained in a separate schema to the elements – so if a taxonomy author wanted to just use the data types, they would be able to do this without importing the elements schema.

When working with taxonomies that have not been designed in this manner, you may find that the specific part you want to reuse is not separable from the rest of the taxonomy. This may result in drawing in unnecessary components and unwanted relationships. Unnecessary components can make a taxonomy slower to process in XBRL tools. It is recommended that the implications of importing unwanted relationships be reviewed carefully.

5.3 Legal status

Taxonomies are protected by the same basic rights as any other piece of intellectual property. Before reusing another taxonomy, the legality of the desired usage must be confirmed.

The legal position is usually described alongside the taxonomy which may affirm the copyright and specify restrictions on how it can be used and what must be done if the taxonomy is reused. Instructions, limitations, restrictions and other terms may be summarised in a licence published by the taxonomy owner.

5.4 What documentation is most useful when looking to reuse a taxonomy?

When a taxonomy author is considering another taxonomy for reuse, they should study documentation provided by the author(s) of that taxonomy. This will help the author to understand the structure of the taxonomy and how to best reuse it. Useful documentation may include:

• An extension guide that gives explicit guidance for how the taxonomy is meant to be extended, which may also be relevant to reuse.
• Architecture documents that describe how the data is modelled and that list the entry points that could be used for as starting points for reuse.
• Filing Guidance and Filing Rules that give further understanding on how the taxonomy should be used, which should align with the intended usage of the taxonomy being created.

It is recommended that if these are not found, then the author of the taxonomy under consideration should be contacted for this information.

5.5 How to distribute a taxonomy that reuses other taxonomies

When distributing your taxonomy, special attention must be given to those files that have been imported. The taxonomy package for your taxonomy should not contain files belonging to the taxonomies that are being reused. One reason is that including them might result in conflicts². The second reason is that if files do not belong to the taxonomy author, they are generally not theirs to distribute.

A special case where it may be preferable to redistribute a taxonomy is if a taxonomy package is not available. If this route is acceptable and considered beneficial, it is recommended to provide the reused taxonomies as separate taxonomy packages, rather than combining them into your own taxonomy.

In addition, it is best practice to describe which parts of other taxonomies are reused in the taxonomy’s architecture document.

5.6 How does taxonomy reuse impact maintenance?

It is normal for taxonomies being reused to be updated with new versions and this should be planned for by taxonomy authors. In order to maintain the benefits of reuse, it is recommended to always seek to update reused taxonomies to their latest applicable version³. The update may be vital if the old version is now unsupported or has known errors or material changes to definitions and structure.

Reuse does come with a maintenance cost. The list below gives some practical guidance for how to minimise this cost:

• If changes to the reused taxonomy are known to happen periodically, align your updates to coincide with these.
• There are often early and consultative versions of taxonomies that can be used to check for compatibility issues prior to the full release. The taxonomy owner may be able to act on any feedback you provide to reduce the impact of changes.
• Consider proactively suggesting improvements to any taxonomies you reuse.

When updating reused taxonomies, it is important that all old references are removed. This can be checked by:

• Searching the taxonomy for old namespaces and file names.
• Preventing an XBRL processor from being able to access the old taxonomy, and then validating your taxonomy. This will highlight any remaining references to the old taxonomy.

5.7 Change reports

Most taxonomy owners will release change reports which outline what is different in their new version. These are useful to check for any impact to your taxonomy and could be referred to when creating your own change reports, rather than having to document all changes yourself.

Some areas to be specifically aware of when looking at change reports for reused taxonomies are:

• Changes in concept names, as these will affect XBRL reports.
• Additional or changed label roles, which may or may not be useful to include.
• Deprecations that may not throw technical errors even though the author of the reused taxonomy is saying that these elements should no longer be used.

Some considerations when preparing your change report are:

• The change report should always include a reference to the change reports of taxonomies that are being reused.
• If the scope of reuse is limited, then the relevant parts of the change documentation should be included into your change report.

5.8 Compatibility of architectures

Taxonomy architectures sometimes include specific features, such as custom components, to support their primary purpose and these may be relied on by software that uses the taxonomy. This can act to make taxonomies incompatible for the purposes of reuse. The effect of these incompatibilities may not become apparent until the taxonomy is in use and so software vendors should be engaged as part of deciding whether to reuse.

If you are considering reusing a taxonomy, you should look carefully at the architecture being used. If there are any conventions or specific constructs that carry particular meaning and could impact the meaning of your taxonomy, then this might make it unsuitable for reuse.

For example, one taxonomy may only use abstract items to give a structure to the presentation, whereas another also uses abstract items to provide additional guidance. This difference in architecture would need to be addressed when combining the taxonomies.