I'm old enough to remember logging onto the internet using a telephone line dial-up, eagerly awaiting its distinct audible tone to indicate a successful connection. Only to then click-and-wait for each page to drag its way from the host server to my screen at an approximate rate of 56 kilobytes per second. Having reviewed many of the ESEF reports completed this year I could have been forgiven for thinking I had been transported back to the 90s as I waited for the XHTML YE21 Annual Financial Reports to load!

Nowadays our expectations are that online information will be almost instantaneous and the slightest delay has the potential to result in elevated blood pressure. So when the ESEF requirements specified that AFRs must be entirely prepared in XHTML, one might reasonably expect to soon be revelling in supercharged digital reporting. Alas not so. While warnings went unheeded, opportunities went missed. It would seem that the digital revolution bypassed financial reporting altogether or perhaps we deflected it away in favour of more familiar processes.

So what went amiss? For those involved, the preparation of ESEF brought various challenges and I expect little joy. And for those charged with leading the evolution to iXBRL reporting, the apparent compliance may also have brought little comfort. It would appear we were all blissfully unaware that XBRL is the international standard for digital reporting as we continued to follow a design-for-PDF-for-print process. But if we have learned any lessons from the exercise we have all just been party to, surely all parties now need to review and reassess their response to the ESEF requirements for the betterment of reporting standards.

The scope within ESMA's ESEF creates great potential through the combination of XHTML, the human-readable language, with XBRL, the machine-readable language. And the little 'i' that prefixes the latter is the inline bit that allows both to coexist. Native iXBRL/XHTML can deliver super-fast, supercharged digital reporting. Yet it is extraordinary that in most if not all cases, the ESEF requirements have not been achieved through native code but through PDF-to-HTML conversion tools with questionable effectiveness. With bodies such as the FRC and XBRL.org regularly describing PDF-to-HTML conversion software as 'extremely inefficient', why did their warnings consistently go unheard? As many technology solutions providers proclaimed theirs to be the Holy Grail of iXBRL simplicity through the wonders of their PDF-to-HTML convertors, the ugly truth is that in many instances it simply produced ugly code. It would appear we were all happily complicit in our collective denial as we buried our heads in the sand resulting in, now well documented, poorly constructed code that in many instances ultimately fudged the ESEF technical validation process.

Establishing more ambitious objectives while developing new processes will ultimately achieve a more effective and efficient baseline for iXBRL reporting. More purposeful engagement and collaboration is needed from the regulators, preparers, issuers, auditors and designers to bring about a more meaningful response to meet the ESEF requirements. Ultimately, we believe this can be achieved by following the XBRL Working Group recommendation where it states: Preparers should: Consider a report creation process that targets iXBRL/HTML natively, rather than converting a PDF output.

Undoubtedly ESEF has presented a challenge to a tried-and-tested methodology of preparing, designing and auditing reports. However our collective focus should now be to harness the benefits of HTML for both human and machine readability. Obviously a PDF is in itself a digital file, arguably however it is not necessarily designed for the medium in which it will primarily be consumed. More importantly it is no where near as effective as HTML when it comes to accessibility, responsiveness and performance. But for all those with a vested interest in the delivery of an ESEF-compliant AFR, it would appear that the same old design-for-PDF-for-print process has provided a convenient work-around to the challenge of developing and perhaps more importantly, auditing native iXBRL/XHTML code.

These issues have been well documented throughout 2021 based on voluntary filings, and into 2022 based on mandatory filings. Among these, the following extracts clearly highlight these issues.

Inline XBRL Rendering Performance 1.0 - Working Group Note 27 October 2021

Performance

Some filings in this repository can be slow to open in a browser. This is typically because the Inline XBRL report has been created using automated PDF-to-HTML conversion software. Such software produces a document which faithfully reproduces the appearance of a PDF document, but the resulting HTML is often extremely inefficient, leading to large file sizes and slow rendering times. We expect this to improve over time, as software improves, and preparers start to target the Inline XBRL format directly, rather than converting from PDF [emphasis ours].

***

(https://www.xbrl.org/WGN/ixbrl-rendering-performance-wgn/WGN-2021-10-27/ixbrl-rendering-performance-wgn-2021-10-27.html)

FRCLab Structured Reporting - DTR ESEF Study_October 2021

- As processes and technology mature over time, companies may seek to move to a fully designed structured report that replaces their PDF report.

- Many of these issues result from structured reports being based on PDFs that are not designed with XHTML conversion in mind.

***

https://www.xbrl.org/is-your-ixbrl-slow-to-load-heres-how-to-bring-it-up-to-speed/

Is your Inline XBRL slow to load? Better HTML can bring it up to speed

Posted on April 15, 2022

- Many ESEF software solutions work by converting PDF files into HTML, and this automated conversion process often produces HTML that is extremely inefficient.

- iXBRL makes financial reports more powerful, more interactive and easier to analyse, combining the benefits of computer-readable structured data with a human-readable presentation, but the usability of iXBRL reports can be hampered by inefficient HTML which can make them slow to use.

***

In the spirit of ESEF, the solution requires a shift in our collective approach to the reporting process and our grasp of digital reporting itself. Much has been made of the faithful reproduction of the 'glossy' PDF-to-HTML conversion without exploring the immense and measurable improvements that can be achieved through native digital reporting, both in terms of output and processes. As we look forward to the YE22 reporting season which will include the additional requirement of block-tagging the Notes to the Financial Statements, perhaps now is the time to give pause for consideration of how much better the standard of ESEF reporting can be. Producing native XHTML may be an uncomfortable proposition for some, but undoubtedly it is time that all of us with a material input to the reporting process embrace this opportunity for better and more transparent digital reporting. The objective should be to achieve the standard so that it is at the very least fit-for-purpose for all users and audiences.