Welcome to the third blog of our four-part series on the technical aspects of the ESEF iXBRL Mandate. In this article, we will look closely at the potential validation warnings you may see in your iXBRL document based on the validation rules built within the ESEF taxonomy. Make sure that you catch up to speed on the Guidelines issued by ESMA in the first blog of this series and develop a thorough understanding of Validation Rules in our second blog.
Let’s begin!
You may see warnings when you are validating your iXBRL document either at the creation stage or the submission stage. Keep in mind that of the 477 Validation Rules built into the ESMA ESEF taxonomy 2019, only 9 have been classified as Errors and the balance of 468 have been classified as Warnings.
What are warnings?
The Cambridge Dictionary explains a warning as “something that makes you understand there is a possible danger or problem, especially one in the future.”
In the context of validations, warnings alert the user about possible problems in their iXBRL file. Unlike Errors, validation warnings will allow you to proceed with your ESEF Filing. This implies that if you submit your iXBRL file to your regulator with one or more warnings, then it shall still be considered a valid submission.
So why do you need to even try to understand these warnings when they are not going to impact your ESEF filing? Warnings will shed light on possible problems in your financial report. These warnings will point out mistakes/discrepancies that could be in the XBRL tagging or even in the annual Financial Report (AFR) itself that may be present in your filing. It is important to report accurately, after all, this report may be viewed by potential investors. Addressing Warnings will improve the quality of your report and bring to light issues that you may not have realized could be an issue in the first place.
Still, while warnings will highlight most issues, it does not mean that your annual report will be considered to be 100% mistake-free. This is because the ESEF filing is validated using the embedded XBRL tags. Hence if any section has not been tagged at all and the same contains a calculation mistake, then such calculation error cannot be identified by any validation tool. Also, ESMA may have not built rules in the ESMA taxonomy covering each and every possible scenario.
The 465 Validation Warnings can be segregated into broadly 11 categories as explained below:
Mandatory Tags
As the name suggests, mandatory tags are XBRL tags that must be present in your ESEF filing. While ESMA has stated that these tags are mandatory, they have assigned the severity for these validation rules as Warnings.
While these tags are not compulsorily required to be tagged (since their absence is still considered a warning), it will be a good practice to start tagging them from the get-go. Currently, the absence of the 9 XBRL tags shared below will be considered a warning. We also recommend that you update yourself on the new ESMA taxonomies when they are released to see if these tags are reclassified as Errors.
Address of entity’s registered office
Country of incorporation
Description of nature of entity’s operations and principal activities
Domicile of entity
Explanation of change in name of reporting entity or other means of identification from the end of the preceding reporting period
Address of entity’s registered office
The legal form of entity
Name of the parent entity
Name of ultimate parent of groups
Principal place of business
International Accounting Standard 1 (IAS 1)
IAS 1 Presentation of Financial Statements requires comparative information to be disclosed in respect of the previous period for all amounts reported in the financial statements, both on the face of the financial statements and in the notes unless another Standard requires otherwise.
There are 2 Validation Rules to verify this. The rules are built to ensure there must be at least 2 unique contexts (dates) present in the file. One rule deals with Instant contexts while the other deals with Duration contexts. Check out this blog to understand more about what these contexts mean.
ESMA Guidelines
In our first blog, we covered how ESMA has issued Guidelines to Issuers and Software firms. There are 50 Guidelines all of which 12 are aimed at Issuers while the balance 38 are aimed at the Software Firms. In addition to merely publishing these Guidelines, ESMA has also gone ahead and created Validation Rules for 6 of these guidelines. There are in all 14 Validation rules which check for these 6 guidelines.
Some examples are:
According to Guidance 2.1.2 of the ESEF Reporting Manual, it is recommended to present the period element in the YYYY-MM-DD format without the time component. Please make sure that the XBRL context period end date is provided with a date value following the recommended format.
According to Guidance 2.5.2 of the ESEF Reporting Manual, it is recommended that a language attribute is assigned to all textual facts. Please make sure that XML: lang attribute is inherited or assigned to each textual fact.
Fact equivalence validations
Any data or fact can be reported multiple times in the same Annual Report. It is recommended that you tag each such instance. Here you may use the same XBRL tag, with the same context, throughout your iXBRL filing. However, that is not the only possibility. You may also tag the same fact by using different XBRL tags and it may still be correct. Well, you may be wondering how this can be done. Let us explain this with an example.
Let us say you want to tag a fact that represents the amount of Goodwill owned by you. There are two ways by which you can capture such a fact.
Option 1: The Non-dimensional way
By the non-dimensional way, we mean that a single XBRL tag will be used to capture the fact. For the purposes of this example, we would be applying the tag “Goodwill”. We would of course have to couple it with a context and other attributes such as language, decimal, and unit to make it more meaningful.
Option 2: The Dimensional way
By the dimensional way, we mean that in addition to the XBRL tag (which would represent the broader concept), we would also be applying a dimension (which would narrow it down to the concept that we wish to tag). For the purposes of this example, we would apply the broader tag “Intangible assets and goodwill” and then apply the dimension “Goodwill [member]”.
To understand more about dimensions click here.
Technical validations
In the previous section, we spoke about how the same fact can be disclosed multiple times in the Annual Report and should ideally be tagged each time. However, there are certain scenarios in this situation that could lead to a warning.
This rule has been created to identify instances when the same XBRL tag with the same context has been tagged to use more than one value that is not identical.
There is a possibility that you may have assigned the wrong tag to a fact.
You may have applied the correct tag but with the wrong context leading to a mismatch.
You have applied the correct XBRL tag; however, there are mistakes in the Annual Report itself. This is a serious concern and would require you to first correct the Annual Report itself.
Yet another scenario could be wherein the tagging is correct, however, the mismatch is due to other factors such as rounding-off which would require no change from your end and such warnings can be ignored.
Cross period validations
There are 32 cross-period validation rules present in the ESEF taxonomy. This rule checks the arithmetical accuracy for a given concept over a period of time. What it checks is whether the sum of the opening balance and the changes during the reporting period matches with the value reported for the closing balance.
Let us look at the example below:
The opening balance of Equity as of 31st December 2017 is € 500 and the changes during the year 2018 are € 50. Accordingly, the closing balance of Equity as of 31st December 2018 should be € 550. However as can be seen in the above image, the value captured is only € 540 resulting in a mismatch.
This could indicate an issue in tagging or there could be an inherent mistake in the Annual Report itself.
For many issuers, this year’s annual report will be your first time exploring iXBRL and the technical aspects associated with it. Just remember that the end result will benefit you tremendously, and this is simply a learning curve that you need to navigate. If you find yourself feeling overwhelmed, don’t stress. Get in touch with our experts and they will be here to ensure absolute clarity for all your doubts and queries.
