XBRL can have some major upsides with regards of automatically analyzing a lot of financial data. It can make quite a difference in the perspectives of analytic speed and precision. But just as with all business intelligence, data quality is key. We all know the saying “garbage in is garbage out”. So how do we ensure data quality from the very start?
A year from now, the creation of the annual report for listed companies will be very different from now when the XBRL dimension is added to the work. More and more companies are getting prepared for this big change by partnering up with companies specialized in the creation of iXBRL files. That’s good, because you can’t start soon enough if you want to deliver a quality report.
But even when you partnered up with an XBRL vendor, there is still a question of how the XBRL file is actually made. All the figures need to be mapped to their XBRL counterparts and extensions to the taxonomy have to be made.
This doesn’t sound to difficult maybe, because most providers have lists where you can find all the possible elements you can use. Simply find the element where the name matches the most with your own label. And if you can’t find the proper elements, you can always create your own.
We need to be careful though, because mistakes are easily made this way. Sometimes the label seems to match with an element based on the name, but the meaning of the element differs from the meaning of the number in the annual report. It can also happen that it seems like there is no element that matches at all, but when looking closer to the meaning of the elements, there is a suitable one which just has an entirely different name.
Matching the right element to a figure isn’t the only hurdle. Elements also carry certain properties, like scale, balance, sign and type. Using the wrong values for these properties can have a major impact. Using a scaling of 3 instead of -3 can make your figures seem a thousand times lower, without seeing a major difference in the report. Even the taxonomy validation is not going to help here, since the numbers probably add up.
Interpreting the balance property the wrong way can cause your report to have negative values where they should be positive, or the other way around. Again, it doesn’t show in the readable part of the file, but the automatic interpretation of a computer will be very different. We can only imagine the impact when at some point these XBRL files are used by algorithms on the stock exchange and someone makes an error like this.
The whole idea of using XBRL in the first place, is to be able to easily analyze financial reports, without having to interpret everything based on the context. This allows for automatic processing and the ability to analyze and compare thousands of reports with each other.
Comparing reports can only work if there is some kind of standard. This means that in an ideal world, all the figures are standardized and there is no need for extensions. The more extensions are used in a report, the harder it gets to automatically compare it with other reports.
In conclusion it seems that tagging a file isn’t that difficult, but tagging it properly is a lot harder and requires knowledge about the taxonomy and about the industry. If a file isn’t tagged properly, it might still be valid and an auditor could still approve the file, but the quality for analytics can be very poor. Right now we are heading towards the first XBRL reports for listed companies and it can be easy to only focus on the regulations and don’t think about proper tagging. I think however that we should focus on both, because the whole point of XBRL is that we soon want to start analyzing all the data we gathered and we don’t want have to ignore the data from the first years because of poor data quality.
We have decided to take the step towards iXBRL, so we might as well embrace take our advantage from it and don’t do it half-baked.