A Consistent Presentation of XBRL Instances
The EBA and the EIOPA have been accepting XBRL files for several years now for CRD IV and Solvency II reports. For authorities, XBRL is a giant leap forwards compared to Excel files, since XBRL can process data way more efficient than they ever could do with Excel.
However, with XBRL, the reporting entity can’t see what they report. For the one creating the report, the whole XBRL conversion is one big black box. Normally, they will rely on their input data and assume that the tooling converts their data exactly as it should.
This has some disadvantages. For instance, the CRD IV and Solvency II taxonomies contain duplicates. This means that while you may have only filled in a value at one table, it might appear in several other tables as well. This information is present in the XBRL file, but not in the source data. Next to that, it might be that the reporter doesn’t use the tool as intended and the tool converts the data in a different way than the reporter wanted to.
Present XBRL Files in a Readable Format
To prevent these kinds of things from happening, XBRL tools can present the created XBRL file in a readable format, such as html, Excel or PDF. This is possible, because most taxonomies contain a so called “presentation linkbase”, which contains information on how to show the XBRL data. This is used for instance to create the annotated templates in Excel. Proper XBRL tooling can use this information to present the XBRL file in a readable format.
There are some issues with this however. There is for instance no documentation on how to show the numbers. One thousand euro’s is saved as “1000” in the XBRL file and 95% is saved as “0.95”, give or take some decimal zeros. There are no percentage signs, no thousand separators and the decimal separator is always a point. A tool can add these things of course. It can easily be programmed that an item of a thousand is presented as “1.000“. But what if some is used to use the point as decimal separator? Without proper documentation a thousand in this case can easily be read as one with three decimals. This can also mean that different software providers from different countries show a different presentation of the same XBRL file, since every country can have different ways of presenting the same value.
Using iXBRL Instead
Then why not use iXBRL? That gives us the opportunity to add presentation properties in the file directly. In this case however, iXBRL seems the wrong way. That’s because the whole context of these files is about data processing in vast amounts, while iXBRL is really focused on presenting the data to people. For data processing, regular XBRL is more efficient. Also, the authorities will have to change their entire process to be able to process iXBRL files instead of regular XBRL.
The Dutch SBR team has tackled this by creating the “Consistent presentation”; a document that explains how a presentation of a Dutch GAAP XBRL file should look. In the above issue it says for instance that the presentation of monetary or numeric items should be based on the country of the language. An English presentation of the taxonomy therefore looks different from a Dutch presentation, but that is ok, since everyone can refer to the documentation. It also mentions for instance that unused elements must not be presented and that abstract elements can’t be shown. These kind of things are also relevant for CRD IV and Solvency II, since one can argue that the whole table, including abstract elements should be shown instead of only the used values.
I would propose to do the same for CRD IV and Solvency II XBRL files; we should create consistent presentation documentation to create a uniform standard throughout Europe, so that all software providers present XBRL files in the same way. Of course, styling can be different, but the content should be presented in the same, consistent way.