The ESEF RTS – (EU) 2018/815 [1] – stipulates that:
(2) Issuers should prepare their entire annual financial reports in the Extensible Hypertext Markup Language (XHTML) format…
(4) …consolidated financial statements in annual financial reports prepared either in accordance with IFRS adopted pursuant to Regulation (EC) No 1606/2002 or with IFRS as issued by the IASB (both are in the following referred to as IFRS consolidated financial statements) should be marked up using eXtensible Business Reporting Language (XBRL)
The wording of these requirements has caused some understandable confusion over exactly what the format requirements are. Are filers expected to produce two versions of the document – one in XHTML and one in iXBRL? Certainly, this extract from the RTS presents two separate requirements: to use the XHTML format, and to include iXBRL tags.
This separation is reinforced in other material from ESMA[2]:
- All AFRs shall be prepared in XHMTL, which is human readable and can be opened with any standard web browsers;
- Where AFRs contains IFRS consolidated financial statements, these shall be labelled the XBRL ‘tags’, which make the labelled disclosures structured and machine-readable;
However, this would seem to run counter to ESMA’s overall objective of consolidating on a “Single Electronic Format”, and ESEF solutions are focusing on iXBRL, so it is worth a closer look.
What are XHTML and iXBRL?
XHTML is a format for human readable documents. When you visit a website in your browser, it is displaying an XHTML document to you. Of course you may not normally think of this XHTML as documents or files, although if you were so inclined, you could save them to your hard drive and open them in your web browser; much like opening a .docx file in Microsoft Word.
XHTML can therefore be used for human readable annual financial report content:
XHTML is a widely supported, easy to process format and is therefore a good choice for such content. However, it does nothing to provide machine readable content data. A human reader can easily ascribe meaning to content from the context (“Example Company” is the company name, “£1,000,000” is the revenue), but a machine cannot easily or reliably do so.
Plain (non-inline) XBRL provides this machine-readable data, and only that. It is not a human-readable document, so XBRL-aware tools must be used to render the data as required:
ESMA could have required one document for human consumption and another for machine consumption (and indeed this is what the SEC did for many years, since the EDGAR XBRL programme predates the invention of iXBRL).
iXBRL provides a better solution since it combines these two documents into one. How?
iXBRL is a way to embed machine-readable XBRL tags within an XHTML document so that the resulting document is both human and machine readable. An iXBRL document is an XHTML document, with some extras thrown in.
One of iXBRL’s key strengths derives from how these tags are embedded. Rather than duplicating values for human and machine consumption, machine readable values are identified within the human readable content:
It not only meets the requirements for human readable and machine readable data, but it does so using a single representation of that data. By avoiding duplication, it removes a significant potential source of discrepancies, and that makes it a much more robust solution than a combined XHTML and XBRL submission (as a result, the SEC have migrated to iXBRL for their EDGAR programme).
The resulting iXBRL file can still be treated as an XHTML file and shown in a standard web browser exactly as before. It can also be processed as an XBRL file. Finally, iXBRL-aware software can present an augmented rendering that makes the tagged data visible to human reviewers:
So what does this mean for ESEF filers?
Now that we have covered the relationship between iXBRL and XHTML it is easier to decipher the requirements.
Filers who follow the second requirement (iXBRL) will, in doing so, meet the first (XHTML). The only way to include iXBRL tags in accordance with the specifications produces a single document that is valid iXBRL and therefore valid XHTML.
The reason for the separation of requirements is that not all filers will be using IFRS (some will use local GAAP), and so ESMA’s iXBRL requirement does not apply. These filers will still have to prepare their submission in XHTML format. In practice, some jurisdictions may choose to require iXBRL for local GAAP too, and this is of course compatible with ESMA’s requirement for XHTML.
Conclusion
- ESMA requires a single submission from each filer
- That submission is always required to be valid XHTML, even where local GAAP is used
- In most cases (where IFRS is used), that submission is required to be iXBRL
- A valid iXBRL submission is also a valid XHTML submission
References
- [1] ESEF RTS – (EU) 2018/815
- [2] https://www.esma.europa.eu/policy-activities/corporate-disclosure/european-single-electronic-format