The Impact of The Letter "i"

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.