1 Overview

This document provides requirements for a set of additional arcroles for capturing semantic relationships between XBRL concepts.

Standard XBRL arcroles provide relationships that are used to reflect the presentation of (parent-child) and calculation relationships between (summation-item) facts in an XBRL financial report, but they do not capture the accounting meaning of those relationships.

For example, four of the proposed new relationships capture a relationship between an instant concept and a duration concepts. Although there is a mathematical relationship between these concepts, the use of specialised relationships captures the accounting meaning of that relationship, distinguishing between, for example, an "accrual" contribution and an "inflow" contribution to a total.

New relationships types that capture accounting semantics in a structured form could be used to:

• Assist with tag selection by preparers by allowing concepts to be filtered by the accounting nature (such as "cash inflow");
• Provide more granular "anchoring" information for extension concepts;
• Drive automated quality rules, which case use relationships to find relevant concepts rather than hard-coded lists of concept names; and
• Enable more powerful analysis of XBRL reports.

2 Relationship to existing arcroles

2.1 Standard presentation (parent-child) relationships

The addition of concepts like class/subclass and traits do not fit well into a parent-child presentation model.

In many cases the relationships do not represent a hierarchy, but just a set of relationships which is inconsistent with the purpose of a parent-child relationship in the presentation linkbase.

Although it would be possible to create these new relationships using parent-child relationships by placing them in dedicated extended link roles, doing so would be a misuse of presentation relationships, and would be confusing to end users.

2.2 Standard calculation (summation-item) relationships

Current summation-item relationships do not support calculations between instant and duration concepts. Such relationships are planned for Calculations 2.0, but this would not negate the need for these proposed arcroles. As described above, these relationships do not just capture the mathematical relationships, but also the accounting nature of those relationships.

2.3 Link Role Registry arcroles

The Link Role Registry contains some arcroles that overlap with the functionality provided by these proposed new arcroles, but the existing arcroles are very specific and tied to individual concepts. For example, ArcroleGrossAccumulatedDepreciation.

3 Proposed new arcroles

There are eight proposed relationships:

• Instant/Accrual
• Instant/Contra
• Instant/Inflow
• Instant/Outflow
• Trait/Concept
• Trait Type/Domain
• Class/Subclass

3.1 Instant/Accrual

This relationship indicates that the target accrues into the source (instant) concept. Specifically, an accrual element that represents the expense or income provision against the instant element (typically an asset or liability). It signifies the use or interest costs during a reporting period when no cash transaction occurs.

It provides the link between an element measured at a point in time (instant) and an element measured over a period of time (duration). In this relationship, the source element is an instant element, and the target element is a duration element. If the source element has a credit balance, then the target element has a debit balance, and vice versa. The benefit to users is that it provides accounting relationships between the expense and the contra asset or asset. Ensures the balance is flowing into the applicable contra account and assists with identifying non-cash adjustments.

Here is an example:

“Finite-Lived Intangible Assets, Accumulated Amortization” (FiniteLivedIntangibleAssetsAccumulatedAmortization) is the instant element that represents the accumulated balance of the periodic amortization expense, “Amortization of Intangible Assets” (AmortizationOfIntangibleAssets).

3.1.1 How is this helpful?

This allows a user of the taxonomy to identify all non-cash expenses. These values are usually estimates made by management to allocate expenses to the correct accounting period. The ability to identify these concepts allows auditors and investors the information they need to quickly identify the balances that cause profit to differ from cash flow.

It also allows the filer to check if they are using the correct element. If the expense they are tagging is not booked against the instant, then they may have selected an incorrect element. They can look at the instant it impacts and use the accrual of that instant to tag the expense.

3.2 Instant/Contra

This relationship indicates that the target offsets the source element, specifically, a contra element that reduces the asset or liability. It provides the link between two instant elements. If the source element has a debit balance, then the target element has a credit balance, and vice versa. The benefit to users is that it provides accounting relationships between the contra account and the asset or liability that it offsets. Ensures that the contra accounts are properly classified as an offset when consumed by users.

Here is an example:

“Finite-Lived Intangible Assets, Accumulated Amortization” (FiniteLivedIntangibleAssetsAccumulatedAmortization) is the target element of “Finite-Lived Intangible Assets, Gross” (FiniteLivedIntangibleAssetsGross), as it represents the contra account.

