Managing the ESEF Mandate's Impact on Your Annual Financial Report

The European Single Electronic Format (ESEF) mandate, as directed by ESMA (European Securities and Markets Authority), is rapidly approaching. Accordingly, agencies of all kinds must be aware of how the mandate will impact them.

As explained by ESMA, issuers listed on regulated markets now must prepare their Annual Financial Reports (AFRs) in an ESEF from 1 Jan 2020, with the objectives of making submission easier for issuers and facilitating accessibility, analysis and comparability for investors and regulators.

While the general requirements of ESEF are clear—and have been well described by Liv Watson in this detailed post—one critical aspect has seen comparatively little emphasis. In this blog, I want to take a closer look at the use of XHTML (a more strictly formed version of HTML, a fundamental language behind webpages) as the format of the regulatory AFR.

As the AFR has become a glossy, design-centric document—one that some companies are using as a pivotal representation of their brand—what difference does the ESMA specification of XHTML make?

Why Annual Financial Reports should matter to reporting professionals

AFRs in Europe are often not prepared solely to fulfil regulatory requirements, they are also used as an important communication tool. Consequently, the AFR usually contains significant content beyond the financial statements, including extensive management reports.

To convey this message in an engaging way, graphic design is often emphasised. Graphic design plays an important role in the final product with the use of images, colour and data communication tools such as graphs and infographics. The AFR is also usually the document sent to print to fulfil demand for hard-copy information from investors and some government agencies.

Understandably, there has been a lot written about the Inline XBRL (iXBRL) tagging mandated for the ESEF, but the related requirement to use XHTML for the whole AFR has wider applicability.

The inclusion of iXBRL is only required for consolidated financial statements prepared using IFRS. However, the use of XHTML for the AFR applies to “all issuers whose securities are admitted to trading on a regulated market,” as described by the transparency directive, including those filing individual, rather than consolidated, financial statements.

In other words—while the iXBRL mandate has swept the headlines, XHTML will impact a larger swath of filers, and preparation is key.

The viability of standalone reports

Some see the requirement of XHTML as a sign that they should be looking to their websites for inspiration, but in many ways, the regulatory AFR remains a standalone report. This makes the XHTML requirement more like the PDF produced by most companies at the moment than the dynamic AFRs provided on websites.

In fact, some of the rules provided to support the ESEF require that filing is standalone, with no external references to resources (e.g., images, charts or tables) outside the filing package allowed. There are also rules designed to avoid the “potential threat” of executable code inside the report—as described by the ESEF Reporting Manual— so many of the dynamic features you are used to seeing on websites will not be supported. That, and the restriction on external content already mentioned, will also restrict the use of video.

Design nuances and variations

There are some design differences to bear in mind, and there are reasons that web design is considered a separate discipline than PDF design, but many PDF design elements can be replicated in XHTML.

As described in guidance 2.5.4 of the ESEF reporting manual, CSS, a common language describing the style and formatting of webpages, may be used to style the reports. Collectively, CSS and XHTML can replicate the majority of the design seen in PDF reports at the moment.

Images are also supported in AFRs, allowing for much of the current use of illustrative images and infographics to continue. However, do bear in mind that ESMA recommends that preparers do not embed images carrying financial information in the Inline XBRL document. The main design differences to consider are those related to pages and printing. After all, the PDF format was designed to take a document through to print; web technologies do not naturally produce the same high-quality, pixel-perfect results.

Largely, there is no need to look at this requirement as a major restriction, provided you already have the most efficient tools in place. It may also be an opportunity to look for process improvements in your organisation.

Re-evaluate your processes

Approaching the creation of an XHTML AFR in the same way as the creation of a traditional AFR will yield unnecessary, costly iteration between you and your design team. Using the process designed for the production of a PDF and bolting additional steps on the end to convert to XHTML (along with the required iXBRL) only adds time, complexity and cost to the process.

However, it doesn't have to be this way. By consolidating your processes onto Wdesk, you afford stakeholders inside and outside your organisation the opportunity to collaborate in unparallelled ways. Wdesk allows financial reporting professionals to export data in a format readable by commonly used graphic design software. As last-minute changes to data are made, changes to narrative and data can flow into design software without overriding the work established by design teams.

With the document preparation, tagging and design brought together, real efficiencies can be achieved, complexity is reduced and cost goes down.

For more information about improving financial reporting, read our recent blog post, entitled "Performance Reporting Checklist: 5 Questions for Finance Teams."