Guidance on Block Tagging and Other ESEF Reporting Manual Updates from ESMA
The European Securities and Markets Authority (ESMA) has recently published an updated version of the ESEF Reporting Manual. The next reporting cycle will see a significant expansion of the European Single Electronic Format (ESEF) tagging requirements, with preparers now required to tag the notes that accompany their financial statement. The updates to the reporting manual include rules and guidance on how these so-called “text block tags” are to be prepared, as well as changes to fine-tune existing rules. In this blog, we will discuss the most significant changes in the new reporting manual.
Text block tagging of notes to financial statements
Text block tagging is a major addition to ESEF requirements for the coming reporting cycle. For financial years beginning on or after 1 January 2022, issuers must “block tag” the notes to their financial statement. In a block tag, the content of an entire section of a report is tagged as a single fact. The tag may include text, numerical values, tables and other data. The phrase “block tag” refers to the fact that the whole disclosure is tagged as a single block — any numbers or tables within the note are not individually tagged.
Preparers are required to tag any disclosures in their financial statements that correspond to IFRS concepts on the list in Annex II of the Regulatory Technical Standards (RTS).
Section 1.9 of the updated manual provides essential guidance on how text block tags are to be constructed.
Let us look at some examples to understand how block tagging is intended to work. Figure 1 is an extract of a disclosure of tax liabilities from the notes to a financial statement.
Figure 1 – Extract of disclosure of tax liabilities
In this case, the entire disclosure in Figure 1, including both the complete table and the narrative text below, would be tagged with one concept, ‘Disclosure of tax receivables and payables [text block].’ This approach differs from that taken in primary financial statement tagging, where each number has to be assigned a separate tag.
Figure 2 is an extract from a disclosure of accounting policies. The content of the disclosure is broken down by topic.
Figure 2 – Extract of disclosure of accounting policies
In this case, the note contains disclosures that correspond to multiple required concepts. The section as a whole corresponds to the “Disclosure of accounting judgements and estimates [text block]” concept, and then text within the section corresponds to concepts for individual policies, such as “Description of accounting policy for fair value measurement [text block]”. The filing manual explains that all such concepts should be tagged, resulting in overlapping tags as shown by the coloured boxes in Figure 2.
In some cases, disclosures do not form a single continuous block. Inline XBRL provides two useful mechanisms, known as “continuation” and “exclude” which can be used to construct a single text tag from separate sections of a document.
Block tagging multiple tags with the same or overlapping values and tagging discontinuous sections are standard features of Inline XBRL report creation. The technical details of such tagging are largely taken care of by Inline XBRL software. XBRL International’s Inline XBRL tagging guidance offers detailed explanations of using multiple tags and discontinuous section tagging.
The manual notes that block tags extracted from the Inline XBRL report may not be formatted in the same manner as seen in the human-readable version. This topic is inherently complex, particularly given the nature of the HTML used to achieve the highly-designed appearance of many ESEF reports. The filing manual takes the approach of requiring only the basic essentials of technical validity of the extracted value, and accuracy of its text content, noting that it is expected that the XBRL community will develop new approaches and solutions in this area. We welcome this pragmatic approach.
Annual financial reports in other formats and languages
The introduction of ESEF represented a significant change to the established process for the preparation of annual financial reports (AFRs). Perhaps understandably, many companies have chosen to continue to publish AFRs in PDF and other formats, in addition to the Inline XBRL-based ESEF format. The updated filing manual adds some welcome clarity on the status of these additional reports by recommending that anything that is not an official ESEF report is clearly marked as such.
The reporting manual confirms that AFRs prepared in the ESEF format are the only “official ESEF version” necessary to comply with the obligations of the Transparency Directive. It recommends that AFRs prepared in other formats (e.g. PDFs) should highlight and clearly state that they are not the official ESEF version of the AFR. If an AFR is published in any other format before the official ESEF format publication this requires justification.
Where there is a legal requirement to present an AFR in more than one language, each report should be in ESEF format and the report contents and tagging should be consistent. On the other hand, where AFRs are published in an additional language, but this is not legally mandated, it should be labelled as a non-official version and “translation”, regardless of the format that it is published in.
The following flow chart summarises these recommendations for AFRs published in additional formats and multiple languages. Detailed explanations can be found in sections 1.0 and 1.1 of the manual.
We regard this new guidance as helpful, since the recommendation on marking alternate AFRs as non-official provides useful clarity and helps affirm the definitive position of the ESEF AFR to report preparers and users.
Reducing validation “false positives”
ESEF reports are validated against the rules published in the reporting manual. In some cases, these rules raise “false positives” — errors or warnings that do not reflect any real issue in the report. False positives are a problem, as they may cause preparers to make undesirable modifications to their report in an attempt to silence the error or warning. Even more importantly, requiring preparers to routinely ignore false positives can also lead to real validation errors being ignored.
We are pleased to see a number of changes in the reporting manual that seek to reduce the number of false positives in validation results.
Conditional mandatory elements
A major cause of false positives is the need to report “mandatory” elements which are not relevant in a particular report. For example, if a company changes its name, it is mandatory to tag an explanation for the change in name – but most of the time, when a company has not changed its name, this disclosure is not required. Currently, the validation applied to reports is not conditional, and the absence of the explanation tag will be flagged as an error, even if the company has not changed its name. Issuers have attempted various different mechanisms to address this validation failure, such as reporting an ‘NA’ value. The updated reporting manual clarifies that mandatory elements (listed in RTS Annex II) need to be tagged only if the corresponding disclosures are present in the AFR. Further, it states that filers are not required to include unnecessary disclosures solely for the purpose of satisfying mandatory element tagging rules, or to indicate that such disclosures are not present.
This change is very welcome, but it also needs to be reflected in the validation rules embedded in the taxonomy that are applied automatically by XBRL software.
Element naming conventions
The latest manual has removed the earlier recommendation of naming elements by applying the “LC3 convention” to the element’s label. Whilst the LC3 convention can provide a reasonable starting point for element names, applying it in a multi-language environment such as ESEF introduces complexity, and dogmatic application of this rule can result in a lack of consistency in element names across filing periods, which can hamper analysis.
Extension abstract concepts
Finally, the reporting manual no longer discourages the creation of additional abstract concepts (or headers) in the extension taxonomy. Although such new abstract concepts are rarely necessary, their introduction is harmless and they can aid construction of the presentation tree in certain circumstances.
We look forward to seeing these changes, and to the ongoing development and improvement of the ESEF format and guidance as all stakeholders gain in experience.