3.2.1 How is this helpful?

It is not always obvious to a user and certainly not to a processor that an element is a contra of another. This information is useful when normalising data. When calculating total assets, for example, you can take all the debit instant items to determine assets, but you also need to deduct the contra credits from this total. Without this link the user has to manually identify what those contras are.

This relationship would be extremely useful for extension contras which would be unknown until the time the data is actually processed.

3.2.2 Note on similar arcroles in the LRR

The Link Role Registry contains a number of specific arcroles which are effectively specialisations of the proposed instant/contra arcrole:

• ArcroleGrossAccumulatedDepreciation
• ArcroleGrossAccumulatedDepreciationAndImpairmentLoss
• ArcroleGrossAccumulatedImpairmentLoss
• ArcroleGrossAllowance

Each of these arcroles are specific versions of the arcrole where the arcrole reflects the actual element. These arcroles should be replaced with instant-contra which provides a generic solution.

The gross-allowance arcrole is similar but lacks the semantics that both elements at the end of the arcrole are instances. It also implies that the gross amount is an asset with an allowance against it, whereas the contra can be used for liabilities as well.

3.2.3 Note on Gross-Net arcrole

The Link Role Registry also contains an existing Gross/Net arcrole.
This arcrole relates the gross and equivalent net items. This relationship is different in that it identifies the net item that is the result of deducting the contra element from the gross element. The definition of this arcrole should be updated to reference the proposed new instant/contra arcrole this so that these arcroles can be used together in a more effective way.

3.3 Instant/Inflow

This relationship indicates that the target element flows into the instant balance of the source element, specifically, an element that represents an increase to a particular instant balance.

It provides the link between an instant element and a duration element. In this relationship, the source element is an instant element, and the target element is a duration element. Generally, if the source element has a debit balance, then the target element has a debit balance, and vice versa.

The benefit to the users is that it provides accounting relationships between the elements that represent inflows or increases to balance sheet accounts. It also delineates between cash inflow elements and elements that are non-cash accrual elements.

Here is an example:

“Proceeds from Sale of Property, Plant, and Equipment” (ProceedsFromSaleOfPropertyPlantAndEquipment) is the target element of “Cash” (Cash), as it represents the inflow to cash from the sale of property, plant and equipment.

3.3.1 How is this helpful?

This allows the user to determine which duration concepts are included in an instant concept total. This is used for rules to check that extension taxonomies have not used duration elements inappropriately. For example, we check that Other Comprehensive Income items are not included in Net Income. To do this, we derive a list of all items that flow into Accumulated Other Comprehensive Income and check that none of the resulting elements are calculation descendants of Net Income. Alternatively, we can check that inflows into Retained Earnings are not a component of Other Comprehensive Income.

3.4 Instant/Outflow

This relationship indicates that the target element flows out of the instant balance of the source element, specifically, an element that represents a decrease to a particular instant balance.

It provides the link between an instant element and a duration element. In this relationship, the source element is an instant element, and the target element is a duration element. Generally, if the source element has a debit balance, then the target element has a credit balance, and vice versa.

The benefit to users is that it provides accounting relationships between the elements that represent outflows or decreases to balance sheet accounts. It also delineates between cash outflow elements and elements that are non-cash expense elements.

Here is an example:

“Payments to Acquire Property, Plant, and Equipment” (PaymentsToAcquirePropertyPlantAndEquipment) is the target element of “Cash” (Cash), as it represents the outflow of cash for the purchase of property, plant and equipment.

3.4.1 How is this helpful?

See above for Instant/Outflow.

3.5 Trait/Concept

This relationship indicates that the target element possesses the singular trait conveyed by the source element.

It provides the link between the trait, which is a domain member with a datatype of domainItemType, and the target concept. This relationship can be used in conjunction with the Class/Subclass relationship. A subclass of a class concept assigned a trait will inherit that trait.

The benefit to users is that they can easily search for elements based on the accounting traits possessed by the element in the taxonomy. Users also have the ability to auto-generate element lists, based on those traits.

Here is an example:

“Current [Member]” (CurrentMember) conveys the property of current, as opposed to non-current, and “Assets, Current” (AssetsCurrent) possesses that trait.

