# A Calculated Risk

## Introduction

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.

## Basics

We'll start with the basics of how XBRL calculations work. Let's say we have the following on our
balance sheet:

 Label 2019 2018 XBRL Concept Total liabilities 110 100 Liabilities Total shareholders' equity 120 90 Stockholders' Equity Total liabilities and shareholders' equity 230 190 Liabilities and Stockholders' Equity

In our calculation linkbase, the XML tags for this calculation would look something like this:

<calculationArc
weight="1"
order="1"

<calculationArc
weight="1"
order="2"

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:

 Label 2019 2018 2017 2016 2015 XBRL Concept Total liabilities 110 100 N/A N/A N/A Liabilities 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? 2019 110 + 120 = 230 Yes 2018 100 + 90 = 190 Yes 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.

 Type Concept Balance Type Operand 1 + Liabilities Debit 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
this later.

The following are valid calculations based on balance type:

 Operand 1 Operand 2 Total + Credit + Credit = Credit + Credit - Debit = Credit + Debit + Debit = Debit - Debit - Debit = Credit - Credit - Credit = Debit + 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.

## Complexities and Limitations

Period Type

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

 Label Value Period Type Balance as of 12/31/2018 100 Instant Net Income 10 Duration Other Comprehensive Income 20 Duration Dividends Paid 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.

Dimensional Calculations
As mentioned before, calculations only apply to facts that share the same context. Hence, if two facts have different dimensions (and consequently different contexts), then they cannot be part of the same calculation.

Consider the following below:

 Concept Dimension Value Common Stock Shares Outstanding Common Class A Member 2,000,00 Common Stock Shares Outstanding Common Class B Member 1,000,00 Common Stock Shares Outstanding [None] 3,000,000

We have three facts all of which have the concept "CommonStockSharesOustanding". The dimensionless fact represents the total and the other two facts with dimensions represent the components or, in terms of a calculation, the operands. This is a quintessential application of dimensions - to break a data point into its components; however, there is no way to model it using XBRL calculations given the context restrictions.

Income and Cash Flows Statement
The relationship between the income statement and cash flows statement poses some interesting challenges regarding calculations. In the income statement, we show a number of items that ultimately add up to the total, "ProfitLoss". When creating the total for "NetCashProvidedByUsedInOperatingActivities" in the statement of cash flows, there are two options: the direct method and indirect method. To arrive at this total, the direct method adds and subtracts the cash items, whereas the indirect method starts with "ProfitLoss" and makes adjustments for non-cash items. As we will investigate below, the indirect method poses certain challenges when tagging XBRL.

Let’s consider the following simplified income statement:

 Concept Value Balance Type Revenues 10,000 Credit Depreciation Depletion and Amortization 1,000 Debit Asset impairment charges 500 Debit Profit loss 8,500 Credit

We can create the following simple calculation for "ProfitLoss" based on the balance types:

Revenues - DepreciationDepletionAndAmortization - AssetImpairmentCharges = ProfitLoss

Everything looks good so far. Now let us look at the corresponding cash flows statement:

 Concept Value Balance Type Profit loss 10,000 Credit Depreciation Depletion and Amortization 1,000 Debit Net cash provided by used in operating activities 11,000 No Balance Type

The first thing to notice is that "NetCashProvidedByUsedInOperatingActivities" lacks a balance type, which may seem odd at first. Given that this is a component of "Cash and Cash Equivalents," one might expect this concept to be a debit. Additionally, both "NetCashProvidedByUsedInFinancingActivities" and "NetCashProvidedByUsedInInvestingActivities" are debits.

If, however, "NetCashProvidedByUsedInOperatingActivities" were a debit, we would not be able to create the following calculation:

ProfitLoss + DepreciationDepletionAndAmortization = NetCashProvidedByUsedInOperatingActivities

If "NetCashProvidedByUsedInOperatingActivities" were a debit, then we would be forced to subtract "ProfitLoss" which does not make sense here. Fortunately, "NetCashProvidedByUsedInOperatingActivities" does not have a balance type so we are free to create the above calculation. Additionally, a portion of the definition for this concept appears to support this reason for no balance type:

While for technical reasons this element has no balance attribute, the default assumption is a debit balance consistent with its label.

Another issue that causes confusion with the cash flows statement is a calculation that exists in the income statement but in reverse fashion. Consider the following example from the income statement:

 Concept Value Balance Type Income loss from continuing operations 10,000 Credit Income loss from discontinued operations net of tax 5,000 Credit Discontinued operations gain/loss on disposal of discontinued operations net of tax 1,000 Credit Net income loss available to common stockholders, basic 16,000 Credit

Sometimes you could see the exact same items in the cash flows statement but in reverse order such as
the following:

 Concept Value Balance Type Net income loss available to common stockholders, basic 16,000 Credit Discontinued operations gain/loss on disposal of discontinued operations net of tax 1,000 Credit Income loss from discontinued operations net of tax 5,000 Credit Income loss from continuing operations 10,000 Credit

Creating a calculation for the income statement is not a problem, but we cannot create the calculation in the exact form that is presented in the cash flows statement. From the income statement, we have the following equation:

IncomeLossFromContinuingOperations + IncomeLossFromDiscontinuedOperationsNetOfTax + DiscontinuedOperationGainLossOnDisposalOfDiscontinuedOperationNetOfTax = NetIncomeLossAvailableToCommonStockholdersBasic

Algebra tells us that we can rewrite this equation as follows:

IncomeLossFromContinuingOperations =
NetIncomeLossAvailableToCommonStockholdersBasic - DiscontinuedOperationGainLossOnDisposalOfDiscontinuedOperationNetOfTax - IncomeLossFromDiscontinuedOperationsNetOfTax

From an XBRL perspective, since every concept in these equations is a credit including the total, the first equation is fine. We cannot, however, rewrite the first equation as the second in XBRL because we cannot have a negative calculation weight on the last two operands since those operands and the total are credits. Now given that the two calculations are logically equivalent, it is sufficient to just include the first one in the XBRL for both. In fact, the first calculation is valid for the cash flows statement even if that same data did not exist in the income statement.

Calculation Bleed-through
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:

 Concept Value Balance Type Revenues 10,000 Credit Operating expenses 6,000 Debit 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
via dimensions:

 Concept Hotels Corporate Consolidated Balance Type Revenues 10,000 0 10,000 Credit Direct costs of owned hotels 1,000 0 1,000 Debit General and administrative expense 1,500 1,500 3,000 Debit Depreciation expense 2,000 0 2,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.

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:

 Concept Label Value Label Role Rendered Value Balance Type Revenues Revenues 10,000 Standard 10,000 Credit Operating expenses Operating Expenses 6,000 Standard 6,000 Debit Operating income loss Operating Income 4,000 Total 4,000 Credit

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:

 Concept Label Value Label Role Rendered Value Balance Type Revenues Revenues 10,000 Standard 10,000 Credit Operating expenses Operating Expenses 6,000 Negated (6,000) Debit Operating income loss Operating Income 4,000 Total 4,000 Credit

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:

 Concept Label Value Label Role Rendered Value Balance Type Revenues Revenues -10,000 Standard 10,000 Credit Operating expenses Operating Expenses -6,000 Negated (6,000) Debit Operating income loss Operating Income -4,000 Negated Total 4,000 Credit

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.

## Conclusion

As we have shown, there are many considerations when applying XBRL calculations. The rules governing their use can appear complicated and overwhelming. There are limitations in the specification that add further confusion and can leave filers unsure as to whether or not they are applying calculations correctly. Many of the concerns can be addressed by a better understanding of the rules governing XBRL calculations especially with respect to contexts. As validation tools improve and the filer community becomes more educated in the nuances of the specification, calculations can shift from being a source of frustration to a source of confidence in the validity of XBRL data. Shawn Rush is the Chief Technology Officer at CompSci Resources, LLC. He earned a degree in Systems Engineering from the University of Virginia and has extensive experience consulting a wide array of clients on the XBRL specification and developing XBRL-related software products. Mr. Rush is a co-inventor of CompSci's patented XBRL technology that automates the review, organization, tagging, and analysis of data for generating XBRL documents.  Shawn Rush

Chief Technology Officer at CompSci Resources, LLC