Top 7 mistakes when filing in ESEF
Not all errors were created equalWhen 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:
- And warnings.
1. Incorrect use of signsWhen 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 duplicatesIt 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 inconsistenciesA 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 factsAny 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 labelsWhen 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 datesFacts 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 nameThe 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:
However, the parenthesis is only added to the zip-folder containing your ESEF report, and because you need the name of the zip-file to be consistent with the directories kept within, this will cause an issue. It is very easy to remedy, though, as deleting the “(1)” from the file name will rectify this issue.
Avoiding common ESEF errors
The easiest way to make sure that your annual financial report in ESEF will receive a positive validation, is to make use of an XBRL review software such as the ParsePort XBRL Inspector, as it will give you the opportunity to review every error message related to your reportc