Components of an XBRL Taxonomy

Learning Objectives link

By the end of this section, readers will be able to:

• Understand the fundamental purpose and structure of taxonomies in digital reporting
• Identify and describe the core components of a taxonomy, such as concept definition, relationships and structural elements
• Understand other technical components such as namespaces used in taxonomy definition
• Appreciate the benefits of well-structured taxonomies in improving data quality, regulatory compliance, and transparency

Introduction link

An XBRL framework consists of two main components: XBRL taxonomies and XBRL reports. Taxonomies define the structure and meaning of the data, while XBRL reports contain the actual data reported using the taxonomy framework. Together, these components enable the creation of machine-readable and consistent digital reports.

Taxonomies act as a bridge between technical data definitions and real-world business reporting needs. They ensure that information is communicated clearly and uniformly, facilitating regulatory compliance and enabling data-driven decision-making at a global scale.

A taxonomy is a structured framework that defines, organises, and interrelates data. It is pivotal in standardising regulatory data and improving its quality, transparency, and information interoperability between stakeholders.

The following section will explore the key components that form the backbone of a taxonomy.

Concept Definition: The Foundation of a Taxonomy link

Every XBRL taxonomy is built on concepts, the building blocks that define what can be reported. Concepts represent key terms in a report, like “Revenue”, “Total Assets”, or “Greenhouse Gas Emissions”. Each concept must be clearly described so that both people and software can understand how to use it and what data type it expects.

When designing a taxonomy, each concept is assigned a set of properties. These properties explain what kind of value it accepts, how it behaves in reports, and how it relates to time, financial direction, and other reporting dimensions.

Key Properties of a Concept link

The following table explains key properties used for defining a concept.

Other Taxonomy Elements link

In addition to concepts, taxonomies define header elements that serve as section headings in the concept hierarchy, such as “Statement of Financial Position” in a presentation tree. These header elements cannot be used to report facts and are technically marked as “abstract”.

The taxonomy also defines structural elements used for technical constructs such as cubes, dimensions, domains, and domain members. These elements are discussed in detail in the dimensional relationships section.

Additional Element Properties link

Taxonomy elements also have additional properties, such as “nillable”, which indicates whether a value can be nil, and “substitution group”, which defines whether the element represents a reportable fact, or a type of structural element.

Examples: Taxonomy Concepts and Properties link

The following is an extract of taxonomy concepts with their properties, as displayed in a taxonomy tool.

Technically, taxonomy elements are defined in “XML Schema (XSD) files”, where each element is declared with properties (or “attributes”).

Relationships: Connecting the Dots in a Taxonomy link

A taxonomy does more than just define individual elements: it also defines how they relate to each other. These connections, known as relationships, allow the taxonomy to represent hierarchies, calculations, dimensions, labels, references, and more.

Without relationships, a taxonomy would be just a list of isolated definitions. Taxonomy relationships turn that list into a meaningful structure, helping both humans and machines understand how the different elements fit together.

Technical constructs used to define relationships between taxonomy elements such as presentation, calculation, and dimensional relationships are referred to as “linkbases”. The technical term for the object specifying the type of a relationship in a taxonomy is “arcrole”.

The following sections explain the main types of relationships found in XBRL taxonomies, each designed to support a different aspect of reporting logic, validation, presentation, or interpretation.

Presentation Tree: How Taxonomy Elements are Organised link

A simple, unstructured list of taxonomy concepts can be difficult to interpret. To address this, the presentation tree in the taxonomy is used to organise elements into a hierarchical structure, making it easier to visualise and navigate the taxonomy. For example, the presentation tree for financial concepts mirrors the hierarchy of balance sheets or income statement items as seen in the extract of a presentation tree below.

The presentation tree is used to display the taxonomy structure in a user-friendly format, helping humans navigate the taxonomy more easily.

Taxonomy elements are grouped under logical sections such as Balance Sheet or Cash Flow Statement. These groups are technically known as “Extended Link Roles” (ELRs). Within each ELR, elements are arranged hierarchically using the “order” attribute, which determines the position of each element within its parent group. This allows for multiple levels of nesting to reflect the structure of business reports.

Additionally, the labels shown in the hierarchy can be customised. For instance, the concept “Assets” might appear as “Total Assets” in the Balance Sheet. This can be controlled using the “preferred label” attribute in the presentation tree.

Calculation Relationships: Validating Totals link

The calculation tree defines relationships between concepts in a taxonomy for the purpose of describing and validating simple totals and subtotals. An example of a calculation relationship is: “Assets” = “Current Assets” + “Non-Current Assets”.

