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.
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.