The SEC’s drive on data quality is going from strength to strength with each day. With a 64% drop in errors in XBRL filings in Q1 2016 compared to Q1 2015, it is already creating a positive buzz. The SEC’s initiative on data quality, the Data Quality Center (DQC) of XBRL US has now released the next set of Guidance and Validation Rules for public review. This is certainly a great development as the first set of rules has already shown remarkable results in terms of data validation and therefore accuracy.
But Does Validated XBRL Always Mean Accurate XBRL?
We have been working with SEC filings for the last 7 years and have built a repository of normalized XBRL data that can be used for analysis. But while doing this, we came across several scenarios where incorrect and inconsistent data was reported in the XBRL report. As a result, we applied all our experience to build several checks and balances that ensure stellar data quality.
Though XBRL has fared reasonably well in providing error-free data, there are still some areas that need to be addressed. While building our repository, we come across some typical examples of data inconsistencies such as selection of period type, use of inconsistent contexts, wrong signage, and tagging of duplicate facts. While some of these can be addressed with better validation rules and guidance on tagging, some others like incorrect contexts can slip under the radar unless the report is compared with a previous filing. Then there are some errors that can be squarely categorized as non-adherence to accounting logic and can be tackled to a large extent by having multiple rules and checks.
Accounting Logic: Going Beyond Mathematical Checks
While the base taxonomy supplied by the regulator will take care of a large majority of accounting rules, filers might still need additional checks to handle complex accounting relationships
To explain this, let me take an example of an XBRL filing we analyzed for the Number of Shares Outstanding. A number of shares outstanding basically refers to a company’s stock held by all its shareholders at a given point in time and is generally reported twice: once in the Balance Sheet and then in the Stockholder’s Equity.
Here is a screenshot from the filer’s HTML file for both the documents:
Figure Extract of Stockholder’s Equity from Company’s 10Q HTML
Both these statements show that the number of shares outstanding as of March 31, 2016, is 22,969,135 while the balance as of December 31, 2015, was 22,813,809.
Now let’s see how this has been represented in structured data i.e. the XBRL instance.
Figure Snapshot of the Balance sheet as shown in the XBRL instance.
So while the HTML suggests that the number of shares outstanding for December 31, 2015, is 22,813,809, the XBRL shows this number for March 2016 instead.
While earlier the taxonomy did not have rules defined for accounting logic, the recently introduced DQC rules do take care of this. Having said that, the DQC rules only check if the number of outstanding shares at a given point in time is less than or equal to the number of shares issued. And while the example above meets this condition, it still shows incorrect data.
Goes to prove that a validated XBRL file can clear the business rule defined (DQC_0009.15) and still be inaccurate. Interestingly, for prior filings of the same company, the number of outstanding shares was actually more than that of shares issued. Had the DQC rules been in place then, such errors could have been caught in time and addressed, but thats a whole different discussion.
Is there any way to catch this inconsistency?
So, is there a way to spot such errors? There is, if not fully, then at least to a large extent.
Taking the same example, the number of shares outstanding also appears under stockholder’s equity and is generally captured in the XBRL report using a different tag than the one used for the main balance sheet.
Figure Snapshot of Stockholder’s Equity as shown in the XBRL rendering of SEC
Here the value for an outstanding number of shares is reported correctly. If we had rules that cross-checked the data within the XBRL document itself, such inconsistencies could have easily come to notice.
For example, we could have a rule for the two tags used to define the same value in the two documents: Balance Sheet and Share Holders Equity
Rule: us-gaap_CommonStockSharesOutstanding = us-gaap_SharesOutstanding + us-gaap_CommonStockMember
This rule would have then established a relationship between:
- us-gaap_CommonStockSharesOutstanding, an element from the balance sheet, and
- us-gaap_SharesOutstanding which is dimensionally tagged using us-gaap_CommonStockMember, in the shareholder’s equity,
thus allowing data to be cross-validated.
Of course, there would need to be variations of such a rule depending on how many share classes existed and if the company was using extensions to report this data, but you get the point. Basically, building such rules can certainly help in identifying inconsistent values.
Accounting Logic Checks: Is Inline XBRL the Answer?
With the SEC moving towards inline XBRL, can we expect such issues to be resolved? The immediate answer is no.
Even though you may have prepared your inline XBRL report as per the inline XBRL tagging rules, it may not yield an accurate report. The HTML /human-readable view
will still show you all the values, even though they might be with incorrect tags. As filers, you need to continue to be careful about such errors, while preparing your
inline XBRL report. There is of course solace in the fact that the tags and numbers can be reviewed in the same inline XBRL document, reducing the scope for such
errors.
Addressing Accounting Checks: The Solution
The presence of two tags in the taxonomy for the same value may have resulted due to the move from the paper-based format to the XBRL one.
While such errors in the XBRL report might appear to be minor inconsistencies, they actually bring out a deeper question. If the same value is to be tagged at two different places, the taxonomy could have been modeled to use the same element and dimensional contexts in both the balance sheet as well as the stockholder’s equity. This problem would never arise in that case assuming that your XBRL application is able to differentiate between consistent and inconsistent duplicates.
Several taxonomies across the globe follow such varied modeling patterns. The equity disclosure in the balance sheet and in stockholder’s equity is a classic example, where the modeling has been done differently for the same information within a single taxonomy, forcing filers to provide the same value multiple times.
With innovative and forward-looking XBRL specifications such as table linkbase , formula linkbase and user-friendly formats such as inline XBRL, we might see changes in taxonomy modeling approaches as well. But thats something for the regulator.
For now, as a filer, you need to do a thorough quality check of your XBRL data till the time the DQC comes up with more rules.
Feel free to reach out to us should you need a report on the quality of your inline XBRL or XBRL document, or if you would like a free trial of the rich data set and analytics that we have built.
You can contact me at info@iriscarbon.com
