Components of an XBRL Report

Learning Objectives link

• Explore the components of an XBRL report
• Distinguish between data and metadata in an XBRL report
• Identify the relationship between an XBRL taxonomy and the XBRL report
• Understand entity-specific disclosures in XBRL reports
• Understand ways of creating different XBRL report formats

Introduction link

XBRL reports play a pivotal role in digital reporting by transforming static disclosures into machine-readable, validated data. They enable automation, enhance comparability, and support more agile regulatory oversight, bridging the gap between preparer intent and supervisory analysis.

The interaction between XBRL taxonomies and XBRL reports (technically known as instance documents) forms the foundation of structured and meaningful data exchange. Taxonomies provide the framework for data definitions, relationships, and validation rules, while XBRL reports contain business facts aligned with these structures. This ensures consistency, reliability, and transparency in regulatory disclosures, ultimately strengthening decision-making by stakeholders.

This section explores the structure of XBRL reports and their relationship with taxonomies. It highlights how taxonomies govern the creation and interpretation of XBRL report documents, and emphasises the distinction between data and metadata, underscoring how both elements are essential for clear interpretation and accurate regulatory analysis.

What Does an XBRL Report Actually Contain? link

Before exploring the technical detail of XBRL reports, it helps to begin with a simple visual example. The image below is taken from an Inline XBRL report, and shows a real financial report enriched with structured data.

Although it appears to be a typical financial statement, each reported value is digitally tagged with machine-readable metadata that gives it context and meaning.

This example uses the Inline XBRL format, which preserves visual presentation, although not all XBRL formats are human-readable.

The Human-Readable Report link

On the left side of the document, the visual presentation of a financial statement is shown. In this example, the amount “942,024” corresponds to the line item “Cash and cash equivalents” as of 30 June 2023.

However, unlike static reports, this version embeds structured data tags within the text, allowing each value to be interpreted by machines while preserving the familiar visual layout for humans.

The Digital Structure Behind Each Fact link

On the right side, a fact properties panel displays the metadata associated with the selected value. This includes:

• The reporting date, specified as “30 June 2023”.
• The reported value “942,024”, referred to as “Fact Value”.
• Although shown alongside the currency (USD) in this example, the currency and value are reported separately in the underlying data structure.
• The accuracy of the fact value, in this case it is defined as “0” because the reported value is unscaled and represents the exact amount. When reported values are scaled (for example, in thousands or millions to enhance readability), the accuracy specifies the degree of rounding applied to the reported value.
• The “Change” value shown in the image is a derived figure that compares current and previous reports. It is not part of the metadata defined in the XBRL report.
• The reporting entity, identified using a Legal Entity Identifier (LEI).
• The taxonomy concept used by the fact. In this case, the concept is us-gaap:CashAndCashEquivalentsAtCarryingValue, which defines the item being disclosed and is from the US GAAP taxonomy.

Structure of a Fact: Data and Metadata link

In XBRL, each fact combines the fact value with metadata that defines its meaning and application. A fact consists of two core components:

• Fact value: the actual figure or text being reported (the data).
• Metadata (dimensions): a combination of the entity reporting the data, the reporting period, the concept used, the unit of measure, and any dimensional qualifiers.

This structure ensures that each fact is clearly defined and machine-interpretable. Contexts are especially critical when comparing reports across time or between organisations, as they describe the specific conditions under which each value applies.

Facts in an XBRL Document link

Beyond visual and conceptual representations, XBRL facts also exist in structured technical formats.

The following snippet demonstrates how a single fact is represented in xBRL-JSON format. In this example, “Revenue” is reported as EUR 49,199 thousand for the reporting period of 2024:

{
"fact_001": {
  "value": "49199000",
  "decimals": -3,
  "dimensions": {
    "concept": "ifrs-full:Revenue",
    "entity": "scheme:FAKE0012345678901274",
    "period": "2024-01-01T00:00:00/2025-01-01T00:00:00",
    "unit": "iso4217:EUR"
  }
}
}

This fact includes the following components:

• Value: The fact value reported as “49199000”.

• Decimals: Indicates the accuracy or precision of the reported value. A value of -3 means the number has been rounded to the nearest thousand.

