Changes to the ESEF Reporting Manual 2023 and Its Consequences

1. Use of Elements Available in the IFRS Taxonomy (Guidance 1.2.2)

ESMA provides additional clarifications on how the elements included in the 2023 IFRS Taxonomy update can be used voluntarily through the extension mechanism. This follows the decision to postpone to 2024 the ESEF Regulatory Technical Standard (RTS) amendment in order to formally incorporate the 2023 IFRS Taxonomy update.

2. Anchoring Guidance (Guidance 1.4.1)

ESMA offers a clarification on the Creation of Extension Taxonomy Elements. The 2023 update explicitly advises not to create extension taxonomy elements that duplicate the meaning and scope of any ESEF core taxonomy element as per Annex IV.4(a) of the ESEF RTS. This point is emphasized in order to prevent a decrease in comparability between companies over time.

3. Block Tagging (Guidance 1.9.1 and Guidance 1.9.3)

First, ESMA reaffirms that the tag “Disclosure of notes and other explanatory information” is not required. This element is removed from all of the examples in the manual.

Moreover, a detailed footnote is added to Guidance 1.9.1, which offers further explanation on how to use elements from Annex VI of the ESEF RTS in addition to the mandatory Texts blocks. The footnote emphasizes that the use of these elements can be used to achieve a closer accounting meaning, but it cannot prevail over the use of mandatory elements from Annex II.

Finally, the update on Guidance 1.9.3 clarifies that detailed tagging does not override the requirement of block tagging notes, thus ensuring that the primary requirement of block tagging of notes to the consolidated financial statements is not compromised even when detailed tagging is applied.

This addition offers a new perspective, encouraging to explore detailed tagging options for the whole financial statements without neglecting the primary requirement of block tagging.

4. Guidance for Software Firms to Ensure Technical Validity

4.1. Tagging of dashes or empty fields (Guidance 2.2.5). ESMA recommends to tag empty fields or dash symbols in the primary financial statements. The update introduces additional guidance regarding the treatment of "nil values". It stresses that the transformation registry does not offer functions for transforming an empty field to a nil value.

In the absence of such functions, it recommends to explicitly specify nil values without any transformation, when this is relevant to the report. This additional guidance addresses scenarios where fields are empty, providing issuers with a method to accurately represent such cases in their reports without using transformation functions.

4.2 Readability of the information extracted from a block tag (Guidance 2.2.6) This point places a strong emphasis on clarity and legibility of the extracted information, noting that the information should not only resemble the original document in its semantic structure but also in "legibility and clarity". What this implies is that ESMA recommends the following main specifications:

• the information extracted/rendered in the tag should present words and numbers in the same order and be as legible and clear as the human readable report.
• Where there is space between words and numbers in the source text, there should be at least some space retained in the text block.
• Finally, the information contained in tables in the human-readable report should be "meaningfully transcribed" in the tagged information.

However, we should note that the use of words like “meaningfully transcribed” still leaves room to some interpretation.

4.3 Technical construction of a block tag (Guidance 2.2.7)

ESMA acknowledges the limitations in the transformation mechanics for producing XHTML documents. Until transformation mechanics are further improved, ESMA clarifies that to ensure a better resemblance of the extracted tagged information. It is mandatory to activate the @escaped attribute (setting it to “true”) if the human-readable content contains “<” or “&” characters, ensuring the reliability of the resultant data type. In all other cases, this option can alternatively be configured to “false” or “true”.

4.4 Formats of images embedded in xHTML document (Guidance 2.5.1) This point adds a specific note about SVG embedding, indicating that direct embedding of <svg> elements is not allowed, and that SVG images should be included within an <img> element or JPEG graphic files, excluding instead JPG graphic files.

4.5 Report packages (Guidance 2.6.1 and Guidance 2.6.2) In Guidance 2.6.1, ESMA advises to follow the recommendations of XBRL International about including Inline XBRL in a taxonomy package and provides an updated link to software firms that contains mandatory specifications.

For multiple Inline XBRL documents within a taxonomy package, Guidance 2.6.2 recommends to follow the approach proposed in the specification of report packages and provides an updated link for the recommendation to software firms with mandatory specifications

5. Technical Guidance for Issuers and Software Firms on Extension Taxonomies and Other Topics

5.1 Taxonomy packages (Guidance 3.1.3) ESMA recommends applying the latest version of the Taxonomy Packages specification, marked with Recommendation status, as published by XBRL International on the dedicated website. ESMA also recommends that to follow the specification on report packages in preparing the taxonomy package for submission.

5.2 Data types to be used on extension concepts (Guidance 3.2.2) ESMA updates a link for software firms to include additional rules of data type registry references in their tools.

5.3 Relationships to anchor extension taxonomy elements to elements in the ESEF taxonomy (Guidance 3.3.1) The Regulatory Technical Standards on ESEF states that extension taxonomy elements (excluding abstract concepts) should be anchored to elements in the ESEF taxonomy and that the relationship between the extension taxonomy elements should be identified.

6. Calculations (Guidance 3.4.1) ESMA believes that the Calculation XBRL 2.1 specification will be mitigated by the new specifications provided by XBRL International. The Calculations 2.0 specification will substantially enhance XBRL calculation functionalities that seek to provide more complete coverage of the calculations. However, Calculations 2.0 is still not a formal recommendation of XBRL International.

ESMA clarifies that Calculations 1.1 provided minor improvements to the “summation-item” mechanism defined in the XBRL 2.1 specification and improved handling of rounded and duplicate facts, which are particularly relevant to Inline XBRL-based reporting.

ESMA is closely monitoring the XBRL community developments around calculations and will consider recommending the use of Calculations 1.1 in due course. Therefore, the specification is discouraged for application in the ESEF report packages at this stage.

For now, users can still utilize the XBRL 2.1 specification.