Last month, the Financial Reporting Lab (from the FRC) published a report outlining the structured reporting of the European Single Electronic Format (ESEF). The Lab looked at 50 ESEF filings submitted this year, including both mandatory submissions in some countries who didn’t impose the one-year delay, and some voluntary submissions across the EU and the UK. Of the 50 reports, the FRC drew many trending concerns which ranged from tagging errors to the xHTML appearance. As a result, they have provided feedback and considerations that companies may want to adopt in the upcoming year.
The areas for consideration were split into 3 sections:
1. Process
2. Usability and Appearance
3. Tagging
1. Process
The FRC stressed the importance of understanding whether the company is in scope of the ESEF mandate and if so, what the requirements would be and when the company is required to comply to the mandate.
As a reminder:
All main market listed companies are required to publish their Annual Financial Report in xHTML, which (to some extent) will replace the current PDF format.
Issuers who prepare consolidated financial statements in IFRS are also required to tag their financial statements in iXBRL.
Although ESEF was originally set for annual reports with accounting periods that began on 1st January 2020, this was delayed by most European countries (including the UK and Ireland) by one year. For those jurisdictions that took advantage of the delay, the new mandatory requirement will be introduced for annual reports with accounting periods beginning on 1st January 2021. For annual reports with accounting periods beginning on 1st January 2022, ESEF will introduce block tagging of notes as well as the Primary Statements. The ESEF filing should be submitted to your OAM (in the UK this is the National Storage Mechanism) within four months of the company’s accounting end period.
When it comes to choosing a solution for ESEF, there are two main options. The first option is to acquire and implement an iXBRL tagging technology in-house. If that does not suit, you will outsource the process to a third-party iXBRL tagging provider. Choosing between these options will depend on a business’s individual needs in terms of budget, resources, and existing processes. To ensure a successful submission, the company should be aware of each part of the ESEF process and its timings.
The FRC has also highlighted the importance of doing a test run. The best way to do this is to tag and convert your previous year’s Annual Financial Report. This gives you a chance to test the xHTML conversion, the tagging of the primary statements (tagging both ESEF taxonomy tags and extension tags), and test the validation checks for both warnings and errors. This test will not be wasted as tagging the previous year will provide the groundwork for the 2021 filing.
2. Usability and Appearance
It is important to note that your ESEF filing will be made public, and will be seen and used by investors, analysts, employees and more. This report will represent the company, so it is important that the xHTML is well-designed and of good quality. The FRC recommend that the same care is put into creating your xHTML report as you would with the PDF.
Common ESEF solutions involve converting your designed PDF to xHTML. This means design processes will remain mostly the same. Whilst many xHTML conversions can create a perfect replica of the PDF, there is always a chance of error. A few of these errors were mentioned by the Lab, including custom fonts and layered images. As many of these issues stem from the creation of the PDF, there are several recommendations to follow when creating a PDF for xHTML conversion. Therefore, it is important that the PDF is designed with xHTML conversion in mind.
Although (for those consolidated IFRS reports) the xHTML used for submission contains the iXBRL tags embedded into the background of the report, the tags themselves are not ‘human-readable’. For this reason, inline XBRL viewers are used to review the ESEF tags on an xHTML report. These inline viewers allow us to see the tagged data as well as the properties of the tags. The FRC encourages companies to publish a version of their xHTML with an inline XBRL viewer, this is in addition to the zip file that you submit to the FRC’s National Storage Mechanism. If you are using ARKK as your ESEF solution, we provide this xHTML with inline viewer as part of our review documents.
3. Tagging
When tagging the financial statements; taggers should always search the ESEF taxonomy for a suitable tag that represents the accounting meaning of the disclosure. An extension tag should only be created when no other element from the ESEF taxonomy has an accurate accounting meaning that will represent the disclosure and it is therefore inappropriate to use an ESEF taxonomy tag.
It will be up to the individual tagging the report to create an extension with all of its attributes; including the element name and label, balance type, period type, item type, and its anchor(s). As part of the creation of each extension, it is important that the extension tag links back to the ESEF Taxonomy. The ESEF taxonomy tag, or tags, with the closest accounting meaning to your extension tag is used as the ‘link’ - this is called an anchor.
Two common issues identified by the FRC in their study of the 50 reports relating to tags and extensions were:
1. Forcing ESEF tags - The FRC found that companies sometimes ‘shoehorn’ all their disclosures into the ESEF taxonomy to try and avoid extensions.
Taggers should make sure they have a better knowledge of the taxonomy and its elements, (tags, axis, members etc.), so they can avoid such mistakes.
Understanding Sign Logic is a frequent problem for issuers with no prior iXBRL experience, and it is one of the most common errors found in XBRL reports. Even with the basics covered, signage can be made trickier after calculations are taken into consideration and the need to change weightings for the line items that have been defined with no balance type (debit or credit). The common reasons for calculation issues stem from the application of wrong SignLogic, and misunderstanding the use of balance types (pre-set, extended or lack thereof). Making sure your calculations are correct is important as they make up the 'Calculation Linkbase', which is created as part of an entity's extension taxonomy.
The ESMA reporting manual and the Conformance Suites (included with the ESEF taxonomy) contain validation checks that can either be classified as ‘Warnings’ or ‘Errors’. A big topic of discussion has been how ‘Errors’ and ‘Warnings’ should be handled. There is a major difference between these two types of validations, but many preparers mistakenly group them together as having the same meaning. Validation warnings are common and can often be ignored. Validation errors, however, are more serious and need to be addressed.
A ‘Warning’ can and should be interpreted as "Please double check and ensure this is what you want to report". A report can be perfectly valid but still have several warnings, in this case workarounds should not be used to circumvent the warning. An ‘Error’ on the other hand, will cause the ESEF filing to be invalid, and the specific Officially Appointed Mechanism should not accept them. The FRC mention the differences in their report and agree with this interpretation.
The aim of the FRC’s report is to support companies in their implementation of the ESEF requirements. Whilst the report is very insightful it’s only useful if everyone involved in the ESEF process familiarises themselves with the findings from beginning to end.