Calculation relationships help users of the taxonomy understand how numeric concepts relate to other numeric concepts in the taxonomy. They act as a guide for report preparers in tag selection. XBRL validation software will flag an inconsistency if the fact values in a report do not add up according to the calculation relationships defined in the taxonomy. Thus, XBRL calculations are a valuable tool for defining concept semantics and checking the consistency of reports.

The following is an extract from the calculation tree in a taxonomy, showing how “Equity and Liabilities” is calculated based on the sum of “Liabilities” and “Equity”. Similarly, “Assets” is broken down into “Current” and “Non-current Assets”, reflecting the structure of the statement of financial position.

The “weight” attribute in the calculation tree determines whether child items are added to or subtracted from the parent total. A weight of 1 means the value is added, while a weight of -1 means it is subtracted.

For example, to calculate “Gross Profit”, which is “Revenue” – “Cost of Sales”, the concept “Revenue” will have a weight of +1 and “Cost of Sales” will have a weight of -1 in the calculation tree.

Calculation checks ensure that all reported values add up correctly. These rules are defined once in the taxonomy and are automatically applied each time a report is validated using that taxonomy.

Example: Calculation Check link

According to the calculation tree: “Assets” = “Current Assets” + “Non-Current Assets”.

Companies A and B report the following values in a financial statement:

For Company A: 80,000 + 120,000 = 200,000 ✔️ Since the values add up correctly, the calculation check passes.

For Company B: 80,000 + 120,000 = 195,000 ✖️ It would trigger a warning, alerting the preparer that the total doesn’t match the defined rule in the taxonomy.

Dimensional Relationships: Data Disaggregation and Qualifications link

In business reporting, disclosures are often broken down by categories such as region or customer type. For example, a company might report its revenue by region, such as:

• Revenue – Americas
• Revenue – Europe
• Revenue – Asia-Pacific
• Revenue – Africa

This can be modelled in an XBRL taxonomy by creating a separate concept for each of these, like “RevenueAmericas”, “RevenueEurope”, etc. This approach is acceptable and captures the required information. However, if other concepts, such as “Profit”, also need to be reported by region, separate concepts like “ProfitAmericas”, “ProfitEurope”, and so on would also have to be created. This can lead to a large number of repetitive concepts.

XBRL offers a more flexible and scalable approach using dimensional structure. Instead of creating a separate concept for each region, one can define a concept like “Revenue” or “Profit” and use a dimension, such as Region, to break down that concept. This allows to report facts like:

• Concept: Revenue | Dimension: Region = Africa
• Concept: Profit | Dimension: Region = Europe

The dimensional approach avoids concept duplication and promotes consistent breakdowns across multiple concepts, making taxonomies easier to manage and reports more consistent.

In sustainability reporting dimensional structure avoids redundancy, making it easier to apply similar breakdowns, such as by facility, region, or business activity, across multiple sustainability metrics like water usage or energy consumption.

Key Components of Dimensional Structure link

• Cube (Hypercube): A multi-dimensional view of data created by combining concepts with dimensions. Example: A cube could define “Revenue” and “Profit” broken down by “Geography” and “Product Line”.

• Taxonomy-Defined Dimensions: These dimensions are created within the taxonomy to express meaningful breakdowns of data, such as by region, product line, or emission source. They are called taxonomy-defined dimensions to distinguish them from the built-in XBRL dimensions, like period, unit, and entity, which are used to qualify every fact in an XBRL report. Unless otherwise specified, when the term “dimensions” is used in this context, it refers specifically to taxonomy-defined dimensions. Taxonomy-defined dimensions are of two kinds: explicit and typed.

• Explicit Dimensions: An explicit dimension has a predefined list of allowed values, called “domain members”. These are declared within the taxonomy, allowing only specific, controlled values to be used in reports. Explicit dimensions ensure consistency across reports by limiting values to a known list. Example: A “Geography” dimension may have a “domain” called “Continent”, which includes the domain members: Africa, Europe, Asia-Pacific, and so on.

• Typed Dimensions: A typed dimension allows for free-form but structured values. Instead of a list of domain members, the taxonomy defines the data type or format that values must follow (e.g., string, date, number). Typed dimensions are useful when the dimension values are numerous, dynamic, or cannot practically be listed exhaustively in advance (e.g. entity IDs, location codes). Example: A “PostalCode” dimension may allow any valid postal code format (like “110001” or “W1A 1AA”), as long as it matches a defined pattern (e.g., a string of digits or alphanumeric).

• Domain: A domain is a set of related values. Example: Different domains for use on a “Geography” dimension could include “Countries”, “Continents” or “States”.

