Last update: October 24, 2017.

The European Securities and Markets Authority [ESMA] was empowered by Article 4(7) of the Amended Transparency Directive to draft a regulatory technical standard [RTS] specifying a European Single Electronic Format [ESEF] in which annual financial reports have to be prepared. After carrying out a consultation, ESMA published a Feedback Statement setting out the decisions adopted. The latter can be summarised as follows:

• All annual financial reports will have to be prepared in XHTML format;
• Annual financial reports containing IFRS consolidated financial statements will have to be marked-up with XBRL tags according to the IFRS Taxonomy; which shall be embedded using the Inline XBRL technology,
• XBRL tags have to be embedded in the XHTML document according to the Inline XBRL standard.

This website provides draft artefacts of ESEF:

• ESMA regulatory extension to the IFRS Taxonomy,
• Assumption on rules for creation of the entity specific extension and other guidelines on filings.

DISCLAIMER: Please note that the content of this website and any published working drafts are merely based on current staff considerations and are not formally approved by ESMA’s Chairman and/or ESMA’s Board of Supervisors.

The primary goal of sharing these materials is to consult the assumptions with stakeholders, in particular the filers and companies facilitating the preparation of reports, including consultancy companies, software vendors as well as data users such as investors and analysts.

The first version of published materials was also be presented and discussed at the ESMA Meet the Market Workshop on June 6, 2017 in Frankfurt (as part of the Eurofiling XBRL Week). Please see the introductory presentation by ESMA.

Please provide any feedback by e-mail to esef@esma.europa.eu.

ESMA ESEF Draft Taxonomy

Important: Please note that the draft taxonomy was created to reflect the main ideas described above and to provide a sample of the constructs to be applied in the regulatory extension. It shall by no means be deemed to be the final product.

ESMA ESEF taxonomy is based on the IFRS Taxonomy. It follows the IFRS Taxonomy architecture and naming convention and obeys the assumptions regarding the role of various taxonomy components such as the presentation or calculation relationships, guidelines on exploration of the taxonomy content, etc. as described in the IFRS Taxonomy Architecture documentation.

Conceptually and technically, the ESEF taxonomy imports the IFRS Taxonomy elements, references and labels (standard and documentation).

The IFRS Taxonomy relationships are recreated in the ESEF taxonomy rather than directly reused. This is due to legal restrictions, operational reasons (e.g., endorsement or expiry of standards at the European level with different pace then envisaged by the IASB) and business needs to enable the required modifications (e.g. minor rearrangement of taxonomy content and changes in naming or inclusion of guidance and other supportive elements elements).

The main enhancements of the ESEF taxonomy compared to the IFRS Taxonomy are as follows:

• Simplification of the structure by limiting the number of files,
• Inclusion of guidance concepts to help browsing the taxonomy content by providing hints on where similar and more detailing concepts could be found,
• Addition of a section identifying concepts that must be tagged (if present) in a report,
• Declaration of technical constructs and artifacts, for example relationship type to be applied for the anchoring mechanism, etc.

The ESEF taxonomy has two entry points:

• esef_cor.xsd – providing definitions for all base taxonomy concepts; it shall be imported by filers’ extension schema files;
• esef_all.xsd – importing or referring to all ESEF taxonomy files; to be used to view the full content of the taxonomy.

The draft ESEF taxonomy files can be accessed here.

The draft ESEF taxonomy documentation is available here.

Get to top

Filers’ extensions and tagging requirements for ESEF

This sections contains draft requirements related to the rules to be followed by filers when preparing their company specific extensions in order to tag their reports.

Extension taxonomy

In general, the aim of filers’ extensions to the regulatory [base] taxonomy is to better reflect the content and structures of the submitted report. In an extension, a filer defines concepts that represent terms not found in the base taxonomy. Moreover, filers define the relationships using base and extension concepts to document semantics such as grouping of elements belonging to specific sections of disclosed information, or to provide basic arithmetic dependencies.

It is proposed that filers’ extensions relationships would start with one of the dedicated placeholders identified in the ESEF taxonomy using the guidance concepts. There would be at least the following placeholders in the ESEF taxonomy:

• “Statement of financial position placeholder – this item MUST be used as a starting point for the statement of financial position”,
• “Profit or loss placeholder – this item MUST be used as a starting point for the statement of profit or loss if the statement of profit or loss is separately”,
• “Statement of comprehensive income placeholder – this item MUST be used as a starting point for the statement of comprehensive income if it is disclosed separately or when the statement of profit or loss and other comprehensive income statements are combined in a single statement”,
• “Statement of cash flows placeholder – this item MUST be used as a starting point for the statement of cash flows”,
• “Statement of changes in equity placeholder – this item MUST be used as a starting point for the statement of changes in equity”,
• “Notes, accounting policies and mandatory tags – this item MUST be used as a starting point for markups of disclosures in the notes to the financial statements”.

Filers are required to use these provided placeholders as starting points to resemble their specific structures in the presentation linkbase of the extension taxonomy.

