Since 2021, issuers listed in the EU regulated market or in the UK have been submitting financial statements in HTML format with inline XBRL (iXBRL) tagging. While many countries chose to delay ESEF implementation, it was encouraging to see many companies prepare and file their ESEF documents voluntarily.
The iXBRL allows documents to be presented in a format that is both machine and human-readable. The adoption of iXBRL in ESEF reporting will make the European reporting data more consistent and comparable across all jurisdictions. It is therefore essential that the ESEF filings comply with the relevant technical specifications and have correctly embedded XBRL tags to ensure the quality and useability of data.
The XBRL International has introduced a series called ‘ESEF Errors and Common Pitfalls’ that examines the common errors that occur during the ESEF filings and measures to avoid them. Some of the errors pertain to technical issues and can be avoided by using automated validation using suitable software and others pertain to the content of XBRL data that require preparers to follow a comprehensive review process.
This blog is the first in the two-part series on the common errors and pitfalls in ESEF filings. In this article, we will look closely at errors that occur due to tagging values with incorrect signs, duplicate facts reported with inconsistent values, calculation inconsistencies, and errors in Report Package construction.
1 – Using Incorrect Signs
Tagging values with inaccurate signs is one of the most common errors that occur in ESEF filings. Preparers usually assign a negative value to a concept that should have a positive value according to XBRL concepts and vice versa. In XBRL, the sign used to show the value in a financial report is determined by the definition of the concept against which it is reported. Most often the organizations use the sign defined by the contribution it makes to the statement in which it is reported.
To avoid conflict and assign consistency in sign application, XBRL Formula rules have been incorporated by the ESMA-ESEF taxonomy. These rules will set off a warning if unusual signs are discovered. XBRL Formula rules ensure the reporting of incorrect signs but they can not guarantee a complete check because some concepts can validly take both positive and negative values. It is essential to double-check all tagged values to avoid misunderstanding and produce a flawless report, sans incorrect signs.
Example:
2 – Having Inconsistent Duplicates
Frequently, the same fact and value are reported in different sections of the ESEF report. The consistency of values can be ensured by tagging all the occurrences of a fact. This also helps consumers to navigate between different occurrences with ease and understand the details of the value using Inline XBRL software.
This multiple tagging of the same fact often means that the report contains duplicate facts. If the values are consistent across the report are not a concern as they can be de-duplicated when the data is being processed. However, it is impossible to determine the correct value for a fact when there are multiple facts reported with inconsistent values. Therefore preparers should thoroughly tag all duplicate numeric fact occurrences to guarantee consistency in the report. In case of duplicate text facts where some immaterial changes such as spacing or capitalization can create inconsistency, it is advisable to leave the additional occurrences untagged.
It is important to remember that the ESEF reporting handbook dissuades inconsistent duplicates. To allow conformant processors to confirm compliance with the requirement, XBRL Formula rules have been implemented in the ESMA ESEF taxonomy.
Example:
3 – Having Calculation Inconsistencies
In an XBRL Report, a taxonomy can be used to describe a calculation tree that defines and validates simple summations and arithmetic equations. The values of the facts presented in the reports must always compare with the calculation relationship stated in the taxonomy. Calculation inconsistency is a frequent reporting error that happens in case of a mismatch between the reported facts and the taxonomy-defined relationship. These portray errors in tagged values or calculation tree framework.
A document tagged with precision would scarcely report calculation inconsistencies. Following are the major causes of calculation inconsistencies:
- Incorrect signs: This occurs when the sign conventions used for reporting facts on financial reports do not correspond to the XBRL approach.
- A mismatch between the concepts of the calculation tree and the reported XBRL facts.
- Rounding Error: This is purely an artifact of rounding that occurs when the scaled rounded total does not conform with the rounded actual value.
The ESEF reporting manual mandates that the calculation tree should be used while defining any numerical relationship between the facts that are presented in the reports. Also, an extension taxonomy concept having “a subtotal of other disclosures in the same statement” does not require anchoring as such an interdependence would already be expressed in the calculation tree. Nevertheless, correct tagging of the report will ensure that the report is comprehensively consistent.
Example:
4 – Errors in Report Package
A Report Package is a specially formatted ZIP file that is used to submit an ESEF report containing multiple files. The Working Group Note published by XBRL International specifies how files within the ZIP file must be organized. For XBRL software to automatically discover the XBRL report within the ZIP, the contents must be properly structured and formatted. Failing to conform to the prescribed Report Package structure can also disable a report to open in XBRL software.
Faulty Report Package construction usually occurs due to the following:
- Multiple top-level files: Having a single top-level directory inside the Report Packages is essential for conformant software to detect XBRL files with the ZIP automatically. Also, a .DS_Store directory may indicate the ZIP file has been edited manually after creation, rather than generated by XBRL software. A certified XBRL software can help preparers to validate the Report package, with a minimum of hassle.
- Incorrect path separators: Directories within the ZIP must use / rather than \ as the directory separator. Non-conformance to this requirement indicates that the ZIP file is invalid and has been manually edited after creation.
- Invalid taxonomy metadata: The metadata in Report Packages must conform to the taxonomy file whose structure is defined by an XML schema. A certified XBRL software will ensure that the validation is performed correctly.
Example:
This series is intended to provide information on common errors and enhance the quality of digital filings. Stay tuned in for our next article, in which we cover a few more common ESEF errors and how these pitfalls can be avoided.
