by Anuradha | October 3, 2016
With companies going global and looking to expand in an ever-changing economic scenario, business reporting has taken on a completely new form. It is no longer about merely communicating to the regulator about the companys performance, but has expanded to cover every aspect of business communication whether it is to the investors, stakeholders or regulators.
Through all this, the financial reports filed with the regulator every quarter continues to remain the primary mode of communicating performance. In 2009, the US Securities and Exchange Commission (SEC) mandated XBRL filing along with the HTML format, in an attempt to make electronic data available to users of information for analysis etc. While HTML provided easy readability, XBRL took care of standardization, comparability and easy extraction of data from filed reports.
In essence, both the formats were meant to carry the same data, but was that really achieved?
The SEC requires every number in the financial statements and footnotes to be tagged in XBRL format. In my 7 years of working with SEC XBRL filings, I have seen facts reported in an XBRL report range from an occasional 100 to sometimes even as high as 10,000. The underlying implication with XBRL filing is that the same facts need to be present in the HTML format as well. While this is the expectation, it certainly isnt the end state in many cases. With accountants rushing to meet deadlines, making last-minute changes and working on numerous versions of the report, it becomes tough to keep both formats in sync through the process.
Let me explain this with an example.
Here is an extract of the HTML format and the XBRL format (SEC rendering) of the 10-Q2 filing of Home Treasure Finders, Inc. (Filer) CIK: 0001527102.
Figure 1: Extract from HTML Report for Home Treasure Finders 10 Q2 2016 Filing
Figure 2: Extract from SEC XBRL Rendering for Home Treasure Finders 10Q2 2016
The company has correctly reported its financial information for the period June 30, 2016 in HTML but the XBRL shows values for June 30, 2015 instead. And this problem is not only in the financial statements but has been carried forward in the disclosure footnotes as well, indicating a compliance oversight. The dual reporting in XBRL and HTML formats has likely caused this issue.
Section 8.1 on page 115 of the XBRL Preparers Guide details out Managements Responsibilities and Review Objectives of XBRL documents, and clearly mentions that the accuracy and completeness of data being reported is the responsibility of the company management. Thus the ultimate onus of providing accurate data lies with the Chief Compliance Officer who is accountable for risk at the enterprise level.
Lets step back and examine the possible reasons that might have led to the data being out of sync in this particular example.
1. Process Lapses
This could have been a case of the company still following the traditional model of compliance reporting where XBRL and HTML documents are created separately and every number then is compared to ensure that the HTML and XBRL documents are in sync.
But if the company was using a software, its possible that it is not a single source software. A single source software is one which generates both the XBRL and HTML documents from a single source file, leaving no room for such an error.
All said and done, in this example, it is also evident that the reviewers of the document checked the accuracy of the HTML document only, completely missing out on comparing it with the XBRL version to look for consistency.
2. Technological Ambiguities
Sometimes, the issue can be with the software validation rules as well. In this case it clearly shows that the numbers in the XBRL have not been verified or perhaps validated. There are compliance applications that have smart features to identify facts in the document that require tagging. If the company was using such a platform, the probability of wrongly tagging facts or not tagging some facts at all, would have been much lower.
3. Lack of Awareness of the Reporting Technicalities
Apart from processes or technology, one more area leading to such errors is the lack of awareness around XBRL itself. Though the standard has been around for several years, XBRL has been treated more as a cost for compliance. Preparers and the reviewers of XBRL are not completely aware of XBRL reporting requirements and technical aspects such as assigning right dates, analyzing which period a fact belongs to, the use of negation, units, scales etc.
With IRIS CARBON®, you neednt worry about any of these problems. The cloud-based, collaborative disclosure management platform is a single-source application that ensures your HTML and XBRL documents are always in sync. With all the SEC required business validation rules in place, it helps you generate quality output and ensures that all mandatory items are captured. The platform is backed by an assisted services team with more than 9 years of experience in SEC filing to, guarantee only the best quality output with minimal effort and zero risk.
This is not to say that regulators are not aware of the data quality situation. While the SEC is penalizing those who are violating accounting laws, they are also thinking of ways to ensure data quality; setting up of the Data Quality Committee is one such initiative.
In July 2016, the SEC also approved voluntary filing by companies in inline XBRL (iXBRL). Inline XBRL provides an HTML layer to your XBRL data and takes away the pain of preparing reports in two formats. The inline XBRL format helps filers prepare easily readable reports that are machine readable and available for analysis as well. Read here to know more about inline XBRL and inline XBRL tagging rules. It only remains to be seen as to how many companies take advantage of inline XBRL filing.
If you are interested in filing in inline XBRL or have any queries, please write to me at firstname.lastname@example.org