• Concept: The taxonomy-defined meaning of the fact (ifrs-full:Revenue). This reference combines two parts:

  • “ifrs-full” is the namespace, identifying the IFRS taxonomy;
  • “Revenue” is the concept, which has a formal definition in the taxonomy.
  • Together, they point to a precise and standardised meaning.

• Entity: The reporting entity identified by its Legal Entity Identifier (LEI), in this case FAKE0012345678901274.

• Period: The time frame to which the fact relates. The period is expressed in ISO 8601 format, including start and end dates separated by a slash.

• Unit: Indicates the currency or unit in which the fact is reported. Here, iso4217:EUR denotes that the value is expressed in euros, following the ISO 4217 currency code standard. Units are only specified for numerical concepts.

• Each fact in an xBRL-JSON report has a unique ID. In this case, it is “fact_001”.

Each component aligns with the conceptual explanation provided earlier: a fact is always accompanied by metadata, allowing it to be processed reliably by both humans and systems.

This xBRL-JSON representation of an XBRL fact is compact and easy to understand. While different XBRL formats use different structures to represent facts, they all provide the same level of metadata.

A Fact Reported for a Specific Category (Dimension and Member) link

Some reported values in XBRL refer to particular categories or breakdowns that give the data more meaning. For example, financial concepts such as “Equity” can be disaggregated to show the portions that come from issued capital, retained earnings, or other components. These portions are known as domain members.

The example below shows a value for “Equity”, specifically limited to the “Issued Capital” portion, as reported for the year 2024 in euros:

{
"fact_120": {
  "value": "71354000",
  "decimals": -3,
  "dimensions": {
    "concept": "ifrs-full:Equity",
    "entity": "scheme:FAKE0012345678901274",
    "period": "2024-01-01T00:00:00",
    "ifrs-full:ComponentsOfEquityAxis": "ifrs-full:IssuedCapitalMember",
    "unit": "iso4217:EUR"
  }
}

Here, the reported value is 71,354,000 euros, rounded to the nearest thousand. It pertains to “Issued Capital”, a specific component of the broader “Equity” concept. This classification is captured using an additional dimension:

{
"ifrs-full:ComponentsOfEquityAxis": "ifrs-full:IssuedCapitalMember"

}

This dimensional tag indicates that the fact relates specifically to “Issued Capital” within the “Components of Equity Axis”. The IFRS taxonomy, like many others, adopts a naming convention where taxonomy elements are assigned descriptive names. Dimension and domain member elements often include suffixes such as “Axis” and “Member” to improve clarity. However, this naming convention is not required by the XBRL specification, and other taxonomies may employ different naming styles.

Taxonomy-Driven Structure of XBRL Reports link

XBRL taxonomies serve as active rulebooks that structure digital reporting. They define the reporting vocabulary (dictionary), establish relationships among concepts, and introduce validation rules to ensure that data is both meaningful and consistent.

XBRL reports apply these rules in practice. Each fact in a report is linked to a taxonomy-defined concept and is submitted with precise context: who is reporting it, for which period, in what unit, and under what breakdown or dimension. This ensures that each data point is understandable, comparable, and properly located within a broader analytical structure.

The relationship is similar to a regulated digital form: the taxonomy defines each field and its expected characteristics, while the XBRL report contains the completed answers. Below is a simplified textual illustration of this idea:

Example of Preparer Aubmissions - Analogy to XBRL Reports Aligned to the Same Structure link

Each cell represents a reported fact aligned to the structure defined by the taxonomy. Despite differences in values, the consistent format ensures comparability and reliability.

These examples demonstrate how each reported fact is not just a number, but a structured data point enriched with metadata that gives it context, comparability, and clarity. Although the facts in this example are numerical, XBRL supports a range of data types, including text, dates, booleans, and others, depending on the specific requirements of the disclosure.

Taxonomy-Derived Validation Rules link

The taxonomy defines the structural and semantic constraints governing valid XBRL reports. Key validation principles include:

• Concept Validity: Reported facts must refer to a concept that is defined in the taxonomy.

• Data Type Conformance: Fact values must comply with the base data type of the associated concept (e.g., monetary concepts require numeric values consistent with the specified decimal precision; string values are invalid for numeric types).

• Period Type Consistency: The period type attribute of each concept dictates whether facts are reported for an instant (single date) or a duration (start and end dates). Validation ensures alignment between the fact’s period structure and the concept’s period type.

• Unit Specification: For numeric concepts (e.g., monetary, shares, or pure types), a valid unit must be specified. The unit must conform to the expected measure as defined by the concept type and taxonomy constraints (e.g., iso4217:EUR for monetary amounts).(See the Unit Registry).

• Explicit Dimension Constraints: Explicit dimensions can only be applied where valid domain-member relationships are defined within the taxonomy’s dimensional model, where those dimensions are applicable. Invalid combinations (e.g., applying Components of Equity Axis to the Revenue concept) are rejected by dimensional validation rules.

• Typed Dimension Constraints: For typed dimensions, preparers specify domain member values directly in the XBRL report, following the data type and pattern constraints defined for the typed dimension in the taxonomy. Validation rules also check for invalid combinations of typed dimensions and concepts.

• Content Validity: In addition to structural validations, taxonomies may define simple total checks through calculation trees and advanced validation rules using XBRL Formula Rules. These allow XBRL reports to be tested against complex assertions, cross-concept consistency, and business logic constraints during validation.

XBRL Reports with Taxonomy Extensions link

In some open reporting environments, preparers may be allowed or required to introduce taxonomy extensions to capture entity-specific disclosures that are not fully covered by the base taxonomy. When creating XBRL reports that include extension concepts, the preparer must define an extension taxonomy, which specifies the new concepts, their data types, labels, dimensional structures, and relationships to existing base taxonomy elements.

The process of extending a taxonomy is typically governed by the regulator’s filing rules, which specify the conditions, scope, and constraints under which extensions may be introduced to ensure consistency and comparability. Read here more about filing rules.

Representation of Facts Across Different XBRL Report Formats link

The XBRL specifications provide multiple, interoperable formats for representing XBRL reports to address different use cases. While all formats preserve the same logical structure — facts linked to taxonomy-defined concepts with associated metadata — their syntax and technical structure vary significantly. This variation influences how reports are created, validated, and consumed. Some formats focus on machine-readability, while others combine human and machine interpretation.

The different XBRL report formats are:

• xBRL-XML: The conventional XML format, widely supported by existing tools, suitable for small to medium data volumes in closed reporting environments where infrastructure reuse is important.

• Inline XBRL (iXBRL): Combines human-readable presentation and machine-readable tagging, ideal for open reporting environments where both readability and structured data extraction are required.

• xBRL-JSON: A compact, developer-friendly JSON-based format that simplifies data publication and integration, well-suited for small to medium reports and modern data platforms.

• xBRL-CSV: An efficient, CSV-based format optimised for large-scale tabular data collection, in closed reporting environments.

Read about choosing between different XBRL report formats in this article.

Approaches for Creating XBRL Reports link

XBRL reports can be created through several different approaches, depending on the reporting environment and the format being used:

• Template-driven data entry: Structured input templates guide preparers to capture data in a controlled format, which is then converted into valid XBRL reports (commonly in xBRL-XML).

• Source system exports: Reports are automatically generated from existing systems such as ERP, data warehouses, or prudential reporting platforms, ensuring consistency with taxonomy definitions. Depending on the reporting setup, these exports may produce XBRL reports in xBRL-CSV xBRL-XML, or xBRL-JSON formats.

• Tagging of human-readable reports: For Inline XBRL, preparers apply XBRL tags to formatted reports (e.g., annual reports), embedding structured metadata into the human-readable content. Tagging may be manual, software-assisted, or fully automated.

A list of XBRL International certified XBRL report creation software is available on this certification page.

Summary link

XBRL reports combine business facts with clear, structured metadata to make financial and regulatory data easy for both humans and machines to understand. Using taxonomies, each reported fact is linked to a well-defined concept, along with details like who reported it, for which period, in what currency, and under which category. This structure helps ensure the data is accurate, comparable, and can be automatically checked for errors. With different formats like xBRL-XML, Inline XBRL, xBRL-JSON, and xBRL-CSV, XBRL supports a wide range of reporting needs — from simple filings to large-scale data collection — while keeping the meaning of data consistent and reliable.