Table of Contents

1 Introduction

Preparers in open reporting environments may create extension elements to report disclosures that are unique to their business. These extension elements can be linked to suitable elements in the base taxonomy through anchoring. This linkage enables analysts, regulators, and other data users to interpret, compare, and analyse extension elements with greater clarity and consistency.

This guidance offers a high-level overview of various relationships¹ used in XBRL taxonomies and reports, emphasising their role in "anchoring" an Entity-Specific Disclosure (ESD). However, it does not provide a detailed examination of each relationship, which is beyond its scope. Broadly speaking, XBRL relationships refer to the associations between different elements and metadata in an XBRL taxonomy or instance document.

A well-designed base taxonomy leads to ESDs that are easier to interpret, compare, and consume—while potentially reducing the need for extensions. Therefore, the primary focus should be on designing base taxonomies that effectively accommodate ESDs, rather than relying solely on anchoring mechanisms to interpret their meaning. Read more about modelling base taxonomies to support ESDs in the separate guidance.

This guidance is primarily intended for regulators and taxonomy authors, offering direction on creating and enforcing XBRL relationships that support anchoring—ensuring consistent linkage between extension elements and base taxonomy concepts, potentially through filing rules.

This guidance also aims to build awareness among data consumers of both existing and newer anchoring relationships, helping them better interpret extension elements and apply them effectively in analytical models and reporting tools.

This guidance categorises relationships into three groups:

Designed for Anchoring

The "wider-narrower" relationship, specifically developed for European Single Electronic Format (ESEF) requirements by XBRL International, links ESD elements to broader and narrower base taxonomy concepts.

Currently in Use with Anchoring Potential

Existing relationships like the Calculation Tree, Presentation Tree, Cube, Extensible Enumerations, Labels, and References can be leveraged to anchor ESDs. These relationships provide validation, organisation, disaggregation, metadata, and external references.

Emerging with Anchoring Potential

Newer relationships, such as trait-concept, class-subclass, fact-explanatoryFact, instant-accrual, and instant-inflow/outflow, introduce ways to define and validate connections between financial elements. These concepts enhance precision in taxonomy design and facilitate accurate classification.

Each relationship is described with its technical construct, expected and alternative uses, and potential anchoring applications. The document also references further guidance on how to effectively implement anchoring in XBRL reports. For a more detailed discussion of anchoring see How to address Entity Specific Disclosures in XBRL reports.

2 Relationships – designed for anchoring

2.1 Wider-Narrower (relationship)

An anchoring mechanism that links source concepts of wider scope and meaning to target concepts with narrower scope and meaning. The relationship links an extension concept to a base taxonomy concept.

This is the only XBRL relationship specifically developed for anchoring by XBRL International. It was created to support ESEF requirements. Here is additional guidance for using the ESEF rules for anchoring extensions.

Technical Construct

• Wider anchor [concept]

  • Narrower anchor(s) [concept]

  For example, the extension taxonomy element "Flight equipment" can be anchored to the base taxonomy element "Property, plant and equipment," linking an extension element to a wider accounting meaning base taxonomy element.

Expected Uses

• This relationship is intended for use on reporting concepts. It is not intended for use between domain members or other dimensional components.

Other Uses

• Narrower anchors are often used to link the primary statements extended element to details that are disclosed in the notes to the financial statements.

Anchoring Use Case

• This mechanism was created and used for anchoring as specified in ESEF requirements.

3 Relationships – currently in use with anchoring potential

These relationships are in widespread use and may be leveraged for anchoring.

3.1 Calculation Tree

This relationship between elements provides a mechanism for describing and validating simple totals and subtotals.

Technical Construct

• Total (roll up)
  • Contributing elements

For example, using a calculation tree, "Assets" can be defined as the sum of "Current assets" and "Non-current assets".

Expected Uses

• Validation of totals and subtotals

Other Uses

• Using the relationship to express totals.
• Understanding the meaning of a concept based on this relationship.

Anchoring Use Case

• Using calculation relationships as anchors.

3.2 Presentation Tree

The organisation of taxonomy elements into a hierarchical structure with the aim of providing a means of visualising or navigating the taxonomy.

Technical Construct

• Abstract element
  • Parent element
  • Child element

For example, a presentation tree can organise the taxonomy of greenhouse gas emissions as follows:

• Greenhouse Gas (abstract)
  • Scope 1 Emissions
  • Scope 2 Emissions (abstract)
    • Location-based Scope 2 Emissions
    • Market-based Scope 2 Emissions
  • Scope 3 Emissions