Numeric facts shall also be utilized in calculation linkbase relationships where possible and applicable. This relates in particular to arithmetic relationships between line items from the primary financial statements, which must be included in the filer’s extension taxonomy. Unfortunately, the calculation linkbase as defined in the XBRL 2.1 specification has some limitations. For example, it does not allow to resemble arithmetic relations across periods (e.g., beginning balance + changes in period = ending balance) or across domain members (e.g., line item “Goodwill” reported for member “Carrying amount [member]” of “Carrying amount, accumulated depreciation, amortisation and impairment and gross carrying amount [axis]” is a result of subtraction of “Accumulated depreciation, amortisation and impairment [member]” from “Gross carrying amount [member]”). To cater for this limitation, filers are requested to model their presentation linkbase relationships in a specified manner. In particular, filers shall correctly apply period end, period start and total label roles to enable deduction of cross period calculation based on the presentation linkbase content. Moreover, parent-child relationships between members in presentation linkbase shall be defined and treated in a similar manner as calculation linkbase links between line items; i.e., lower level elements contribute to upper level element with weight +1.

Filers shall also include in their extension taxonomies hypercubes linking line items with dimension members to ensure that reported facts are XBRL Dimensions valid.

Filers are also not allowed to modify the base taxonomy concepts documentation labels or references. It is required, however, that each extension concept has a label identifying its meaning and scope, in the corresponding national (and optionally also in English) language. For labels in English filers shall follow the style guide of the IFRS Taxonomy. It is considered to additionally allow a more verbose description (documentation labels) and references (in reference linkbase) for company specific concepts.

It is recommended that extension element names follow the Label CamelCase Concatenation [LC3] convention.

Tagging rules

Primary financial statements [PFSs] (i.e., balance sheet, income statement, cash flows statement and statement of changes in equity) must be completely tagged in detailed (i.e., every single value must be tagged individually).

In case of disclosures each note must be at least blocked tagged in order to identify its presence in the report. Filers may tag information in notes with more details on a voluntary basis. Detailed tagging of notes may be imposed in the future.

A set of concepts contained in the IFRS Taxonomy was identified which has to be tagged mandatorily if the corresponding information is disclosed in the filer’s report. These items are listed in a separate section of the ESEF taxonomy (extended link with role “[000000] Tags that must be applied if corresponding information is present in a report”).

When tagging their financial statements, filers must use the base taxonomy concepts wherever possible. In case there is no concept available to tag a piece of information, a filer defines an extension concept. In order to avoid inconsistent tagging resulting from the possibilities enabled by the modelling of the base taxonomy, extension concepts must be defined as line items (primary items) unless differently envisaged by the base taxonomy; this applies, for example, to classes of equity in case of statement of changes in equity or other classifications applied in notes.

Anchoring

Important note: the proposed below rules and mechanism of anchoring may be subject to change following the finalisationof the XBRL International Entity Specific Disclosure Task Force’s works.

Anchoring extensions means linking an entity specific concept against a concept or a set of concepts available in the base taxonomy. This is done in order to provide more information about the definition of the extension concept and communicate its desired meaning, which is best known by the filer creating the report and extension. Hints on how the extension concept relates from the base taxonomy (or other extension concepts) shall increase data comparability across reports of various filers by providing a common denominator for all extension concepts in the form of their link to the base taxonomy concepts.

In general, the anchoring may be required in the following cases:

• An extension concept is wider in scope than another concept defined in the base taxonomy. For example, a filer wants to present in the profit or loss statement a line item “Other non-operating income (expense)” which almost entirely consists of gains on exchange differences on translation recognised in profit or loss for which  the IFRS concept “Gains (loss) on exchange differences on translation recognized in profit or loss” exists. Nonetheless, also a few other minor miscellaneous sources of income or expense are also included in the other non-operating income  which make the extension element wider in scope than the closest IFRS Taxonomy match.
• An extension element is narrower in scope than a concept defined in the base taxonomy. For example, the IFRS Taxonomy item “Cost of sales” may be build up in large part from an extension concept “Cost of cloud subscription and support”.

Apart from these two simple cases, there may be also various combinations and more complex situations where an extension element represents a subset of a combination of two or more items from the base taxonomy or other extension items. They are being debated by the XBRL International’s [XII] Task Force on Entity Specific Disclosures [ESD TF]. The Task Force has been set up by the XII Best Practices Board in February 2016 in order to improve the way that entity-specific disclosures are described in XBRL and allow the automated processing of these disclosures by computers and ultimately by data users.

While awaiting the outcomes of the ESD TF recommendations, a temporary approach is considered to be introduced which shall be simple in construction and easy to understand by filers and data users. However, it shall achieve the aim of making data easy to compare for analysis, despite the limited coverage of IFRS standards and the particular design aspects of the IFRS taxonomy.

Extension taxonomy concept shall be therefore anchored against the concept in the base taxonomy that is closest in meaning and scope (used in the filing or not) unless it is a subtotal whose relations to base taxonomy concepts are already expressed by means of calculation linkbase relationships.

The anchoring shall be applied in the definition linkbase of the filer’s extension taxonomy using a dedicated ‘wider-narrower’ relationship type (role on arc). It shall be applied to connect an extension concept to a base taxonomy element with wider or narrower definition, where the direction of a relationship goes from the wider to the narrower concept. Anchoring shall be made against a base taxonomy concept with a similar data type, balance attribute, period type, etc., and shall apply as well to domain members. In general, it is not expected that the filer’s extension defines abstract items to represent grouping headers in the linkbases. Nevertheless, should these appear in the extension, their anchoring is not required.

Reporting manual

Detailed rules on reporting that guide syntax and semantics of filers extension taxonomies, explain tagging requirements and describe the anchoring mechanism are planned to be defined in a Regulatory Technical Standard and in a form of the ESMA ESEF Reporting Manual.

The draft ESEF Reporting Manual is available here.

Get to top