Table of Contents

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 elements to ESEF taxonomy elements. It may also be of use to software developers who aim to support preparers with ESEF-enabled tools. Please see Appendix D for additional technical guidance.

2 Introduction and scope

The ESEF rules include the requirement to submit an entity-specific extension taxonomy 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 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 tagging was constrained to only using 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 elements created by preparers, and the base taxonomy elements 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 elements to represent disclosures in their financial statements, where it is not appropriate to use elements from the base taxonomy.

Anchoring, as required by ESEF, links an extension element created by the preparer, to an appropriate element in the ESEF taxonomy that 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 is defined in ESMA’s Regulatory Technical Standards (RTS) and in particular Annex IV, paragraph 9. The RTS is a legislative document and takes precedence over any additional guidance. ESMA has also published an ESEF Reporting Manual, which is not a legally binding document but includes helpful guidance on anchoring in Guidance 1.4 and 3.3 - 3.4. Note that while the RTS and Guidance 1.4 have remained unchanged with respect to anchoring since their initial publication, Guidance 3.3-3.4 was updated in July 2020 to provide further information (primarily to software developers) about how to apply the RTS requirements to structural element entity-specific elements.

Anchoring will be recorded within the "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).

Although 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. As a result of the updates to guidance points 3.3 and 3.4 additional guidance has been provided on the way that anchoring is represented in the definition linkbase for certain types of extensions related to structural elements. These changes are discussed in more detail in Section 5.3, Section 5.4 and should primarily be managed by software.

4 When to anchor

ESMA’s RTS requires preparers to anchor extension elements 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 as specified in Article 4 of the amended Transparency Directive1), filers will only be required to represent the primary financial statements mentioned above. In the second stage (from 2022), the requirement will also encompass the notes to the financial statements, but only in the form of block tag or text elements. For anchoring from 2022 the reporting manual clarifies that “if issuers decide on a voluntary basis to create detailed tag extension elements to mark-up their Notes, there is no obligation to anchor such extension elements.”. (Guidance 1.4.1).

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 describes multiple types of anchoring relationships illustrated in the following examples:

5.1 Anchoring to the ESEF taxonomy concept having the closest wider accounting meaning and/or scope

Extension 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 element with a related meaning which fully encompasses the meaning of the extension element. In the example below we see how this applies to concepts. It is relevant to note that in case of extension concepts it is not expected that the anchor would be to another extension concept. The use of the wider-narrow relationship is explicitly defined as between an extension concept and a base taxonomy concept ².

Example 1: One-to-one anchoring of concepts

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" has a much wider accounting meaning than "Property Plant and Equipment", and the documentation for "Other property, plant and equipment" explicitly excludes "separately disclosed items" from this element.

Figure 1: PPE and Flight Equipment

Therefore, the extension concept for "Flight equipment" 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 above by the indented item.

Example 2: Disaggregations

Line items included for disclosures in the Statement of Financial Position:

• IT equipment
• Network and communication equipment

Both extension concepts must be anchored to "Property, plant and equipment".

Figure 2: PPE, IT equipment & Network and communication equipment

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 extension concepts are created for all disclosures in this table except "Total Revenue" However not all extension taxonomy concepts require anchoring. The "Software licences and support" extension concept is a subtotal of other disclosures in the same statement and therefore the extension concept created for this should not be anchored to an ESEF taxonomy concept.

Figure 3: Revenue from rendering of information technology services

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 closest narrower accounting meaning and/or scope

Extension concepts may also be anchored to the ESEF taxonomy concepts having the closest narrower accounting meaning and/or scope. This will be mandatory where the financial statements line item combines two (or more) concepts of the core ESEF taxonomy (RTS, Annex IV, paragraph 9b). Note that the RTS does not require this combination to comprise exclusively components that are represented by concepts in the core taxonomy. 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 5.1). In the example below we see how this applies to concepts.

Example 4: Combinations of concepts

For example 4, the line item "Share capital and share premium" does not have a corresponding ESEF taxonomy concept. Instead, its meaning combines components that are represented by two different concepts: "Issued capital" and "Share premium" in the ESEF taxonomy. In this case, the anchor with the closest wider accounting meaning for the entity-specific disclosure is "Equity attributable to owners of parent", as per the guidance above. Additionally, since the extension concept is a combination of two existing concepts in the ESEF taxonomy, the two narrower concepts also need to be used as anchors to show that the entity-specific disclosure has a wider meaning than either of 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.

Figure 4: Share capital and share premium in the Statement of Financial Position

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

Note that terms other than 'target' and 'source' may be used in practice to indicate the direction of the anchoring relationship, for example, ‘wider’ and ‘narrower’.

For completeness, if an extension taxonomy concept comprises two or more components of which only one has a corresponding concept in the core taxonomy, this does not combine ‘a number of core taxonomy elements’ and therefore the application of an anchor to the narrower ESEF taxonomy element is not mandatory.

5.3 Anchoring entity-specific domain-members