• Domain Member: An element representing one of the possibilities within a domain. These may be used as possible Dimension values. Example: “Africa” is a domain member of the “Continent” domain, which is used under the “Geography” dimension.

• Dimension Default: The assumed value for a dimension when it is not explicitly stated, usually representing the total. Example: If a reported “Revenue” fact does not specify a “Geography” dimension value, it is assumed to be the total across all geographies.

Example: Taxonomy-Defined Explicit Dimension link

In the following table, the segment reporting disclosure is modelled using a dimensional structure, where the concepts “Revenue” and “Profit” are qualified using the explicit “Geography” dimension. The “Geography” dimension includes three domain members: Americas, Europe, and Asia, predefined in the taxonomy.

Example: Taxonomy-Defined Typed Dimension link

In the following table, energy consumption disclosure is modelled using a dimensional structure, where the concept “Energy Consumption” is qualified using the “Facility” dimension. The “Facility” dimension is defined as a typed dimension, meaning it accepts structured values, such as alphanumeric facility codes, instead of being restricted to a predefined list of members specified in the taxonomy.

Labels: Making Concepts Human-Readable link

Taxonomies are machine-readable by design, but clarity for human users is equally important.Labels in a taxonomy provide text descriptions to taxonomy elements that help preparers, reviewers, and users interpret the data being reported.

A single taxonomy component can have multiple labels. Labels may be multilingual and serve different purposes. Different label types are identified using “label roles”, which define the purpose of the label. Standard Label (defined using the “standard role”) provides the default label for a concept. Each concept should have a standard label. For example, the concept “CostOfGoodsSold” would have a standard label like “Cost of Goods Sold”, providing a human-readable name for display in reports and tools.

A good standard label should be standalone, unique, useful, concise, and consistent across the taxonomy. It must accurately describe the concept without relying on hierarchy, avoid context-specific terms, and follow an agreed-on labelling convention for clarity and uniformity.

When labels in multiple languages are defined, software can allow the reader to view labels in their preferred language when viewing an XBRL report or taxonomy. The language for a label is identified using a tag, for example “en” is used to identify “English”.

Label Types link

In order to give a more complete definition of a taxonomy component, multiple labels can be provided. The way in which these should be understood is indicated by the label type. Taxonomies do not explicitly define where and how each label type should be displayed. The following are a few such labels types:

• Documentation: Explains the taxonomy component and its usage. Example: “The amount of liabilities related to the entity’s leases. A lease is a contract, or part of a contract, that conveys the right to use an underlying asset for a period of time in exchange for consideration.” (Documentation label for “Leases Liabilities”)

• Terse: Short label, assumes context from related concepts. Example: “Dividends paid” (Terse label for “Dividends paid, classified as financing activities”)

Labels That Control the Presentation of Taxonomy Elements link

The presentation tree has a mechanism (known as the preferred label mechanism) to show different labels for the same element at different points in the tree. In the example below, the same concept is used to give the balance at the beginning and the end of a period. A “period start label” and “period end label” are assigned to the concept and marked as the preferred label in the appropriate locations in the presentation tree. The standard label for the concept is “Property, plant and equipment”.

* Property, plant and equipment at beginning of period (period start label)
	* Increase (decrease) in property, plant and equipment
		* Additions, property, plant and equipment
		* Depreciation, property, plant and equipment
		* Decrease, property, plant and equipment
* Property, plant and equipment at end of period (period end label)

• “Total label” is used in a presentation tree as the preferred label when a different label is required to be displayed as the total of a set of other values. Example: “Total liabilities” (for the sum of current and non-current liabilities) is the total label for the concept “Liabilities”.

• “Negated label” is used in a presentation tree as the preferred label when the value is displayed with the opposite sign from how it is reported in XBRL. Example: “Finance Cost” is to be shown with a negative sign as it reduces total balance, so a “Negated” label is used which will flip the sign of the reported value.

Label Selection Based on the Sign of Reported Values link

The naming conventions of some taxonomy concepts may change depending on the sign of the reported value. For example, in the case of the concept “Profit (loss)”, if the value is positive it may be referred to simply as “Profit” and if it is negative it is referred to as “Loss”. Specific labels can be defined, such as “Positive label” or “Negative label” to be used in such cases.

The following is an extract from a taxonomy viewing tool, displaying the different labels assigned to the concept “Revenue”.

For more information about how labels work in XBRL, refer to the detailed guidance on label types, multilingual labels, and good standard labels.

References: Connecting Concepts to Standards and Regulation link

Taxonomy concepts often originate from an underlying authoritative literature or regulation. References in the taxonomy are typically used to provide links to the definition of taxonomy concepts in authoritative literature, such as the relevant accounting standard or reporting regulation.

