This document is a review draft. Readers are invited to submit comments to the Entity Specific Disclosure Task Force.


  • Michalis Georgiou, PwC
  • Jon Rowden, PwC
  • Andromeda Wood, Workiva


  • Pierre Hamon, etXetera
  • Charlotte Hoyland, PwC
  • Louis Matherne, Financial Accounting Standards Board
  • Lou Rohman, Merrill Corporation

Table of Contents

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

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 Unresolved reference 'xg: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 Unresolved reference 'xg: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.

Figure 6: png

The extension concept for "Flight equipment" then should be anchored to the closest wider accounting meaning concept identified above. The extension concept is the 'target' of this relationship as is indicated in the diagram below by the indented item.

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".

Figure 6: png

Example 3: Disaggregation with subtotal

Line items in the Statements of Comprehensive Income

Revenue   £m
Cloud Subscription and support   3,423
             Software licenses 4,101  
             Software support 12,323  
Software licences and support   16,424
Total revenue   19,847

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.

Figure 6: png

Note that although subtotals are not anchored to an ESEF taxonomy concept,the Presentation trees and Calculation trees help identify which part of the financial statements they relate to and document any arithmetic relationships which can be documented.

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 6 below.

Figure 6: png

Note that if one of the narrower concepts is insignificant, it is not necessary to anchor to it according to the rules.

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

  roleURI="[Entity specific URL]/role/Anchoring"  
  xlink:href="[Entity specific schema].xsd#Anchoring"/> 


Extract 2 - Anchoring

  xlink:role="[entity specific URL]/role/Anchoring">

  xlink:label="PropertyplantAndEquipment" />

  xlink:href="[entity specific schema].xsd#prefix_ITEquipment" 

  xlink:title="definition: ITEquipment to PropertyPlantAndEquipment"
  order="1.0" />

  xlink:href="[entity specific schema].xsd#prefix_NetworkAndCommunicationsEquipment" 
  xlink:label="NetworkAndCommunicationsEquipment" />

  xlink:title="definition: NetworkAndComminicationsEquipment to PropertyPlantAndEquipment"
  order="2.0" />


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.

Figure 6: svg

Appendix C ESEF rules and guidance

This guidance note is based on the following documents:

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:

  1. Annual financial reports containing financial statements for financial years beginning on or after 1 January 2020 

  2. XBRL Specification 2.1 

This document was produced by the Entity Specific Disclosure Task Force.

Published on None.

Was this article helpful?

Related Articles


Would you like
to learn more?

Join our Newsletter mailing list to
stay plugged in to the latest
information about XBRL around the world.

By clicking submit you agree to the XBRL International privacy policy which can be found at xbrl.org/privacy