When reporting entity-specific disclosures that require dimensional qualification, it is possible to create entity specific domain members as well as concepts. The base taxonomy, e.g., for the ‘Statement of changes in equity’ table, is modelled using taxonomy-defined dimensions. Domain members must be anchored to either another domain member in the base taxonomy or, if forming the top level of a set of members, to an appropriate taxonomy defined dimension.

The same RTS rules about closest wider or narrower in accounting meaning and/or scope apply for members too, despite the differences in XBRL syntax used. The accounting meaning in a table is conveyed by the combination of the concept, dimension, and member used – all contribute. Note the different approach between anchoring entity specific concepts and entity specific domain members (and/or other structural elements). An entity specific concept can only be anchored directly to a concept element in the base taxonomy. Entity specific domain members may also be anchored directly to a base taxonomy domain member or a taxonomy-defined dimensions(axis). However, they can also be anchored indirectly through another entity specific domain member, an entity specific dimension, and possibly an entity specific cube(table) linked to base taxonomy concepts.

Example 5: Combinations of domain members

For example 5, if an entity is reporting ‘Share capital and share premium’ as an aggregation in a single column in the ‘Statement of changes in equity’ it would not have a corresponding ESEF taxonomy domain member. The two components of this table column are represented by two different members: ‘Issued capital [member]’ and ‘Share premium [member]’ in the ‘Components of equity [axis]’. The extension member created, ‘Share capital and share premium [member]’, would be anchored to ‘Equity attributable to owners of parent [member]’ as the closest wider ESEF taxonomy member in accounting meaning (as per the guidance above). Since this is a combination of two ESEF taxonomy members, two narrower anchors are also required. The extension member will appear as the ‘target’ of the wider ESEF taxonomy member and as the ‘source’ of the narrower ones. This is illustrated in the Figure 5 below.

Figure 5: Share capital and share premium in the Statement of Changes in Equity

Note that as members are abstract taxonomy elements, they are anchored to other ‘abstract’ elements in the taxonomy, unlike concepts.

The preparation software used should enable the user to make choices as to the anchoring of members and where those are done automatically, should permit the user to review and amend if necessary.

Additionally, the ESEF Reporting Manual contains other recommendations related to the use of XBRL tables that should be considered when anchoring entity-specific domain-members. Of particular note are:

• Guidance 1.5 which describes when to consider using taxonomy-defined dimensions (axis) and domain members in tagging
• Guidance 3.4 (second half) which describes the use of relationships between domain members to indicate any calculation roll-up that might be present.
• Guidance 3.4.3 discussing the use of default members, in particular that the defaults defined in the ESEF Taxonomy should not be overridden.

5.4 Anchoring entity-specific domain-members and entity-specific dimensions

It is possible that an extension element may need to be modelled as a top level domain member where there is no appropriate dimension to anchor to in the ESEF taxonomy (or even an appropriate table). It is therefore possible to create entity-specific dimensions and tables and the ESEF Reporting Manual, Guidance 3.3 explains the technical basis on which this is done.

Example 6: Entity-specific domain-members and dimensions

For example 6, if ‘Earnings per preference share’ is disclosed at the bottom of the Income statement and is using the ‘Basic earnings (loss) per share’ concept to represent the disclosure, there is no appropriate “preference shares” member to use in the ‘Earnings per share [table]’. Furthermore, the IFRS accounting meaning of ‘Classes of ordinary shares [axis]’ in this table is not the same as “preference shares”. Therefore, in this case a ‘Preference shares [member]’ should be created as well as a ‘Classes of non-ordinary shares [axis]’. The RTS requires both entity-specific elements to be anchored. The ‘Classes of non-ordinary shares [axis]’ anchors to the ‘Earnings per share [table]’ and the ‘Preference shares [member] anchors to the entity-specific dimension ‘Classes of non-ordinary shares [axis]’. This is illustrated in the Figure 6 below.

Figure 6: Earnings per preference share

The above fulfils the requirements of the RTS as through these relationships the entity-specific member is ultimately anchored to the base taxonomy in a meaningful manner.

5.5 Anchoring an entity-specific table

It is also possible for an anchor to be a concept that is a line item in an entity-specific table as illustrated in example 7.

Example 7: Entity-specific table

Extract from Consolidated Income Statement

	Before Fair Value adjustments	Fair Value Adjustments	Total
Operating profit/(loss)	365	37	401
Net financial income/(expense) from financing	-264	0	-264
Profit/(loss) on derivatives and other financial results	2	-1	1
Net financial income/(expense)	-262	-1	-263

In the rows highlighted in the table above, we see that two extension concepts were created: “Profit/(loss) on derivatives and other financial results” and “Net financial income/(expense) from financing”. These extension concepts should be anchored to a wider base taxonomy concept such as “Finance income (cost)” as shown in the Figure 7 below..

Figure 7: Finance Cost Anchoring

The following was created to complete the modeling in the extension taxonomy. As so much of the table is made up of entity-specific elements³, the greyed concepts in the table are the anchors for this example.