References are a piece of structured information attached to a taxonomy component that provide a link to external information about the element. A taxonomy concept may have any number of references associated with it. Each reference is composed of a number of reference parts.

For example, the concept “Issued capital” may include 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

In this example “Name”, “Number” etc are called reference parts.

References are especially useful for regulators, auditors, and preparers who want to know what accounting rule or legal requirement supports a given data point.

Types of Reference link

Depending on the type of reference, they serve different purposes. The following table provides some of the reference types.

Structured Information in References link

Structured information or metadata about taxonomy concepts, for example, milestone information such as the effective date, deprecation date, or creation date; or the applicability of business type, form number, or report type relevant to taxonomy elements, can be provided in the taxonomy. Such structured information about taxonomy components is captured in key-value format using property references. For details see guidance on property references.

XBRL Formula Rules: Ensuring Data Logic and Validity link

While some relationships in a taxonomy are structural or descriptive, others help enforce data quality and logical consistency. Validation rules can be defined in the taxonomy using XBRL Formula Rules.

XBRL Formula Rules go beyond simple totals, allowing for conditions, thresholds, and logic that must be met for the data to be considered valid. These are validation rules, similar to spreadsheet checks that ensure formulas are correct or values fall within expected ranges.

Conformant XBRL software, (certified for conformance with XBRL specifications), will automatically apply formula rules as part of validation, making it easy for preparers to check reports prior to submission. By defining validation rules in the taxonomy using XBRL Formula Rules collectors avoid the possibility of misinterpretation of the rules by preparers and third-party software developers.

XBRL formula rules provide built-in features to work seamlessly with XBRL data, addressing XBRL-specific requirements such as selecting facts based on XBRL aspects, querying taxonomy relationships, and traversing XBRL dimensional models.

Examples of validation rules that can be defined as XBRL Formula Rules:

• “Revenue” is reported as a positive value
• “Current Period End Date” must be reported
• “Current Period End Date” is later than the date reported for “Current Period Start Date”
• “Property, Plant and Equipment” total value is an aggregation across its asset classes, modelled using dimensions
• Total at the end of a reporting period is equal to the total at the start of that period plus any changes that occur during the period

Key Components of XBRL Formula Rules link

• The Rule Name: An identifier for the rule that is used to provide an error code if it fails.

• The Test Expression: The logic that is evaluated in order to determine the outcome of the rule.

• Variables: Inputs to the test expression. For example, if the test expression performs an aggregation, variables are used to select the total and contributing facts from the XBRL report.

• Filters: Conditions that a fact must satisfy to be selected for rule testing. For example “concept filter = Revenue” ensures only facts which are reported against the “Revenue” concept are picked for test evaluation.

• Pre-conditions: Some rules require the prior evaluation of conditional validations. Preconditions define those prerequisites that are to be satisfied before validating the rule.

• Messages: Messages that can be displayed in the event of an evaluation failure (unsatisfied messages), in order to help understand the nature of the problem. XBRL formula rules also have a provision to define satisfied messages, which will be available to users on successful evaluation of a validation rule.

Read more about validating XBRL data in this article.

For more technical detail on how to design and implement XBRL Formula rules, see the XBRL International tutorial on formula rules.

Reporting Templates: Table Layout for Data Entry and Rendering link

Some business reports go well beyond the presentation of a simple linear hierarchy. Some reports are required to be presented in multidimensional tabular layouts familiar to business users and non-technical stakeholders. Reporting templates address this challenge by allowing taxonomy developers more flexibility in defining report presentations.

The reporting templates facilitate simple input of reported values when generating XBRL reports and clear rendering of the reported XBRL data for business users.

The following example illustrates a reporting template based on exposure disclosure by region. In this case, concepts for exposure types are organised in rows, while geographical regions appear as columns. This layout guides the preparer in capturing multidimensional data accurately and consistently, aligning each reported figure with its corresponding concept and regional breakdown.

Features of Reporting Templates

• Independent Modelling: Reporting templates are modelled independently of the dimensional modelling of the underlying data points. This allows software to present a familiar, user-friendly view of the template while maintaining a logical and consistent data model.

• Custom Labelling: Reporting templates can define custom labels for rows and columns. There is no requirement to use the standard labels defined for concepts and dimensions in the taxonomy. Standard labels are often lengthy due to the need for uniqueness across the entire taxonomy. In contrast, templates can use shorter, context-specific labels that enhance readability.