Expected Uses

• Helps organise the reported facts for readability and comprehension with the grouping of elements by reporting chapters, sections and subsections.
• This relationship is used to arrange the relative position of elements displayed to a user.

Other Uses * The presentation tree can be used to interpret the accounting meaning of concepts through hierarchical groupings (e.g., Current Assets, Cash Flows). * The presentation tree helps interpret arithmetic relationships for period-over-period reconciliations or dimensional disaggregations when these cannot be captured in the calculation tree. * The presentation tree can be used to understand arithmetic relationships when the calculation tree is underused or missing. * The presentation tree helps assess if there are gaps and inconsistencies in the calculation tree.

Anchoring Use Case

• An extension could be "part of" a presentation group as an extended parent or child. An anchor relationship is useful to identify relevant properties of the extension element in context of the presentation group.
• For example: an extension for a "Specific current receivable" is part of "Current assets", is calculated in the "Current assets subtotal" but the presentation relationship does not specify that it is a "Current receivable".
• Includes additional meaning and utility for Abstracts(header) beyond what we have included in the past.
• Ordering can be a type of anchoring. Getting the order "correct" for presentation may provide a proxy for anchoring.

3.3 Cube

A multi-dimensional definition of related data. A cube is defined by combining one or more dimensions with one or more concepts. Cubes are often referred to as "hypercubes", as unlike a physical, 3-dimensional cube, a hypercube may have any number of dimensions.

A taxonomy-defined dimension may be either "explicit", in which case the taxonomy defines a list of allowed dimension values (Members) (e.g. a list of countries), or "typed", in which case the taxonomy defines the format for dimension values (e.g. the format for a postal code).

Technical Construct

• Abstract
  • Cube
    • Axis (Dimensions)
      • Members
  • Line items
    • Concepts

For example, a dimensional structure is defined to support a disclosure in which the Revenue concept is disaggregated by reporting segment. A cube includes a "Segment" dimension whose members—Segment A and Segment B—represent the individual reporting segments. The common "Revenue" concept, disaggregated by these segment members, is included within the same cube.

Expected Uses

• A cube is expected to be used when one or more dimensions are applied to a concept.
• A dimension is required when the same concept is used to tag two or more facts instead of using different concepts in the same reporting period.

Other Uses

• Dimensions are commonly used to represent the breakdown (disaggregation) or roll-up (aggregation) of reported values.
• A dimension can be used when additional information is provided about a fact. For example, if "dividends on class A stock" are reported using a generic "Dividends" concept, a dimension can indicate the class of stock — using "Class of stock axis" and "Class A member". However, if the concept itself already includes the class information (for example, "dividends on class A stock"), then a dimension is usually not needed.

Anchoring Use Case

• Anchoring is built-in to the structural element design whether as an explicit or typed dimension. Members of a dimension provide a way for preparers to anchor expected ESDs using the Cube design.
• A dimension element extension can be regarded as anchored due to its connection with other elements within the cube structure, as required by ESEF.
• Anchoring members to other members.
• Although both explicit and typed dimensions include an anchoring mechanism, explicit puts those members in a hierarchy while typed does not, so typed is not as precise. Typed dimensions lose the hierarchy but gain more specificity with the dimension constraint.

3.4 Extensible Enumerations

While not a relationship itself, this is an XBRL design feature to define concepts for facts that take a value, or set of values, from a taxonomy-defined list of values that can be augmented.

The list of allowed values is defined using the same mechanism as used for defining dimension members in a taxonomy. This allows the same enumeration to be used as a fact value or as a dimension value for an explicit taxonomy-defined dimension.

Technical Construct

• There are two parts to this feature that are defined separately in the taxonomy:
• The Enumeration concept.
• The predefined list of values that can be augmented.

For example, consider a concept that requires a reporting currency. This concept can be defined as an extensible enumeration type linked to a list of valid currencies defined as domain members, ensuring that preparers choose only from the provided list.

Expected Uses

• Taken together with the Extensible Enumeration concept, preparers choose from a predefined list or create entity-specific options if needed (i.e., drop-down values).
• Used interchangeably for enumeration and for defining dimension members in a taxonomy, as the list of allowed values for members is defined using the same mechanism. This allows the same enumeration to be used as a fact value or as a dimension value for an explicit taxonomy-defined dimension.
• See XBRL International blog post, Enumerations in XBRL for additional examples.

Other Uses

