Can Your Validated XBRL Report have Incorrect Data?

by Shilpa Dhobale | July 25, 2016

Quality XBRL Filing, Beyond Validation Checks

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 of 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 contextswrong 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 ‘Number of Shares Outstanding’. Number of shares outstanding basically refer 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 Stockholders Equity.

Here is a screenshot from the filer’s HTML file for both the documents:

Extract of Company's 10Q XBRL fle of SEC
Figure 1 – Extract of Balance Sheet from Company’s 10Q HTML

Extract of Stockholder's Equity from Company's 10Q SEC filing
Figure 2 – Extract of Stockholder’s Equity from Company’s 10Q HTML

Both these statements show that the number of shares outstanding as on 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.

Snapshot of Balance Sheet for Stocks as shown in XBRL
Figure 3 – Snapshot of Balance sheet as shown in the XBRL instance.

So while the HTML suggests that the numbers 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 that’s 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.

{C}{C}{C}{C}{C}{C}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 4 – Snapshot of Stockholder’s Equity as shown in the XBRL rendering of SEC

Here the value for 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 modelled to use the same element and dimensional contexts in both the balance sheet as well as the stockholders 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 modelling patterns. The equity disclosure in the balance sheet and in stockholder’s equity is a classic example, where the modelling 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 modelling approaches as well. But that’s 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 shilpa.dhobale@irisbusiness.com.