A Calculated Risk

A detailed investigation into the complexities and limitations of XBRL Calculations
by: Shawn Rush, CompSci Resources, LLC

Note that this overall scenario could apply to differences in context due to dates as well. For example, if the second table showed a Consolidated column for a date range different than the one reported in the income statement, then we would encounter a similar calculation inconsistency for the Consolidated column.

This type of scenario is one of the main causes of confusion regarding the validity of an XBRL submission. Many validation tools will understandably flag this scenario as a calculation inconsistency even though the filer is following the SEC's instructions and has created the calculation properly. Because validation tools have not been able to differentiate between this scenario and a real calculation error, there is a general misconception that XBRL data contains more calculation errors than actually exist. Addressing this issue will be critical to the overall effort of increasing the consumption of XBRL data.

Negation Abuse

The final issue discussed here deals with applying negated label roles incorrectly to force valid calculations while still having the rendered value match the value in the HTML. Consider the following table and calculation:

Revenues - OperatingExpenses = OperatingIncomeLoss

Note that "Operating Expenses" is expressed as a positive number. Sometimes in the HTML, filers may want to express this with parentheses so that the line items can all be summed. In this case, the proper structure would be as follows:

Note that fact value of 6,000 in both examples is the same, but in the second example, we have applied the Negated label role so that a negative value is rendered to match the HTML. The calculation above still works for this setup as the fact values did not change.

Now consider the following:

From a rendering perspective, this table matches the previous one, but the stored XBRL values are the complete opposite in sign. This is an error because the intention is to report positive revenues and expenses, but instead negative values were reported. Unfortunately, this could easily be missed because the rendering appears correct, and the calculation is still valid with all negative numbers.

Filers should be very careful to avoid this mistake by ensuring the reported value matches the intention of the concept. This requires filers to have a clear understanding of the concepts used and not to change the signs of fact values for the sole purpose of making calculations work.

Previous  Table of Contents | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | pdf   Next