• An Extensible Enumeration concept associated with another concept can be used to convey additional information about a reported value of that concept that has not been disaggregated. For example, an extensible enumeration element "Revenue, Product and Service [Extensible Enumeration]" is used to convey additional information about revenue values that are not disaggregated by type of products or services in a statement of income. This approach reduces the need for a concept extension.

Anchoring Use Case

• Using Extensible Enumeration alongside a concept—as described in "Other Uses" cases — especially with entity-specific values, preserves the connection to the base taxonomy while capturing entity-specific detail.

3.5 Labels

XBRL label roles are used to assign a specific meaning to a label for a given element. A taxonomy component can be assigned multiple labels of different types and in different languages.

Technical Construct

• Label role (type of label such as Standard label, Terse label, Documentation label)
• Language

For example, the concept "CashAndCashEquivalents" may include a standard English label ("Cash and cash equivalents"), a standard German label ("Zahlungsmittel und Zahlungsmitteläquivalente"), and an English beginning balance label ("Cash and cash equivalents, opening balance").

Expected Uses

• To control the presentation of taxonomy elements and report values
• Documentation of taxonomy component, providing an explanation of its meaning and its appropriate usage and any other documentation deemed necessary.

Other Uses

• Providing more information about taxonomy components.
• See label role guidance for details.

Anchoring Use Case

The label of a specific entity disclosure, when created with the base taxonomy style, can give an indication of the accounting meaning of an extension. However, this is unstructured and cannot be considered a reliable form of anchoring.

3.6 References

A piece of structured information attached to a taxonomy component that provides a link to external information about the element.

A taxonomy component may have any number of references associated with it. Each reference is composed of a number of reference parts.

Technical Construct

• Reference Role (type of reference such as disclosure reference)
• Reference Part (such as "Article", "Chapter").

For example, the concept "Issued capital" may include disclosure references linking it to its definition in an IFRS standard, as follows

• Name: IAS
• Number: 1
• Issue Date: 2022-03-24
• Paragraph: 78
• Subparagraph: e

Expected Uses

• References are typically used to provide links to the definition of a taxonomy component in authoritative literature, such as the relevant accounting standard or legislation. A taxonomy component may have any number of references associated with it.

Other Uses

• Taxonomy implementation notes / Change notes
• Structured information about taxonomy component in key-value format using property references. For details see guidance on property references.

Anchoring Use Case

• Potential mechanism for anchoring by using the same reference to supporting authoritative literature as a comparable base taxonomy element.

4 Relationships – emerging with anchoring potential

Except for "fact-explanatoryFact", these relationships have only been recently developed and are not yet in general use.

4.1 trait-concept (relationship)

It indicates the relationship between a source trait domain member and a target concept. Traits are abstract elements with a domain item type, where a trait represents a property or characteristic — such as liquidity, where the trait may distinguish between current and non-current.

Define the traits of a concept. This allows concepts to be easily classified by their traits or qualities. These relationships can be used to validate the appropriateness of concepts when the traits conflict with the use of the concept.

Technical Construct

• Source [domain-member]
  • Target concept

For example, the concept "Current asset" can be linked to the trait "current" (defined as a domain member). This association classifies "Current asset" by highlighting its short-term and liquid characteristics, thereby enhancing the understanding.

Expected Uses

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

Other Uses

• None observed at this time.

Anchoring Use Case

• This relationship could be used to identify an extension by one or more traits.

4.2 trait-domain & domain-member (relationship)

Defines a relationship between the trait type and the domain which represents a set of possible trait values.

For example, a trait type of liquidity may have values of current and noncurrent. The liquidity domain has possible trait values of current member and non-current member. The traits "Current" or "Noncurrent" are linked to concepts using the trait-concept relationship. The use of a domain allows the integrity of the model to be checked. No concept as a target of the trait-concept relationship can have more than one trait from a given trait domain. I.e., A concept cannot be defined as current and noncurrent.

Technical Construct trait-domain

• Trait Type [trait datatype]
  • Domain [Domain Type]

Technical Construct domain-member

• Domain [Domain Type]
  • Domain Member 1 [domain-member]
  • Domain Member 2 [domain-member]

For example, consider the liquidity trait. It is first linked to the liquidity domain using a trait-domain relationship. This domain contains two members — "current" and "noncurrent" — which are defined through domain-member relationships. Then, a concept such as "Current asset" can be linked to the trait "current" via a trait-concept relationship, ensuring that a concept cannot be classified as both "current" and "noncurrent."

Expected Uses

• This relationship allows the definition of a domain of possible trait values.
• A concept cannot have more than one trait from the domain of a given trait type, i.e., they are mutually exclusive.

Other Uses