3.5.1 How is this helpful?

This allows the taxonomy creator to be specific about the trait of the concept. In taxonomies today these traits are often incorporated as text strings as part of the element name. Connecting such concepts to a specific “trait” makes this information available in a structured form, making queries such as “Give me a list of all current elements” straightforward. This also makes it possible to check that companies have defined calculations correctly. The sum of current assets for example should be composed of elements with the current attribute.

3.6 Trait Type/Domain

This relationship allows the definition of a domain of possible trait values. For example, the "Current" trait used in the previous section is one of two possible values for the "Currentness" trait type of either Current or Non-current.

The domains of trait values are defined using the existing domain-member arcrole. The Trait Type/Domain arcrole defines a trait type, represented by the concept at the source of the relationship, with a specific trait datatype (e.g. traitTypeItemType), and associates it with a domain.

“Cash” is the target of the Trait/Concept relationship from “Current”. “Current” is a target of the domain-member relationship from “Currentness Domain”, which in turn is the target of the Trait Type/Domain relationship from “Currentness”.

A concept cannot have more than one trait from the domain of a given trait type. In the example above, it would be an error for a single concept to be assigned both "Current" and "Non-current" traits using trait-concept relationships. This relationship assists in checking the integrity of the model.

The benefit to users is that it ensures that conflicting accounting attributes are not assigned to an element.

The following example demonstrates how different valuation techniques apply to specific accounting concepts. The "Recorded Value [Trait]" represents the trait type that is being described. The possible values of this trait type are:

• Recorded at Historical Cost
• Recorded as Estimate
• Recorded at Carrying Value

Each of these traits is represented as a member of a domain. This means that a concept at the end of the trait-concept arc can only have one trait from a given domain. “Debt Securities held to maturity, Allowance for credit loss, Current” can only be valued with the "Recorded as Estimate" trait.

3.6.1 How is this helpful?

This allows a taxonomy creator to know the available traits that can be used on an element and those that cannot be used in conjunction with each other.

It also allows rules to be written that check that items with conflicting attributes are not grouped together. For example, an element with a non-current attribute should not be added to a parent with a current attribute. It effectively defines the list of allowable key value pairs.

3.7 Class/Subclass

This relationship indicates that the target element inherits all of the traits of the source element. The target (subclass) element can have additional traits assigned to it.

It provides the link between two elements that have the same base attributes, that is data type, period type and balance type (if applicable). For example, if the source element is instant and debit, then the target element will also be instant and debit.

The benefit to users is that the application of a Class/Subclass relationship in the taxonomy makes it easier for users to understand the traits of every element.

Here is an example:

“Prepaid Expense, Current” (PrepaidExpenseCurrent) is the target element of “Assets, Current” (AssetsCurrent), as it inherits all of the traits of current assets.

3.7.1 Restrictions of the Class/Subclass relationship

• A class-subclass relationship cannot have a source or target concept that has a trait datatype. (See Trait Type/Domain)

• Inheritance applies across all networks in the DTS.

• A trait member cannot be the source of a Class/Subclass relationship. This would result in the subclass being a duplicate of the class as trait concepts can only have one trait.

• A Class/Subclass relationship cannot be defined between concepts with conflicting concept attributes. For example, a Class/Subclass relationship cannot be defined between a concept with a balance attribute of debit and a concept with a balance attribute of credit. A Class/Subclass relationship cannot be defined between a concept with a period type of "instant" and a concept with a period type of "duration". A Class/Subclass relationship cannot be defined between a concept with a datatype of "string" and a concept with a datatype of "monetary".

• Any target subclass of a source class concept with Trait/Concept relationships will inherit those traits. In the example below, commercial paper has the traits of "Carrying Value" and "Current".

• Any target subclass of a source class concept cannot have conflicting traits. The example below has an invalid Class/Subclass relationship because the concepts have conflicting values for the same trait type:

The above Class/Subclass hierarchy should be defined as follows:

3.7.2 How is this helpful?

This relationship is intended to save time for taxonomy creators, and reduce taxonomy size, by allowing sets of traits to be shared easily between multiple related concepts.

This arcrole is effectively the same as the standard general-special arcrole, but has specific semantics (traits are inherited), and the explicit restriction of requiring that attributes of the element's descendants must have matching attributes.