In 2021 the European Securities and Markets Authority (ESMA), the EU securities regulator published the 2021 European Single Electronic Format (ESEF) XBRL taxonomy files based on the 2021 IFRS Taxonomy to facilitate the implementation of the XBRL reporting.
The ESEF Regulation requires that all issuers with securities listed on an EU-regulated market prepare their annual financial reports in xHTML and mark up the International Financial Reporting Standards (IFRS) consolidated financial statements contained therein using XBRL tags and the iXBRL technology.
For many issuers, ESEF filing is their first experience in creating XBRL reports. Early filings often have quality issues that need to be addressed to ensure the usability of the XBRL data.
In May 2021, XBRL International released a series themed ‘ESEF Errors and Common Pitfalls’ which explores common errors that occur when completing the ESEF reports and how to avoid them. In this article, BR-AG briefly outlines the most common traps the ESEF filings, which mainly concern:
- Incorrect tagging
- Calculation inconsistencies
- Taxonomy package issues
Quality data is key to making sustainable decisions. Poor quality data leads to faulty analysis and investment decisions, poor customer relationships, and ineffective business campaigns.
Tagging values with an incorrect sign (negative value) can lead to significant misunderstanding for everyone working with the XBRL data. In paper-based or other human-readable reports, a value is presented according to its effect on the sum to which it contributes. In an XBRL report, the sign for an XBRL fact is represented according to the definition of the concept (e.g., profit, turnover, assets) and is independent of its presentation. This difference leads to significant errors in XBRL reports.
There is a specific characteristic in XBRL which is the balance attribute for an element that can either be set as ‘debit’ or as ‘credit’ which affects the calculation.
In the above example, the interest expenses element is defined in the taxonomy as debit, which means it is deducted from credit values. In the human-readable report, this value is given in brackets which means that it is deducted. If an issuer reports this value with a negative sign, in XBRL it is treated as a “- -“ value, and two minuses give a plus. Consequently, in the XBRL report, this value will be added instead of deducted.
To correctly tag a given figure in XBRL, you may need to assign the opposite sign to it from what is presented in a paper-based report. The best approach is to follow the attribute defined in the taxonomy even if it seems incorrect. If profit is defined as a debit, enter the element with a negative value. Do not create an extension element to correct the balance attribute.
Incorrect signs trigger the calculation inconsistencies in a report which are described further in this article.
Incorrect dates and period definitions, largely arising from opening balances, are a very common issue in the ESEF filings. This is due to the different conventions that are typically used to describe dates and reporting periods. XBRL does not distinguish between a closing balance for one period, e.g., 31st December, and the opening balance of the next day, here 1st January, because they are in fact the same thing:
- end of 2006-12-31 (23:59:59+1s) = beginning of 2007-01-01 (00:00:00)
BUT in XBRL:
- end date 2006-12-31 = instant 2006-12-31 = start date 2007-01-01
Accordingly, XBRL applies a single interpretation to all balance facts (instant facts). This means that the balance reported on a given day is the balance as at the end of that day. While for closing balances, this is not a problem, for opening balances the previous day’s date must be specified.
A rather large problem with XBRL reports arises when companies focus on the presentation (e.g., HTML) of the reported figure rather than its underlying meaning.
Multiple tagging (data duplication) of the same fact in different parts of the report can be problematic for early filers. While duplicates that have the same value (Complete Duplicates) can be easily de-duplicated, duplicate facts reported with inconsistent values (Inconsistent Duplicates) are more problematic as it is not clear what the correct value for a fact should be.
It is worth remembering when rounding values, that facts when rounded, get the same value as other facts in the report, and hence become Consistent Duplicates. If you look purely at the values consistent duplicates are indistinguishable from complete duplicates. Keep this in mind when de-duplicating facts and remember the meaning behind all facts in your report.
Calculation errors, per se, do not invalidate the report. BUT they often indicate errors in the data provided or in the design of the calculation tree which describes simple totals and subtotals in an XBRL report. The three typical reasons for calculation inconsistencies are:
- facts being reported with the incorrect sign,
- concepts in the calculation tree do not match the facts included in the report, and
- rounding errors, which in practice are mathematical errors, not issues directly related to XBRL (see below)
In the human-readable reports values are often scaled and rounded for better readability. Rounding error is a rounding artefact that occurs when a scaled, rounded total value does not agree with the rounded actual value.
Dedicated XBRL validation software may help identify the different causes of calculation inconsistencies.
Another highly prevailing issue affecting especially the newer filers is failing to follow the recommended report package structure. This is probably the most common error in ESEF filings and is the reason why reports may not open in XBRL software.
An ESEF report consists of multiple files that must be uploaded in a specially formatted ZIP file, called a Report Package. The files in the Report Package ZIP file must be set in a specific way, which is currently defined by the Report Package Working Group Note, soon by the Report Packages 1.0 specification.
While a Report Package is a simple ZIP file, its contents must be structured correctly as this allows the XBRL software to automatically locate the XBRL report and other files within the ZIP. Report packages should include standardised metadata that describes included the taxonomy. Also, they must have a single top-level directory inside the ZIP, otherwise, the software will not be able to automatically locate the XBRL files in the ZIP.
For example, many filings include a PDF file at the top level, which violates this rule. Some ZIP software incorrectly uses path separators. The ZIP file specification requires that directories in a ZIP use “/” rather than “\” as the directory separator.
Human error is naturally a major cause of the inconsistencies in XBRL reporting, and it takes a learning curve to be XBRL-ready. Reporting in XBRL is about values and the meaning around them. It is certainly good practice for all, but especially for new filers, to understand the standards and filing rules, but also to use accounting and financial reporting experience to your advantage to report the correct values in XBRL.
Even though there may be some setbacks along the way to transitioning to XBRL, it is worth it to tell the right financial story so that your data is consumed accurately by the end-users.
Get in touch with our experts to find out more about ATOME Solutions: