XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

Continuing on with my analysis of the first set of 408 SEC XBRL filings, here I will summarize what I saw when I looked at XBRL calculations relating to those filings. This web pagepoints provides a summary of these results and a viewer which lets you look at the results of checking these XBRL instances against the calculation relations provided by the filer.

Of the 408 filings, every one provided a set of calculation relations.
Of the 408 filings, 302 had no calculation inconsistencies. (Actually, in the validator I was using 285 had no inconsistencies and 18 had a reported inconsistency relating to an inferred precision issue being addressed by the XBRL specifications working group. This was deemed not to be a calculation inconsistency.)
That left 106 with calculation inconsistencies reported. Of those: 12 filers had only one inconsistency; 38 filers had two inconsistencies (usually the same issue in two periods); 8 filers had 3 inconsistencies; 18 filers had 4 inconsistencies, and 49 filers had more than 5 inconsistencies.
The maximum number of inconsistencies was 34.

You can get a PDF or an Excel spreadsheet with this information from that summary page.

On the report the generator software used for creating the filing is provided, this comes from XBRL Cloud (as does the list of filings).

So, an obvious question was WHY the inconsistencies existed and where the inconsistencies were within the XBRL instance.

As to where, this is the breakdown:

Various: This means that the inconsistencies related to a number of different areas. There were 29 of these which inconsistencies impacted multiple areas. Here is an example.
Stray calculations: There were 2 of these. What this means is that calculations were being fired because of concepts provided by the XBRL instance. The network did not have a full set of concepts. This needs more analysis to see exactly why this is occurring, usually this relates to problems in constructing the XBRL taxonomy. Here is an example.
Income statement: There were 9 relating to the income statement.
Balance sheet: There were 22 relating to the balance sheet. This is a little surprising, the balance sheet is generally pretty easy because all the concepts have a balance attribute (i.e. debit or credit).
Cash flow statement: There were 28 which had cash flow statement inconsistencies. Generally, these look like polarity issues. This is where the filer entered a positive number but should have entered a negative number (or the other way around). This is usually because the preparer is obsessed with presentation of the number and does not seem to understand that for comparability reasons one way needed to be agreed on.
Changes in equity: There were 2 of these. Frankly I would have expected more.
EPS: There were 12 relating to EPS (earnings per share for you non-accountants) not footing. Now this is interesting. Seems like this should definitely foot. Not sure what the deal is. But, it this is NOT supposed to foot, then why are the calculation relations provided?

It has been my observation over the years, and I see nothing which changes this in the calculation validation results that I see, that if a filer cannot get to the point where they cannot get rid of all the calculation inconsistencies it is typically because the filer refuses to grasp how XBRL works. Basically, if the XBRL taxonomy says things should add up, then they should add up. If things are not supposed to add up, then don't put the calculation relations in the taxonomy. That is pretty straight forward. Presentation of the numbers in a rendering for humans is a totally separate issue and has absolutely nothing to do with calculations.

In general what I see is pretty encouraging. For 302 filers to get this right in the first filing period with the SEC not even checking these calculation relations is pretty favorable. Add the 76 who had less than 5 inconstencies which were very similar issues, that brings the total to 378, which is 92 percent of the total.

Here is a PDF which walks you through a few calculations inconsistencies and shows you how to compare the calculation report with the SEC rendering.

If you look at the consistency by generator you see that every generator application both has filings with inconsistencies and without inconsistencies.

In order for automated reuse of the XBRL information provided by the SEC EDGAR system, clearly the data cannot have calculation errors of any sort. XBRL calculations are not sufficient to prove that all computations in an XBRL instance work correctly, see the discussion of business rules in other posts on my blog such as this one.

I am pretty confident that accountants who create XBRL filings will eventually realize that they have a gold mine here in XBRL, rather than just yet another SEC rule that they need to comply with. Pressing one button to make sure that everything adds up, rather then have to put on those green eye shades! What is not to like about that. Further, using business rules to automate the disclosure checklists used to create a financial statement. These are not liabilities folks, they are assets. Pretty soon software will exist which shows this to be the case. Then it will be much easier for business users to understand why XBRL is so useful for not only external reporting, but more importantly for internal reporting.