• None observed at this time

Anchoring Use Case

• It can be used to more precisely categorize and identify traits of an ESD. Could be used for nature versus function; operating versus non-operating, etc.

4.3 Class-subclass (relationship)

Indicates the relationship between a source class concept and a target subclass concept.

Technical Construct

• Source concept
  • Target concept

For example, "Prepaid expense, current" can be defined as a subclass of "Assets, current," meaning it inherits all the traits or characteristics of "Assets, current."

Expected Uses

• Class-subclass relationships describe that the target concept has the same attributes of the class concept with further qualifiers.
• 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).

Other Uses

• None observed at this time.

Anchoring Use Case

• Incremental benefit over other mechanisms to establish a connection with a base taxonomy element because the class-subclass relationship provides greater precision regarding inheritance. All the traits that are applied to the parent apply to the child as well. Also provides some constraints in that, for example, net and gross elements should not be in class-subclass relationships to each other.
• Class-subclass is more precise and therefore less flexible than the "vague" wider-narrower anchor.

4.4 fact-explanatoryFact (relationship)

Relationship for linking a fact with an explanatory fact in an XBRL report.

This relationship helps in understanding how one piece of information relates to or explains another piece of information in the financial statements or reports.

Technical Construct

• Source fact
  • Target fact

For example, an "Impairment expense" fact in the income statement can be linked to its corresponding "Impairment disclosure" fact using the fact-explanatoryFact relationship, thereby indicating that the second fact provides additional explanation for the first.

Expected Uses

• Use "fact-explanatoryFact" mechanism to connect a disclosed fact in the notes with the fact in the primary financial statements in which the amount is included.

Other Uses

• Could also be used to associate two or more related facts in the instance document including ESDs.

Anchoring Use Case

• Could be used to associate an ESD extension to a reported fact that is tagged with a base taxonomy element.

4.5 instant-accrual (relationship)

It indicates the relationship between an instant concept and a durational accrual concept representing the provision of expense or income against the instant concept. The source concept is always an instant and the target concept is always a duration.

Technical Construct

• Source [instant concept]
  • Target concept

For example, the concept "Finite-lived intangible assets, accumulated amortization" (an instant concept) can be linked to "Amortization of intangible assets" (a duration concept) using the instant-accrual relationship, indicating that the amortization expense accumulates over time and is reflected in the accumulated amortization balance at a specific point in time.

Expected Uses

• This relationship indicates that the target accrues into the source (instant) concept.
• It provides the link between an element measured at a point in time (instant) and an element measured over a period of time (duration).

Other Uses

• None observed at this time.

Anchoring Use Case

• Incremental benefit over other mechanisms to establish a connection with a base taxonomy element. For example, a depreciation expense extension would be anchored most effectively to the base taxonomy depreciation element.
• This relationship doesn’t give you an anchor if the source and target are both extensions.

4.6 instant-contra (relationship)

This relationship indicates that the target concept offsets or reduces the value of the source concept. In other words, the target concept represents a contra amount that is subtracted from the source concept to arrive at a net amount.

Technical Construct

• Source concept
  • Target concept

For example, "Loans and advances at amortised cost, gross carrying amount" can be linked to "Loans and advances at amortised cost, allowance for expected credit losses" using the instant-contra relationship, indicating that the allowance for expected credit losses offsets the gross carrying amount of the loans and advances.

Expected Uses

• This relationship indicates that the target offsets the source concept.
• It provides the link between two instant concepts. If the source concept has a debit balance, then the target element has a credit balance, and vice versa.
• The value associated with the target contra concept should never exceed the value of the source instant concept in an instance document if both are reported with the same dimensions. The relationship can only flow in one direction. A concept cannot be a contra element to itself.

Other Uses

• None observed at this time.

Anchoring Use Case

• Incremental benefit over other mechanisms to establish a connection with a base taxonomy element.
• This relationship doesn’t give you an anchor if the source and target are both extensions.

4.7 instant-inflow (relationship)

It indicates that the inflow duration concept adds to the balance of the instant concept.

Technical Construct

• Source concept
  • Target concept

For example, "Cash" (an instant concept) can be linked to "Proceeds from sale of property, plant, and equipment" (a duration concept) using the instant-inflow relationship, indicating that the proceeds increase the balance of "Cash."

Expected Uses

• 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.
• Used with roll forwards.
• An accounting instant concept with a debit balance will have an associated inflow concept with a debit balance. An instant concept with a credit balance will have an associated inflow concept with a credit balance. This relationship can be used to define the components of a roll forward or to indicate how concepts measured over a period of time impact the balances of concepts measured at a point in time.

