ESMA ESEF

esmalogo
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:

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 published materials will 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 by June 16, 2017.

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 planned to be based on the FULL IFRS Taxonomy (i.e., not SME nor the Managements Commentary). It shall follow the IFRS Taxonomy architecture and naming convention apart from the few exemptions listed below. It also obeys the assumptions regarding the role of various IFRS 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).

ESMA domain (http://www.esma.europa.eu) is planned to be applied to folder path, namespaces and the XBRL extended link roles.

The full IFRS Taxonomy consists of a large number of files named according to a specified nomenclature. The ESEF taxonomy is planned to be simplified from this perspective without impact on the actual content, which remains structured by standards and by statements/notes according to the original IFRS taxonomy.

The following list includes the ESEF taxonomy files along with their purpose and content:

  • esef_cor.xsd:
    • Imports IFRS core schema containing FULL IFRS Taxonomy concepts declaration:
    • Defines ESEF extension concepts (e.g., guidance elements, …):
    • Refers to IFRS and ESEF taxonomy standard and documentation labels
  • esef_all.xsd
    • Defines roles to be applied on extended links in ESEF taxonomy linkbases;
    • Refers to ESEF taxonomy linkbases (presentation, calculation, definition, …);
  • esef_pre.xml, esef_cal.xml, esef_def.xml
    • Contains relationships – counterparts of the IFRS linkbases with application of guidance concepts and any other ESMA extension concepts;
    • The definition linkbase may declare hypercubes (used to resemble “tabular” structures in the taxonomy) as open to identify the possible application (as a reference only) of dimensions not mentioned explicitly in a particular section; some hypercubes may remain closed (for certain line items) to identify the desire not to have them extended (i.e., line items shall be tagged using the dimensions prescribed in the taxonomy); tagging rules may further constrain the set of dimensions to be applied in case of open hypercubes or based on the hints provided by the guidance concepts (e.g., only to those envisaged by the IFRS taxonomy as for “general application”);
  • esef_lab.xml, esef_gen.xml
    • Contain labels (in English) of ESEF taxonomy concepts, role types, etc.;
    • These files may be split (one pair per language) when translations to other EU languages are available;
  • esef_for.xml
    • Assertions providing additional documentation on relations between taxonomy concepts as per the IFRS Taxonomy formulas.

To summarise 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;
    • To identify concepts of a specific meaning or use, for example placeholders or starting points for definition of extension structures;
    • To inform on or contain the use of dimensions for particular line items;
  • Addition of a section identifying concepts that must be tagged (if present) in a report.

The ESEF taxonomy has two entry points:

  • esef_cor.xsd (providing definitions for all base taxonomy concepts, their labels and references) that 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 production of the ESEF taxonomy shall be automated and require only the relevant business inputs. These include (but are not limited to):

  • Creation of a section listing the concepts identified as those ones that must be tagged if present in a report;
  • Declaration of guidance elements informing, for example, about placeholders for particular components of a filer’s financial statement extension, or the provision of additional hints to the links in the taxonomy structures (in this way making it easier to browse).

An illustrative .pdf output from the draft version of the ESEF taxonomy is available here.

Draft taxonomy files can be accessed here.

Visualisation tools for colleagues in the community studying the ESMA taxonomy:

  • Arelle, open source xbrl platform. Download here.
  • Vendor tool (kindly offered) running on-line 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 [abstract]”: “This item must be used as a starting point for Statement of financial position”,
  • “Profit or loss [abstract]”: “This item must be used as a starting point for Profit or loss statement”,
  • “Statement of comprehensive income [abstract]”: “This item must be used as a starting point for Statement of comprehensive income or combined Profit or loss and Other comprehensive income statement”,
  • “Statement of cash flows [abstract]”: “This item must be used as a starting point for Cash flow statement”,
  • “Statement of changes in equity [abstract]”: “This item must be used as a starting point for Statement of changes in equity”.

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. An example of this mechanism is provided below.

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

It is considered to prohibit modifying labels of base taxonomy items even if they don’t exactly match the actual titles and headers used in the filing. 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 was considered to additionally request a more verbose description (documentation labels) and references (in reference linkbase) for all company specific concepts. The conclusion was that the anchoring mechanisms shall serve a similar purpose, therefore these two artefacts are optional and may be provided by filers on voluntary basis.

It is expected 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:

  1. An extension concept is very close in definition and scope to a concept existing in the base taxonomy, but at the same time is significantly different and therefore in filers’ opinion it requires a new tag instead of reusing an existing one. For example, “Revenue from hosting services, cloud subscription and support” may be considered by a filer to be equivalent to the IFRS Taxonomy concept “Revenue from rendering of internet and data services”; nevertheless, at the same time, it has enough specific flavour in the part related to “support” that it requires an extension concept.
  2. 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.
  3. 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”.
  4. An extension concept is unrelated to any base taxonomy concept. Not only is it a very rare case, but in addition, such concept would not be comparable across entities and therefore would not result to be useful in the analysis. On the other hand, if a filer decides to present and tag something very different, this may constitute a remarkable and important source of information.

Apart from these four 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;
  • Enable the existing standard XBRL syntax (rather than introducing a custom solution) to be supported by regular tools;
  • 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.

Each extension concept must be anchored against the concept in the base taxonomy that is closest in meaning and scope (used in the filing or not). There may be situations where an extension concept is anchored against another extension concept, as there is no other close match in the base taxonomy. In such cases, the entire structure of extension concepts anchored against one another must also be anchored against at least one base taxonomy concept.

The anchoring shall be applied in the definition linkbase of the filer’s extension taxonomy using ‘essence-alias’ or ‘general-special’ relationship types (roles on arcs). The former shall be used to link an extension concept to a very similar (in definition and scope) base taxonomy concept, where the target of the relationship must be the extension concept. The latter 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.

The following is the proposed filing rule on anchoring to be included in the filing manual:

An element defined in the company specific namespace must be directly or indirectly linked with the element or elements defined in the standard (base) taxonomy namespace that is/are closest in meaning and scope  (i.e. through another closest in meaning and scope element or elements defined in the company specific namespace linked with the closest in meaning in scope element or elements defined in the standard taxonomy namespace). In particular:

A. An element defined in the company specific namespace which is very close in meaning and scope to an element defined in the standard taxonomy namespace must be linked with this standard taxonomy element using an arc with “essence-alias” role and appear as a target of the relationship. Moreover, in such case the company specific concept must be assigned a documentation label describing the difference comparing to the standard taxonomy concept or explain the motivation for creation of an extension concepts rather than reusing the base taxonomy tag.

B. An element defined in the company specific namespace whose meaning/scope is narrower to the closest in meaning and scope element defined in the standard taxonomy namespace must be linked with this standard taxonomy element using an arc with “general-special” role and appear as a target of the relationship.

C. An element defined in the company specific namespace whose meaning/scope is wider than the closest in meaning and scope element (or elements) defined in the standard taxonomy namespace must be linked with this (these) standard taxonomy element (elements) using an arc with “general-special” role and appear as a source of the relationship (relationships).

D. An element defined in the company specific namespace (X) may be linked to another element defined in the company specific namespace (Y) if the closest in meaning element defined in the standard taxonomy for the company specific element X is closer in meaning and scope to this other company specific element Y and Y is the closest in meaning and scope to X.

In case D, elements X or Y must be linked against each other as described in points B or C above depending on which is more narrow or wide in meaning and scope. In such chase however this other company specific element Y or any of its predecessors or descendants in the network of “general-special” or “essence-alias” relationships must be linked with an element or elements defined in the standard taxonomy namespace.

This rule is included in the filing rules explained in the next paragraph. A simple example of this mechanism is provided below.

Filing rules

Rules on reporting that guide syntax and semantics of filers extension taxonomies as well as the tagging requirements are planned to be defined in a form of the ESMA ESEF Filing Manual.

A preliminary draft set of rules was identified based on the Global Filing Manual and other international practices. Rules were tentatively classified with regard to their applicability to the ESEF project. This classification as well as the wording of the rules will be further refined to better reflect the ESEF reporting scenario and requirements.

Example

The above assumptions regarding filers’ extension and tagging rules were explained in this document based on a simple example.

Get to top