Key updates of the latest reporting manual and how they will impact the upcoming reporting season.
The European Securities and Markets Authority (ESMA) has recently updated its Reporting Manual, introducing several changes that will impact the upcoming reporting season. For a complete overview of these updates, you can visit the official ESMA website. However, to make it easier for you to understand how these changes will specifically affect your reporting process, ParsePort has taken the initiative to highlight the most relevant topics.
In this article, we will dissect these key updates and compare them to our current approach and practices. Our goal is to provide you with a clear and comprehensive understanding of the implications for your reports in the next reporting season.
Guidance 1.2.2: Use of elements available in the IFRS Taxonomy that were not yet included in the ESEF taxonomy.
“ESMA suggests that issuers should determine if the IFRS Taxonomy includes an element that corresponds to a disclosure of the issuers report and it is not present in the ESEF taxonomy. The issuers should define an extension taxonomy element whose name, label and XBRL characteristics correspond to name, label and XBRL characteristics of the element in the IFRS Taxonomy.”
The taxonomy element "Property, plant, and equipment including right-of-use assets" has been selected as an example of how elements from the 2023 update to the IFRS taxonomy can be voluntarily utilized until the 2024 amendment to the RTS on ESEF becomes mandatory for financial years starting on or after January 1, 2025.
At ParsePort, we are committed to adhering to the taxonomy syntax and configurations. This approach ensures that when the taxonomy is updated, any extensions can be seamlessly replaced by standard elements, thereby maintaining the comparability of our clients' files.
By choosing ParsePort for your tagging needs, you can rest assured that these updates will be implemented effortlessly. Once the new taxonomy, including the standard elements, is published, the transition will be as smooth as a snap of the fingers.
Our goal is to make your reporting process as efficient and compliant as possible, ensuring that you are always up-to-date with the latest standards and regulations.
Guidance 1.4.1: Anchoring of extension elements to elements in the ESEF taxonomy that are wider in scope or meaning
“Moreover, ESMA is of the opinion, that to improve the quality and usability of the anchoring relationships in issuers’ extensions elements, issuers should anchor their extension elements to ESEF core taxonomy elements sharing the same data type. For example, if an issuer creates an extension element of monetaryItemType, such element should only be tagged to corresponding ESEF core taxonomy element of monetaryItemType (and not e.g. stringItemType).”
At ParsePort, we have long adhered to best practices in taxonomy extensions, ensuring that your reports are both accurate and compliant. While it may seem obvious, it is crucial that the extensions used in your report "mimic" the characteristics of their anchoring elements (wider anchor).
An extension serves as a mechanism to "fill a gap" that the core taxonomy cannot address. However, the fundamental principle of extended taxonomy instructs us to anchor to the closest available meaning. This means that the extension and its anchor should be aligned, particularly regarding their data type.
By following these best practices, we ensure that your reports maintain their integrity and comparability, even as taxonomies evolve. At ParsePort, our commitment to these principles guarantees that your reporting process remains seamless and compliant with the latest standards.
Guidance 2.2.5: Tagging of dashes or empty fields
“To facilitate the analysis and comparison of the data contained in the IFRS consolidated primary financial statements, ESMA recommends that issuers take into consideration the following guidance when marking up empty fields or dash symbols in their statements.”
There is often some debate about whether to use zeros, dashes, or empty spaces in financial statements. At ParsePort, we recommend that customers always tag the zero values in all statements (Income Statement, Comprehensive Income, Balance Sheet, and Cash Flow). For example, if Period 1 shows 200, then Period 2 should have either a zero or a dash, but not an empty space.
Exceptions may apply to the Statement of Changes in Equity (SOCIE), depending on whether the line items are the same in both tables. As a general rule of thumb, we suggest tagging dashes as zeros, ensuring they appear visually in the report as well.
By following these guidelines, you can maintain consistency and clarity in your financial statements, making them easier to read and interpret.
Guidance 2.2.7: Technical construction of a block tag
“In line with the XBRL International Working Group Note published on 19 April 2023 for facts with a datatype of dtr-types:textBlockItemType, issuers shall always set the iXBRL @escape attribute to “true” to ensure that the resulting fact value is XHTML valid. Meanwhile, the facts with other datatypes, such as xbrli:stringItemType shall instead set the @escape attribute to "false" as their values are not expected to contain XHTML.”
The ParsePort Platform is already configured in accordance with the new ESMA guidance 2.2.7. ESMA emphasizes the importance of complying to best practices in XBRL, a standard we are fully committed to upholding.
This update simplifies our processes significantly. Now, all BlockItemType elements (all text blocks) will always be escaped, regardless of whether the text contains specific symbols such as "<" or "&". This ensures consistency and compliance across all reports, making your reporting experience smoother and more reliable.
At ParsePort, we continuously strive to align with the latest regulatory standards and best practices, ensuring that our platform remains at the forefront of XBRL reporting.
Guidance 2.6.1: Including Inline XBRL document in report packages
“ESMA recommends that issuers prepare their ESEF submissions according to the Report Package 1.0 specification published by XBRL International, which indicates how Inline XBRL documents are to be included within a report package.Issuers should follow all the provisions of the above specification, specifically in the context of the recognised file extensions for report types and report packages. Moreover, ESMA recommends that software firms ensure that, in case of incompliance with the above specification, the official specification error codes are presented to issuers.”
With the implementation of the above recommendation and the adoption of The Report Package 1.0 specification, the format of the extracted files will be changing. For the upcoming reporting season, you will be able to extract reporting packages from the ParsePort Platform in the new .xbri format, replacing the previous .zip format.
Rest assured, this transition will occur automatically within our system, so there is no need for concern. To ensure a smooth preparation for the next reporting season, please make sure to update your input files to the latest version. Once updated, you will be ready to convert your files seamlessly!
Guidance 2.6.3: Naming convention for report packages and report file
According to the Manual “the {version} component of the filename should indicate the version of the ESEF report package submitted to the relevant authority. Specifically, a separate digit will be added after the {date} component (separated by the hyphen-minus character). This digit is limited to only one numeric character after the hyphen-minus character and will represent the version of the submission (i.e. for the first submission it should always be 0, for every next resubmission of the same package it should be incremented by 1)”
Example: 12345NOTVALID1234503-2023-12-31-0-en (First submission)
Remember: Whenever an OAM or a National Competent Authority provides indications of different naming conventions which are required at national level, issuers must follow such national naming conventions.
Considering that the engine can’t anticipate how many versions have been already submitted, the option to adjust the counter will be available in the input files (Excel template) to be overridden in case of a different version.
Guidance 3.4.1: Documenting arithmetical relationships in the calculation linkbase
“ESMA recommends that calculation inconsistencies resulting from the evaluation of calculation linkbases of the extension taxonomy should be carefully reviewed, since those can point to tagging issues. Some calculation inconsistencies may not be possible to avoid, even with the application of Calculations 1.1. Notably, Calculations 1.1 may still trigger false positives when there are incomplete fact sets. This occurs when there are enough facts to trigger a calculation, but not enough to check it completely . One such example of a calculation inconsistency that may arise due to incomplete fact sets is presented in the following paragraphs: A fictitious issuer’s extension taxonomy includes the following calculation in the Statement of Comprehensive Income: Comprehensive income = Profit (loss) + Other comprehensive income In the same issuer’s extension taxonomy, the issuer uses in the statement of changes in equity the elements “Comprehensive income” and “Profit (loss)”. The issuer elects to use two new elements (“Other comprehensive income that will be reclassified to profit or loss” and “Other comprehensive income that will not be reclassified to profit or loss”) instead of the element “Other comprehensive income”. In this case, the calculation defined for the statement of comprehensive income will be also evaluated for the statement of changes in equity, but will be able to only include the value of the elements “Comprehensive income” and “Profit (loss)”, while the value for the omitted element “Other comprehensive income” will be 0. Therefore, the result of the calculation will be deemed incorrect and will be raised as a calculation inconsistency. The fact that a calculation inconsistency is flagged does not mean that the ESEF inline XBRL report is incorrect. A calculation defined for the statement of comprehensive income has also been applied to the statement of changes in equity, where there are sufficient facts to trigger a calculation (“Comprehensive income” and “Profit (loss)”), but not sufficient to check it completely as the fact “Other comprehensive income” is missing. Therefore, ESMA considers that these type of calculation inconsistencies could be disregarded”
The latest version of the ESMA Manual provides expanded information on calculation inconsistencies, elaborating on the most common issues observed to date. Specifically, it references Calculations 1.1 and highlights that these inconsistencies often arise not from incorrect calculations, but from the selection of elements used in different statements.
In the provided example, the accounting treatment is correct, as both Other Comprehensive Income (OCI) components used in the Statement of Changes in Equity (SOCIE) accurately represent the total OCI. However, from an XBRL perspective, there is a discrepancy that, while present, is considered non-blocking.
This expanded guidance helps clarify the nature of these inconsistencies and underscores the importance of careful element selection to ensure both accounting accuracy and XBRL compliance. At ParsePort, we are committed to helping you navigate these complexities, ensuring your reports are both accurate and compliant.
You can know more about it here.
Guidance 4.1.5: Naming convention for stand-alone XHTML documents
New guidance in line with the adjustment in Guidance 2.6.3. The recommendation in regards to the name of the file is also applicable for the xHTML files (Stand-alone, individuals) meaning that the file downloaded from the ParsePort Platform should be renamed.
Guidance 3.4.8 (NEW): Documenting arithmetical relationships in the presentation linkbase
“Some of the Primary Financial Statements contain a number of cross-period arithmetic relationships that cannot be reflected in the calculation linkbase. An example for cross period arithmetic relationships is the statement of cash flows where the sum of inflows and outflows of the period corresponds to the change of the cash balance from the beginning of the period to the end of the period. Another example is the statement of changes in equity that contains reconciliations between the carrying amount at the beginning and the end of the period for each component of equity. As the calculation linkbase cannot be used to effectively define data quality checks on such cross-period relationships, the presentation linkbase should be used to document these cross-period and cross-dimension arithmetical dependencies which shall enable the execution of at least semi-automated validations.”
The updated guidance in the new version of the ESMA Manual, derived from guidance 3.4.1, introduces a recommendation (not mandatory) to include abstracts that define the calculation period for sections of the report covering a specific time span. This is particularly relevant for Statement of Changes in Equity calculations, which span the beginning and end of a period and cannot be represented in the calculation linkbase. Implementing this recommendation can help resolve related issues, especially if requested by your auditor.
Below, you will find a list of other guidelines in the ESMA Reporting Manual that have been updated and adjusted with minor changes.
Guidance 1.1.2: AFRs presented in more than one language
Guidance 2.1.2: Formatting of the period element in the context of the Inline XBRL document
Guidance 2.2.6: Readability of the information extracted from a block tag
Guidance 2.6.2: Including multi-html Inline XBRL documents and multiple Inline XBRL document sets in report packages
Guidance 3.1.3: Taxonomy packages
Guidance 3.2.2: Data types to be used on extension concepts
Guidance 3.3.1: Relationships to anchor extension taxonomy elements to elements in the ESEF taxonomy
Guidance 2.2.8 (NEW): Use of the ID attribute on facts