• Open Tables: Reporting templates can define open tables, meaning that the number of rows, columns, or sheets is not fixed. This is useful when the number of records, reporting periods, or currencies is variable or unknown, allowing users the flexibility to expand the template as needed.

• Reuse of Relationships: Reporting templates can leverage relationships defined elsewhere in the taxonomy to build parts of the template. For example, a hierarchy of primary elements defined in a presentation tree can be referenced and reused, avoiding the need to redefine the structure.

Taxonomy Key Terms link

Entry Point: Targeting the Right Part of the Taxonomy link

Taxonomies can be large and complex, covering a wide range of reporting needs. To make them easier to use, they are often divided into entry points, each one defining a specific subset of the taxonomy that corresponds to a particular reporting scenario.

An entry point is essentially a starting package made up of selected data definitions and relationships that focus on the concepts and rules relevant to a given requirement. It tells reporting software to start at the portion of the taxonomy that applies to the report.

Entry points make taxonomies easier to use. Instead of requiring preparers or systems to load the entire taxonomy, entry points allow them to focus only on the specific subset relevant to their reporting needs. This improves performance and reduces complexity, particularly when a taxonomy covers multiple use cases or reporting domains.

For regulators, entry points offer a practical way to define different reporting profiles, such as one for individual entities and another for consolidated groups, without having to duplicate the full taxonomy structure. This modularity makes taxonomies more adaptable and easier to implement across diverse scenarios.

The following is an example of a sustainability taxonomy that includes one entry point for environmental disclosures and another for social indicators.

Whether for financial reporting (e.g., individual vs consolidated statements) or sustainability disclosures (e.g., environmental vs social indicators), entry points help preparers and systems work with only the relevant portion of a taxonomy. This improves usability, streamlines validation, and ensures reports are aligned with regulatory or domain-specific requirements.

Taxonomy Packages: Delivering everything in one place link

Taxonomies are made up of many technical components: schemas, linkbases, labels, references, templates, documentation, and more. Taxonomy packages make all of these files easier to gather together in a standardised way.

Taxonomy packages include not only technical files, but also essential metadata, such as the taxonomy’s name, version, release date, publisher information, and defined entry points. This metadata enables systems to automatically identify, load, and apply the correct components with minimal configuration.

Taxonomy files are usually hosted online and need an internet connection. Taxonomy Packages offer a workaround called remapping, which redirects online paths to local ones, enabling offline access and helping software locate taxonomy files locally.

A taxonomy package simplifies how taxonomies are shared, updated, and applied. Instead of relying on scattered files across folders or URLs, preparers and systems can access a central package that delivers the complete taxonomy in a consistent format.

For preparers, taxonomy packages provide a ready-to-use set of resources. For software tools, they offer automatic detection of structure and entry points. And for regulators and publishers, they ensure greater control over taxonomy versioning and updates.

Read more about taxonomy packages in this guidance and here.

Namespaces and Identifiers link

Every taxonomy element must be uniquely identified to avoid confusion, especially when multiple taxonomies or extensions are used together. This is achieved using namespaces, which act like digital surnames, and identifiers, which distinguish each element individually.

The elements defined in the ISSB 2024 taxonomy carry the namespace “https://xbrl.ifrs.org/taxonomy/2024-04-26/ifrs-sds". In XBRL, this namespace is typically shortened using a prefix, such as ifrs-sds, to make references more concise.

For instance, the IFRS taxonomy may define “ifrs:Revenue”, while a local regulatory taxonomy might define “reg:Revenue”. Although both use the label “Revenue”, the prefixes ifrs and reg, which represent their respective namespaces, ensure that software tools do not confuse one for the other.

Taxonomy Extensions link

Extension is a key capability of XBRL. Taxonomies defined by reporting standard-setters (e.g., IFRS Taxonomy) can be extended by data collectors to include specific reporting items—these are known as regulatory extensions.

Companies can also extend the taxonomy to report entity-specific disclosures.

The starting point used to extend a taxonomy is called the base taxonomy. Relevant elements and relationships from it are reused to build the extension taxonomy.

Base taxonomy owners provide guidance on how their taxonomies can be extended, while the scope of extension for companies is determined by data collectors.

Summary link

In digital reporting, a well-structured taxonomy does more than just define data, it specifies how information is organised, validated, and understood by both systems and stakeholders. Each component, from schemas and relationships to labels and templates, plays a specific role in ensuring that the reported data is not only accurate but also meaningful and comparable.

By adopting and properly understanding these components, organisations can move beyond basic compliance to achieve more efficient, transparent, and reliable reporting practices. Taxonomies become a foundation for trust in data exchange, empowering regulators, preparers, and users alike to speak a common digital language.