While several European countries successfully adopted XBRL for financial statements, a new version is already lingering on the horizon.
From reporting year 2020, stock exchange companies within the European Union are required to report their financial statements using the ESEF XBRL taxonomy. Instead of creating regular XBRL files, they will have to use “Inline XBRL” or iXBRL.
The i makes only a small difference in the name of the format, but it has quite some impact in the way reports have to be generated.
First a short explanation of the format. IXBRL is created to combine data analysis and visual presentation of financial statements. Where you needed two different files in the past (e.g. PDF and XBRL), you can use an iXBRL file to do both. It is both readable for a human and a machine. The general format is similar to html, where webpages are built in. The XBRL data is inserted into the html code. Hence the name “inline XBRL”.
The XBRL code in iXBRL is somewhat different compared to the normal XBRL code. This is because the focus has shifted a bit towards visual representation. This means that the iXBRL code needs to include properties which determine how the data is presented. Do you want to use decimal comma’s or decimal points? And do you want to say “1 Million” or “1.000.000”? Those kind of questions are answered by iXBRL properties that are not available in regular XBRL.
With general XBRL, the creation of the visual financial statement (such as a PDF) is separated from the creation of the XBRL file. The processes don’t depend on each other that much. Our experience is that the focus is lying on creating the PDF and afterwards the XBRL is created based on that. This makes an easy process, where less people are involved at the same time.
This could result in two documents with different content; the balance sheet in the XBRL file could be different from the PDF, because it had to be changed due to for instance XBRL validation rules, or certain financial figures need to be separated into smaller XBRL elements or the other way around.
In iXBRL, you only create one document. This means that the designing- and financial department have to take XBRL into account during the creation of the initial report and this requires XBRL knowledge. They need to know which XBRL elements exist to make sure that the data in the report is coherent with the XBRL framework of elements and dimensions. It can be hard to maintain this knowledge, since XBRL evolves over time and the framework of most taxonomies are quite extensive.
Multiple large companies are already looking for ways to integrate XBRL into their workflow, to make sure everything runs smoothly once iXBRL becomes mandatory. If they already use a CMS, the easiest way would be that the CMS provider includes all necessary XBRL intelligence in that application. When the report is designed in for instance inDesign, or directly created with HTML, a good solution would be to team up with a company that specializes in XBRL. They can combine the data and the design and convert that into an iXBRL document.
Alex de Jong is a partner in ParsePort Netherlands
Have you already made your ESEF preparations? If not, then this article will give you 10 actionable tips to improve your preparations.
Danish companies like Novozymes are already carrying out dual taxonomy reporting in iXBRL, are you ready for dual taxonomy reporting?
The Importance of Reporting Design when Converting to ESEF Wrong fonts, misaligned amounts, low quality
3 Different Ways to Handle Your ESEF Mapping There are many different ways to handle
An easier way to encourage investors to spend their money, an easier way to compare your reports against the market, a heightened quality of data. If you ever wondered what your company will gain from the new ESEF format, you’ll find the answer in this article.