Figure 8: Before and after fair value adjustments

6 Practical application of the guidance

Considerations:

The RTS and therefore the accounting meaning and scope are the primary considerations. Accounting meaning encompasses a number of things and referring to the relevant accounting standard helps to identify these. For example, the accounting meaning could be determined by whether the disclosure is an asset, a liability, a component of equity, income or expense, cash inflow or cash outflow. It could also relate to whether the disclosed value represents a period of time or an instant in time. These accounting concepts may be further defined in accounting standards with specific recognition criteria or measurement definitions. All of these should be taken into consideration when making anchoring decisions.

Determining the accounting meaning of an extension may require knowledge of the intention behind the disclosure. It is necessary to examine related notes to the financial statements and policies to have a clear idea of the requirements and of the wider accounting meaning.

For some anchoring decisions it may be helpful to consider the different factors contributing to the accounting meaning of an extension and identify a ‘primary’ accounting meaning.

For example, an issuer may need to disclose adjustments for specific types of expenditures as an adjustment to profit/loss in the statement of cashflow. In a cash flow statement with an extension created for the line item “Decommissioning of equipment related to oil exploration”, the extension concept label is “Adjustments for decommissioning expenditures”. The extension concept label reflects that this line item represents cash flow adjustments to expenditure but also refers to decommissioning. Looking at the ESEF taxonomy we can find elements making reference to both of these accounting concepts.

If we look at the location of the extension in the cash flow statement, however, we can see that the adjustment is provided as one of a number of provisions made and that the reference to decommissioning is a specialisation of the wider accounting meaning. As such, the appropriate anchor is “Adjustments to reconcile profit (loss) other than changes in working capital”.

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 potential concepts with wider or narrower accounting meaning are identified, the following factors may be considered (in no particular order):

• The context of the financial disclosure for which the extension element has been created, which might also be 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’). In Figure 9, the extension concept, “External purchases,” could be appropriately anchored to “Expense by Nature” as the closest wider concept. External purchases could be part of “Cost of Sales” but it would not be an appropriate anchor because it has no accounting meaning in an income statement with expenses classified by nature. In this case “External purchases” is understood to include more than cost of goods sold, such as external services and transportation costs.

Figure 9: Income Statement classified ‘by nature of expenses’

• Any guidance provided in the relevant IFRS standard as per the reference included in the taxonomy for this concept.
• The ESEF taxonomy elements standard labels.
• The ESEF taxonomy elements documentation labels.
• Data type will generally be the same between extension elements and an ESEF taxonomy anchoring concept but it is not a requirement and there are times when an ESEF taxonomy element with a different data type may make for a better fit.

Example 8: Anchoring concepts with different data types

In the example 8, an extension concept was created for the voluntary marking up of “Cancelation of Treasury Shares, Shares” with a data type of sharesItemType. The best wider anchor in this case may be “CancellationOfTreasuryShares”, which is a monetaryItemType.

Extract from Consolidated Statements of Changes in Equity

Line Item	Data Type	Amount
		Shares	Share capital [member]
Cancellation of treasury shares	monetaryItemType		($1,325,456)
Cancellation of treasury shares, shares	sharesItemType	(125,435,000)

Figure 10: Cancellation of treasury shares

• Period type (instant or duration) can contribute to the accounting meaning of an element therefore anchoring across different period types may diminish the extent to which the accounting meaning matches. Nonetheless, matching period type is not a requirement and there may be scenarios where an ESEF Taxonomy element with a different period type is a better fit but that would be exceedingly rare in the primary financial statements.
• Anchoring a monetary extension concept to an ESEF taxonomy abstract concept would not be appropriate as abstracts concepts have no accounting meaning.
• The location of the concept in the presentation tree of the ESEF taxonomy does not fully describe the accounting meaning.

Note that the reference from the ESEF taxonomy concept to the relevant IFRS standard is the most reliable source of information when making a judgement for an appropriate anchoring target/source.

7 Additional Examples

Additional examples of appropriate and inappropriate anchoring and considerations are discussed in a separate document here.

Appendix A Guidance for software developers

The anchoring relationships shall be constructed as described in ESEF Reporting Manual 3.3.1.

Appendix B Decision tree

Decision tree to assist in the process of determining where to apply ESEF anchors.

Figure 11: Decision tree

Appendix C ESEF rules and guidance

This guidance note is based on the following documents:

• Commission Delegated Regulation (EU) 2018/815 of 17 December 2018 supplementing Directive 2004/109/EC of the European Parliament and of the Council with regard to regulatory technical standards on the specification of a single electronic reporting format
  • Annex IV (Note: this is an Annex nested within Annex II), Points 9 & 10
• The ESEF Reporting Manual (09 July 2020 | ESMA32-60-254rev)
  • Guidance 1.4. Anchoring
  • Guidance 3.3. Extension taxonomy anchoring
• 2020 ESEF Conformance Suite

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)
• XBRL Specification 2.1 – The 'definitionArc' element