Imagine you are shopping online and at checkout, you are prompted to fill in your delivery address and billing address. If both are the same, wouldn’t 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 let’s apply this scenario to the world of any XBRL report.
Duplicate Facts in an XBRL Report
A financial report displays the 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 the property on the Balance Sheet as $1,000 million. At the same time, the value is reported as $1 billion in the notes to the financial statement.
How then should this be reflected in the digital report or database or any application: as one record or two distinct ones? Isn’t 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 of $1000 million as well as $1 billion are stored as 1000000000 while other corresponding metadata takes care of visible aspects like the 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.
But considering this is a common issue, XBRL International has provided guidance to filers on how to handle duplicate facts in XBRL. The note suggests that duplicates should be avoided.
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!
Shouldn’t 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 the property will not be evaluated for calculation correctness. This means that even genuine errors if any could go unnoticed.
When it comes to the quality of the data in a report, the onus ultimately lies with the company. And it’s 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 SEC too is digging deep into XBRL reports and is taking steps to ensure data quality.
The world is talking about using XBRL data for some amazing purposes and such imprudent errors at the filer’s 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 isn’t helping you with this, feel free to reach out to us and we’ll show you how to create a clean and uncluttered XBRL Report.
