Few individuals in the eXtensible Business Reporting Language (XBRL) community would disagree that calculations are one of the more confusing and frustrating aspects of the specification. In theory, calculations should be fairly straightforward. All the numbers on the financial statements should add up to the stated totals, but as we know the devil is in the details. Hopefully we can shed some light on those details by reviewing not only the basics of creating calculations, but also certain scenarios that are either tricky or downright impossible given the current limitations of the specification.
The headline and subheader tells us what you're offering, and the form header closes the deal. Over here you can explain why your offer is so great it's worth filling out a form for.
Note that "xlink:to" denotes the operand whereas "xlink:from" denotes the total. The other important item to look at is the "weight" value. While the XBRL specification allows any numeric here, the U.S. Securities and Exchange Commission (SEC) only allows values of either  or [-1]. Weight determines whether we are adding or subtracting the operand. Hence, the above XBRL is expressed in a human-readable format by the following equation:
Liabilities + StockholdersEquity = LiabilitiesAndStockholdersEquity
Note that only concepts are specified in a calculation. Fact values, contexts (which carry date and dimension information), and presentation links (tables or sections) are not specified when creating the calculation. The calculation applies to a set of facts for a given context if (a) a fact exists for the total concept with the given context and (b) another fact exists for at least one of the operand concepts with the given context. Again, context specifies the dates and dimensions for a given fact value.
Let's take a look at how this applies if we have the following data:
|Total shareholders' equity||120||90||N/A||80||70||Stockholders' Equity|
Total liabilities and shareholders' equity
|230||190||180||N/A||160||Liabilities and Stockholders' Equity|
Given the scenario above, the table below shows how the calculation is applied to the data:
|Context||Liabilities||StakeholdersEquity||Liabilities & Stakeholders Equity||Does Calculations Apply?|
|2017||N/A||+||N/A||=||180||No (needs at least 1 operand)|
|2016||N/A||+||80||=||N/A||No (needs total fact)|
|2015||N/A||+||70||=||160||Yes (but Invalid)|
With this we must remember that the calculations are applied to facts grouped solely by context and not by financial statement or presentation link. This means that a single calculation can apply to multiple presentation links if those links contain concepts that exist in the calculation. We will discuss some of the issues with this later.
A concept's balance type also plays a significant role in calculations. A concept could have a balance type of debit, credit, or none. This is relevant because the balance type of the total concept determines whether the operands can be added or subtracted.
If this sounds confusing to you, then you're not alone. We'll use the previous calculation to shed some light.
|Operand 2||+||Stockholders' Equity||Debit|
|Total||Liabilities and Stockholders' Equity||Debit|
Because "LiabilitiesAndStockholdersEquity" has a balance type of debit and is the total, debit concepts can only be added and credit concepts can only be subtracted. Likewise, if the total were to have a balance type of credit, credit concepts can only be added and debit concepts can only be subtracted. Note that if a total does not have a balance type, then credit concepts and debit concepts can be either added or subtracted. Similarly, if an operand concept has no balance type, it can be either subtracted or added regardless of the balance type of the total.
In the actual calculation in the XBRL, the addition or subtraction of a concept is denoted by a calculation weight of either  or [-1], respectively. Note, however, that this rule regarding balance types and valid calculations weights does not put any restriction on whether the fact value itself is positive or negative. Rules regarding the sign of a fact value are inherent to the concept definition and are not determined by the balance type. For example, "ProfitLoss" can be either positive or negative, but "CommonStockSharesOutstanding" cannot be negative. This is important to remember as one could incorrectly adjust the sign of a fact value to overcome calculation weight restrictions based on balance type. Such action makes the calculation "work", but renders the data meaningless. We will show an example of
The following are valid calculations based on balance type:
|Operand 1||Operand 2||Total|
|+||Credit||+||Debit||=||No Balance Type|
|+||Credit||-||No Balance Type||=||Credit|
The following are invalid calculations based on balance type:
|Operand 1||Operand 2||Total||Reason Invalid|
|+||Credit||-||Credit||=||Credit||Operand 2 weight must be +|
|+||Credit||+||Debit||=||Credit||Operand 2 weight must be -|
|+||Debit||-||Debit||=||Debit||Operand 2 weight must be +|
|+||Debit||-||Debit||=||Credit||Operand 1 weight must be -|
|-||Credit||+||Credit||=||Debit||Operand 2 weight must be -|
|-||Credit||-||No Balance Type||=||Credit||Operand 1 weight must be +|
Finally, a concept's period type plays a role in how we can set up calculations. A single calculation can only contain concepts of the same period type. This means instants can only add up to instants and durations can only add up to durations.
One of the more noticeable limitations of the calculation specification is its restriction on mixing concepts of different period types in a single calculation. This limitation becomes obvious in the inability to specify a calculation in the stockholder's equity statement. The general structure of an equity table shows the stockholder's equity at a given point in time (instant) followed by changes over the course of some period of time (duration) whether it be a year or a quarter followed by the new balance (instant).
|Balance as of 12/31/2018||100||Instant|
|Other Comprehensive Income||20||Duration|
|Balance as of 12/31/2019||150||Instant|
Despite the calculation being obvious in the table, we are unable to model it using XBRL calculations.
Basic Accounting Equation
The basic accounting equation using XBRL concepts is as follows:
Liabilities + StockholdersEquity = Assets
Unfortunately, this simple equation cannot be modeled with XBRL calculations because of balance type restrictions. Given that "Assets" is a debit and "Liabilities" and "StockholdersEquity" are both credits, there is no way to write this equation in XBRL with the proper calculation weights. In the equation above, either "Assets" or both "Liabilities" and "StockholdersEquity" would have to have a negative sign. Neither scenario makes sense so this important calculation cannot be included in the calculation linkbase.
One of the most common issues filers encounter deals with creating a calculation for a set of concepts for one table and context and the calculation inadvertently applying to a very similar but different set of concepts for a different context. Consider the following subsection of an income statement:
|Operating income loss||4,000||Credit|
From this we have the following calculation:
Revenues - OperatingExpenses = OperatingIncomeLoss
Now let's consider a table in the notes that breaks down expenses based on industry segments
|Direct costs of owned hotels||1,000||0||1,000||Debit|
|General and administrative expense||1,500||1,500||3,000||Debit|
|Operating income loss||5,500||(1,500)||4,000||Credit|
In this table, the Hotels and Corporate columns would be tagged with separate Business Segment dimensions, whereas the Consolidated column would be dimensionless since it is the aggregate. The amounts 10,000 and 4,000 in the Consolidated column would already have been tagged from the income statement.
The issue here arises when we now try to apply the calculation from the first table to the facts in the second table. Remember when applying calculations, we do so by context which means the calculation from the first table gets applied to each of the three columns of the second table. When we try to apply the calculation to the first two columns, there is no "OperatingExpenses" fact for either of those contexts. This causes the calculation to be applied as follows:
Revenues = OperatingIncomeLoss
This is obviously wrong and will flag a calculation inconsistency for those first two columns or contexts. In these circumstances, the SEC requires that the calculation for the income statement be included as it is valid when applied to the "Required Context". The "Required Context" is the main dimensionless context of the document whose dates match the reporting period of the filing.
One thing to remember is that the calculation will apply correctly to the Consolidated column. The facts for "Revenues" and "OperatingIncomeLoss" in this column are the exact same facts as those in the income statement as they share the same dimensionless context. This means the application of the calculation to the Consolidated column is one and the same as the application of the calculation to the income statement.
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.