Other Uses

• Validation check
  • Proposed XBRL US DQC rule uses the concept-inflow and concept outflow relationships defined in the FASB Meta Model Taxonomy. The rule uses these relationships to determine items that can appear in the income statement. The rule identifies all concepts that are inflows or outflows from "Retained Earnings Accumulated Deficit". These concepts are income statement items. The rule identifies all facts in the instance that use the "Statement Of Financial Position Location Activity Accrual [Axis]" and flags any facts that are not income statement items or extensions. These relationships allow the simple identification of those items that impact net income.

Anchoring Use Case

• A cashflow statement extension element like proceeds for XYZ sales would ordinarily be anchored to change in investing activities using wider-narrower relationship. This instant-inflow relationship would confirm that it belongs to the cashflow statement.
• Can be used to validate proper wider side anchoring but incremental over other available anchoring options.
• Can be used as a validation that it has been properly anchored assuming the instant-inflow relationship exists in the base taxonomy. Preparer should be anchoring to "proceeds" element that is included in this relationship.

4.8 Instant-outflow (relationship)

It indicates that the outflow duration concept reduces the balance of the instant concept.

Technical Construct

• Source concept
  • Target concept

For example, "Cash" (an instant concept) can be linked to "Payments to acquire property, plant, and equipment" (a duration concept) using the instant-outflow relationship, indicating that these payments decrease the balance of "Cash."

Expected Uses

• 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.
• Used with roll forwards.
• An accounting instant concept with a debit balance will have an associated outflow element with a credit balance. This relationship can be used to define the components of a roll forward or to indicate how concepts measured over a period of time impact the balances of concepts measured at a point in time.

Other Uses

• See Instant-inflow

Anchoring Use Case

• See Instant-inflow

4.9 Concept-dimensional-equivalent (relationship)

This relationship indicates that the combined target elements are equal to the source element. In other words, the target elements synthetically create the same accounting concept as the source element.

Technical Construct

• Source concept
  • Target concept (concept)
  • Target concept (dimension)
  • Target concept (member)

For example, the single concept "Retained Earnings (Accumulated Deficit)" (the source element) can be shown to be equivalent to the dimensional combination of (target elements):

• Equity, Including Portion Attributable to Noncontrolling Interest (the "base" equity concept),
• Equity Components [Axis], and
• Retained Earnings [Member] (the specific component of equity).

Essentially, the dimensional approach (concept +axis + member) is equivalent to using the standalone concept.

Expected Uses

• This relationship provides the link between three target elements and a source element. The three target elements are comprised of one primary element that possesses the same data type and period type as the source element (but not necessarily the same balance attribute for monetary elements), one dimension element, and one domainItemType element.

Other Uses

• XBRL US DQC rules use the concept-dimensional-equivalent relationship defined in the US-GAAP meta data taxonomy. The rule uses these relationships to check if concepts match their dimensional equivalents. The rule flags errors where they do not match. See XBRL US DQC rule.

Anchoring Use Case

• It could in theory be used to anchor an extension source with the three target elements and vice versa but there are better alternatives such as using the existing taxonomy elements.

5 Conclusion

When designing anchoring requirements for Entity-Specific Disclosures (ESDs), regulators and taxonomy architects can leverage three levels of relationships, selecting one or combining multiple levels depending on their objectives.

1. Traditional relationships — such as Calculation, Presentation, and Cube structures — provide logical structuring, dimensional categorisation, and basic validation for reported facts. This level establishes a foundational structure without introducing significant filer burden.

2. Wider-Narrower relationships — specifically designed for anchoring — directly connect ESDs to base taxonomy concepts, improving comparability, alignment, and analysis while introducing moderate additional complexity for filers.

3. Advanced relationships — such as Trait-based, Class-Subclass, Fact-explanatoryFact, and validation-oriented relationships (e.g., instant-accrual, instant-inflow, instant-outflow) — offer the potential for very precise semantic anchoring, enhanced data validation, and improved machine interpretability. However, these approaches are still developing in the base taxonomies, and may involve additional effort for preparers and software developers as practices and tools continue to mature.

The deeper the anchoring requirements, the greater the potential for enhanced data utility, automated validation, comparability, and analytical power. However, this needs to be balanced against the effort required from preparers, the current state of available tools, and the overall readiness of reporting ecosystems.

By making deliberate choices about which levels of anchoring to mandate, regulators can tailor reporting frameworks to meet their policy objectives while managing complexity for filers.