Top 7 mistakes when filing in ESEF

Do you work for a company listed on a European stock exchange? Are you about to publish your annual financial report in ESEF? Is it your first time? If you can answer ‘yes’ to any of the questions above, then you’ve come to the right place. In this article we’ll go over the 7 most common errors when reporting in ESEF, but first, we need to tell you a little bit about the different types of mistakes you can experience.

Not all errors were created equal

When it comes to ESEF, you can experience issues in three different categories, and while some will block your ESEF package from getting a positive validation, others are simply notifications that there is something you need to double check. The categories of issues you can experience are called:

• Errors
• Inconsistencies
• And warnings.

An error is the issue most likely to block your financial report from receiving a positive validation. Because of that you should always aim to fix errors. Inconsistencies are usually acceptable. For instance, if you use roundings in your financial statements, you may experience a situation where you are stating that 2+2=5. As long as you follow the relevant accounting principles, that’s not illegal, but ESEF validation tools will still remind you to make sure. Warnings are issues raised by the contents of your annual reports. They aren’t classified as blocking or even as non-blocking. It’s simply a notification that you need to double check the element in question. If you want to learn how to differentiate blocking and non-blocking issues in your ESEF filing, we’ve added a short explanation at the end of this article. Now, however, it’s time to dive into the different errors, inconsistencies, and warnings you should be looking out for.

1. Incorrect use of signs

When calculating your financial statements, you would typically determine a value as positive or negative based on the contribution it makes to the statement in which it is reported, but in XBRL a value is determined to be positive or negative based on the definition of the concept it is reported against. For instance, when you report Cost of Sales in your financial report, you report it as a negative value. This is because it reduces the total Gross Profit. In XBRL, however, it’s a little different. The concept Cost of Sales has a positive value in XBRL, because it represents the amount paid and not the amount lost. This means, that reporting Cost of Sales with a negative fact value would mean that your Cost of Sales have earned you money within the reporting period. However, that doesn’t mean you cannot have negative values in this way. A company indebted, for instance, could easily be reporting their Reserves with a negative fact value, and that might be completely correct. In both cases, most XBRL consumption tools would give you a warning message such as “reported value below 0” or “negative fact value found”.

2. Inconsistent duplicates

It is not uncommon to report on the same fact in multiple different sections of your financial report, so to ensure that the values of identical facts remain consistent across your financial report, each instance needs to be tagged. Tagging the same fact multiple times across a report will not pose any problems. However, if two instances of the same fact have different values, it will lead to what is commonly referred to as inconsistent duplicates. Inconsistent duplicates in your financial statements are especially problematic. If, for instance, you report your Net cash flow from investing activities as 23,001 in but as 23,002 in another, there is no way to know which number is correct. While the example above could simply be due to a typo during the reporting process, it could also be an attempt to correct a rounding issue. In any case ESMA discourages inconsistent duplicates and so, they should be avoided. The one exception to this rule is duplicate text facts. This is in reverence to the fact that text facts may differ due to immaterial changes such as spacing or capitalization.

3. Calculation inconsistencies

A calculation inconsistency is a nice way of saying that the math in your report doesn’t add up, and the severity of this issue can vary widely depending on the situation. While it may be caused due to your team making a calculation error or a simple typo, the most common reason is because of a rounding error. While roundings aren’t inherently problematic they may still cause issues. This is because XBRL doesn’t differentiate between a rounding error in a report which is accurate to the nearest thousand and a report which is accurate to the nearest million. Instead of figuring out which is correct, any inconsistency is registered as cause for alarm. That said, calculation inconsistencies aren’t going to block your report from positive validation, but they should be double checked to make sure they are harmless rounding errors and not something more severe.

4. Hidden transformable facts

Any iXBRL file such as an annual financial report published in ESEF, consists of two different layers. A visual layer and a technical layer. If a fact only exists on the technical layer of your iXBRL file, it will be consigned to the hidden section. However, not all facts are allowed in the hidden section. In fact, the only things allowed in the hidden section are facts for which there are no transformation rules in the Transformation Rules Registry (TRR). While you can always look through the TRR, it is much easier to assume that at least all monetary values are eligible for transformation, and thus should not be found in the hidden section.

5. Redundant labels

When reporting in ESEF, preparers are supposed to use the base taxonomy elements in the ESEF taxonomy, and only create new labels in the form of extensions when the closest taxonomy element misrepresents the meaning. In many of the 2020 ESEF filings, preparers have redefined base taxonomy elements in their extension taxonomies, and in the vast majority of these cases the redefined labels do not differ in meaning from the labels in the base taxonomy but are created to make the label more closely match the line-item description used in the report. For instance, a company might have the line-item Net rental income in their financial report. Ordinarily this should be tagged with the IFRS concept Rental income from investment property, net of direct operating expenses. However, the preparer may choose to replace the base taxonomy label with the extension Net rental income, so it matches the line-item description. Not only is the approach described above redundant and adds unnecessarily to the size of the report, but it also muddies the new standard and makes ESEF reporting less transparent, especially if every company starts making slight alterations to the labels used.

6. Incorrect balance dates

Facts tagged with the wrong date is a quite common error in XBRL reporting, and the same goes for annual reports created in ESEF. This happens because there are different conventions used to describe reporting dates and periods. For instance, the balance fact ’total assets’ (which is an instant) can be reported as both a closing balance, which would be the end of a reporting period (meaning after business closes) and as an opening balance, which would be the beginning of a reporting period (meaning before business opens). Now a closing balance for one reporting and an opening balance for the next are essentially the same thing, and because of this XBRL does not distinguish between the two, but instead applies a single, consistent interpretation all balance facts. In XBRL a balance date is always understood to mean the end of the date, after business closes. This doesn’t make any difference when reporting closing balances, but when reporting opening balances, you must use the date of the previous day. This is true for instants, but if you apply the same logic for facts reported over a period (durations) you would run into issues. In XBRL a duration fact is defined by the first and the last date included in the period. In other words, if you report on a period covering the entirety of 2021, it is correctly tagged as ‘January 1, 2021, to December 31, 2021’.

7. Incorrect package name

The most common issue when it comes to naming, however, happens when you download or export the final file from your provider. If you save multiple files with the same name in the same location, your browser will automatically add extensions to differentiate the files, which results in a parenthesis with a number at the end of a name like so: