This document is a public draft. Readers are invited to submit comments to the Entity Specific Disclosure Task Force.
Guidance provided in this note is based on the Entity Specific Disclosure Task Force (ESD-TF) interpretation of the rules as published by ESMA and the European Commission (see Appendix C) and is not intended to act as a complete or authoritative statement of those rules.
- 1 Target Audience
- 2 Introduction and scope
- 3 What is anchoring?
- 4 When to anchor
- 5 Anchoring examples
- 6 Practical application of the guidance
- A Guidance for software developers
- B Decision tree
- C ESEF rules and guidance
- D Further Reading
1 Target Audience
This guidance is primarily aimed at preparers of Inline XBRL (iXBRL) reports complying with the requirements set out in the European Securities and Markets Authority’s (ESMA) European Single Electronic Format (ESEF) regulation, who seek to better understand when and how to anchor entity-specific concepts to ESEF taxonomy concepts. It may also be of use to software developers who aim to support preparers with ESEF-enabled tools.
2 Introduction and scope
The ESEF rules include the requirement to submit a preparer-specific extension of the base taxonomy as a result of the flexibility of IFRS financial statements compared to other regulatory reporting. The use of extension taxonomies by XBRL preparers allows them to achieve the XBRL coverage of the entity-specific disclosures that the IFRS Standards require to be disclosed. This in turn helps the consumers of the XBRL submissions by providing them with more data than they would otherwise get if the preparer was constrained to only tagging against a fixed taxonomy.
However, extensions can present a challenge for consumers as these extensions are not always easy to understand. In response to this, XBRL International's Entity-Specific Disclosure Task Force (ESD-TF) published guidance in November 2017 to help define the relationships between extended concepts created by preparers, and the base taxonomy concepts using the mechanism of "anchoring". ESMA is the first regulator to require the use of anchoring and has provided guidance to make it relevant for the ESEF rules.
This guidance provides further support to preparers on how and when to anchor in accordance with ESMA’s ESEF requirements This guidance does not cover when it is appropriate to create an extension or the associated process.
3 What is anchoring?
ESEF preparers are required to create extension concepts to represent line items in their financial statements, where is it not possible to use concepts from the ESEF base taxonomy.
Anchoring, as required by ESEF, links an extension concept created by the preparer, to an appropriate concept in the ESEF taxonomy which is either wider or narrower in accounting meaning or scope. Analysts, regulators and other users can use this information to better interpret and compare financial information collected through the use of extensions.
Anchoring will be recorded within the so-called "definition linkbase" of the preparer’s extension taxonomy (ESEF Reporting Manual, Guidance 3.3.2). The definition linkbase defines a number of relationships between the different elements in the taxonomy (e.g. the relationships defining dimensional structure).
Whilst preparers are expected to have a basic understanding of what linkbases are and understand that they are key components of the package that gets submitted to their regulator (Reporting manual, Guidance 3.4), they are not expected to know how to build them, as software should help in creating them.
4 When to anchor
ESMA’s Regulatory Technical Standards (RTS) require anchoring for preparer extension taxonomy concepts marking up the IFRS consolidated financial statements: statement of financial position, statement of profit or loss and other comprehensive income, statement of changes in equity and statement of cash flows (RTS, Annex IV, paragraph 9).
At the first stage of implementation of ESEF (applicable for annual periods from 20201), filers will only be required to represent the primary financial statements mentioned above. In the second stage (from 2022), the requirement will be extended to the representation of notes to the financial statements, but only in the form of block or text concepts. There is currently no anchoring guidance for extensions outside the primary financial statements or anchoring extension dimension members. The Task Force hopes to provide an update on this in the future.
Furthermore, the rules clearly state that no anchoring is required for an extension taxonomy concept that corresponds to “a subtotal of other disclosures in the same statement” (RTS, Annex IV, paragraph 10).
5 Anchoring examples
The guidance in the RTS and in the ESEF Reporting manual describe two types of relationships:
5.1 Anchoring to the ESEF taxonomy concept having the closest wider accounting meaning and/or scope
Extension taxonomy concepts must be anchored to the ESEF taxonomy concept having the closest wider accounting meaning and/or scope (ESEF Reporting Manual, Guidance 1.4.1). Wider in accounting meaning and/or scope will be an ESEF taxonomy concept with a related meaning which fully encompasses the meaning of the extension concept.
Example 1: One-to-one anchoring
For example, consider the scenario where the following line items are included in the Statement of Financial Position:
- Flight equipment (excluding aircraft)
- Other property, plant and equipment
The ESEF taxonomy has a concept for general "Other property, plant and equipment" described in the documentation as "The amount of property, plant and equipment that the entity does not separately disclose in the same statement or note."
The ESEF Taxonomy however does not have a concept for "Flight equipment". The closest wider ESEF taxonomy concept for "Flight equipment" is "Property, plant and equipment" since the even wider element "Non-current asset" encompasses a much wider number of concepts compared to "Property Plant and Equipment" , whilst the documentation for "Other property, plant and equipment" explicitly excludes "separately disclosed items" from this element.
Example 2: Disaggregations
Extension concepts created by the preparer for disclosures in the Statement of Financial Position:
- IT equipment
- Network and communication equipment
Both concepts must be anchored to "Property, plant and equipment".
Example 3: Disaggregation with subtotal
Line items in the Statements of Comprehensive Income
|Cloud Subscription and support||3,423|
|Software licences and support||16,424|
In this example the preparer needs to create extension concepts for all disclosures in this table except "Total Revenue" However not all extension taxonomy concepts require anchoring. The "Software licences and support" line item is a subtotal of other disclosures in the same statement and therefore the extension taxonomy concept created for this should not be anchored to an ESEF taxonomy concept.
5.2 Anchoring to the ESEF taxonomy concept (or concepts) having the narrower accounting meaning and/or scope
Extension taxonomy concepts may also be anchored to the ESEF taxonomy concepts having the closest narrower accounting meaning and/or scope. This will be mandatory only where the financial statements line item combines two (or more) concepts of the core [ESEF] taxonomy (RTS, Annex IV, paragraph 9b). Narrower in accounting meaning and/or scope will be an ESEF taxonomy concept with a related meaning which is limited in extent or scope in comparison with the meaning of the extension concept (i.e. the extension concept is wider in meaning and/or scope when compared to the ESEF taxonomy concept as per the definition of wider in section above).
Example 4: Combinations
For example, the line item "Share capital and share premium" does not have a corresponding ESEF taxonomy concept, these concepts are represented by two different concepts: "Issued capital" and "Share premium". The extension concept created would be anchored to "Equity" as the closest wider in accounting meaning ESEF taxonomy concept as per the guidance above. Since it is a combination of two existing concepts, in the ESEF taxonomy, it needs to be also anchored to each of the component narrower core taxonomy concepts indicating that it is wider than them. The extension concept will appear as the 'source' of the narrower ESEF taxonomy concepts. The narrower concepts are shown as further indented in the Figure 4 below.
Note that some software solutions may choose not to indicate the direction of the anchoring relationship using the words 'target' or 'source' and may instead refer to a wider or narrower relationship.
6 Practical application of the guidance
A decision tree has been included as Appendix B of this document to assist in the process of determining where to apply ESEF anchors.
In applying the decision tree, where a preparer is identifying potential concepts with wider or narrower accounting meaning, the following factors may be taken into account (in no particular order):
The context of the financial disclosure for which the extension concept has been created since it might be also reflected in the presentation of the ESEF Taxonomy.
- For example, it may be relevant to look at the format of the primary statement that is used in the financial statements (e.g. classified vs unclassified Statement of Financial Position, Income Statement classified ‘by nature of expenses’ vs ‘by function of expenses’).
Any guidance provided in the relevant IFRS standard as per the reference included in the taxonomy for this concept.
The ESEF taxonomy concepts standard labels.
The ESEF taxonomy concepts documentation labels.
The 'Period type' ('duration' vs 'instant') and 'data type' of the concept (the extension concept 'period type' and 'data type' should match the target/source ESEF taxonomy concept used in anchoring)
- For example, anchoring an extension concept with a monetary type to an ESEF taxonomy concept with a monetary type would be correct but anchoring a monetary extension concept to an ESEF taxonomy abstract member would not be appropriate.
The location of the concept in the presentation tree of the ESEF taxonomy.
Note that the definition of the ESEF taxonomy concept in the relevant IFRS standard is the most reliable source of information when making a judgement for an appropriate anchoring target/source.
Appendix A Guidance for software developers
At a technical level, the anchoring relationship is defined in the definition linkbase and must be defined in a dedicated extended link role (e.g. [Entity specific URL]/role/Anchoring) (Reporting manual, Guidance 3.3.2).
Preparation software is expected to build the linkbase in the background, only presenting the preparer with the choice of which wider and narrower core taxonomy concepts to anchor to.
This is an example of the syntax in the definition linkbase for anchoring explained in Example 2. The syntax follows the XBRL Specification 2.1 guidance2 on the use of the definitionArc element1. For each additional anchoring relationship this is repeated.
For more information on the anchoring arcole please see the Link Role Registry.
Extract 1 – References for role and arcrole
<link:roleRef roleURI="[Entity specific URL]/role/Anchoring" xlink:type="simple" xlink:href="[Entity specific schema].xsd#Anchoring"/> <link:arcroleRef xlink:type="simple" arcroleURI="http://www.esma.europa.eu/xbrl/esef/arcrole/wider-narrower" xlink:href="http://www.xbrl.org/lrr/arcrole/esma-arcrole-2018-11-21.xsd#wider-narrower"/>
Extract 2 - Anchoring
<link:definitionLink xlink:type="extended" xlink:role="[entity specific URL]/role/Anchoring"> <link:loc xlink:type="locator" xlink:href="http://xbrl.ifrs.org/taxonomy/2017-03-09/full_ifrs/full_ifrs-cor_2017-03-09.xsd#ifrs-full_PropertyPlantAndEquipment" xlink:label="PropertyplantAndEquipment" /> <link:loc xlink:type="locator" xlink:href="[entity specific schema].xsd#prefix_ITEquipment" xlink:label="ITEquipment"/> <definitionArc xlink:type="arc" xlink:arcrole="http://www.esma.europa.eu/xbrl/esef/arcrole/wider-narrower" xlink:from="PropertyPlantAndEquipment" xlink:to="ITEquipment" xlink:title="definition: ITEquipment to PropertyPlantAndEquipment" order="1.0" /> <link:loc xlink:type="locator" xlink:href="[entity specific schema].xsd#prefix_NetworkAndCommunicationsEquipment" xlink:label="NetworkAndCommunicationsEquipment" /> <definitionArc xlink:type="arc" xlink:arcrole="http://www.esma.europa.eu/xbrl/esef/arcrole/wider-narrower" xlink:from="PropertyPlantAndEquipment" xlink:to="NetworkAndCommunicationsEquipment" xlink:title="definition: NetworkAndComminicationsEquipment to PropertyPlantAndEquipment" order="2.0" /> </link:definitionLink>
The xlink:from and xlink:to attributes on an Arc MUST be equal to the value of an xlink:label attribute of at least one Locator or resource in the same Extended Link element as the arc element itself. The xlink:title attribute is optional and may be used to convey information about the relationship between the elements for software which is enabled to read it.
Appendix B Decision tree
Decision tree to assist in the process of determining where to apply ESEF anchors.
Appendix C ESEF rules and guidance
This guidance note is based on the following documents:
- The Final RTS on the European Single Electronic Format, Annex II
- Annex IV (Note: this is an Annex nested within Annex II), Points 9 & 10
- The ESEF Reporting Manual
- Guidance 1.4. Anchoring
- Guidance 3.3. Extension taxonomy anchoring
Appendix D Further Reading
In addition to the ESEF rules and guidance listed in Appendix C, the following documents may be of interest to readers:
- How to address Entity Specific Disclosures in XBRL reports – Published by the XII Entity Specific Disclosures Task Force (ESDTF)
- Final Report on the RTS on the European Single Electronic Format – Published by ESMA
- RTS Annex as published by the European Commission
- XBRL Specification 2.1 – The 'definitionArc' element