by Shilpa Dhobale | May 16, 2016
Imagine you are shopping online and at checkout, you are prompted to fill your delivery address and billing address. If both are the same, wouldnt you be delighted if you are given an option to enter the address only once? Should the database of the online shopping store save the same address twice as two different records? Obviously not. Now lets apply this scenario to the world of any XBRL report.
Duplicate Facts in an XBRL Report
A financial report displays same concepts repeatedly across the report to establish a correlation between various items. And while the occurrences might differ in scale, the underlying value remains the same. For e.g., Company A shows the value of property in the Balance Sheet as $1,000 million. At the same time, the value is reported as $1 billion in the notes to financial statement.
How then should this be reflected in the digital report or database or any application: as one record or two distinct ones? Isnt it logical to consider this as one unique record? Financial reports are full of such scenarios and if everything starts getting stored as duplicates, it becomes difficult for any application to read the data correctly.
This traditional reporting fallacy is well addressed in an XBRL report. An XBRL report stores numbers in their native format i.e. without applying any scale for rounding off. So both values $1000 million as well as $1 billion are stored as 1000000000 while other corresponding metadata take care of visible aspects like scale of rounding off. This fundamental principle of XBRL eliminates the need to store all variations of the same number as different records in the XBRL report.
As of now though, XBRL does not restrict users from recording duplicate facts.
Avoiding Duplicate Facts: Who is Accountable?
Our analysis of SEC filings suggests that a number of companies have submitted duplicate facts in their XBRL reports across the years. What is even more interesting is that all these filings over the years have been created using the same software application!
Shouldnt this simple task of checking duplicate values across the report be taken care of by the software? Business users have more important things to do and such checks can be easily handled at the software level.
Your Data, Your Responsibility
Duplicate Facts not only clutter the report and violate the XII guidance but also result in calculation validations being skipped. The arithmetic correctness of an XBRL report with duplicate facts is always at risk. Going back to my previous example, both the balance sheet and the note section for property will not be evaluated for calculation correctness. This means that even genuine errors, if any, could go unnoticed.
When it comes to quality of the data in a report, the onus ultimately lies with the company. And its a high price to pay. Companies filing low quality reports with duplicate facts run the risk of passing on the poor quality to regulators and ultimately to all the data consumers who rely on XBRL to provide clean, quality data.
The world is talking about using XBRL data for some amazing purposes and such imprudent errors at the filers end will definitely impact data consumption.
As I mentioned earlier, such sanity checks can very well be handled by software applications. If your XBRL software isnt helping you with this, feel free to reach out to us and well show you how to create a clean and uncluttered XBRL Report.