XBRL Tagging for CSRD Sustainability Reports: What You Need to Know

CSRD does not just require sustainability disclosure — it requires that disclosure in a machine-readable digital format. Specifically, sustainability reports filed under CSRD must be tagged using inline XBRL (iXBRL) and packaged as an ESEF (European Single Electronic Format) reporting package, using the ESRS XBRL taxonomy published by EFRAG.

For most sustainability teams, this is the single most confusing part of CSRD compliance. Understanding GHG accounting or Double Materiality Assessment is difficult but conceptually familiar. XBRL tagging is a technical format requirement that sits at the intersection of accounting, IT, and regulatory filing — and most teams have never encountered it before.

This guide explains what XBRL tagging is, what CSRD specifically requires, and how to prepare without getting lost in the technical details.

What Is XBRL?

XBRL (eXtensible Business Reporting Language) is an open data standard for business and financial reporting. It allows individual data points in a report — a revenue figure, an emission total, a board composition metric — to be tagged with a machine-readable label that identifies exactly what the number represents, what period it covers, and what entity it belongs to.

XBRL has been used in financial reporting for over a decade. The US SEC, European securities regulators (via ESEF), and many Asian filing authorities already require financial statements in XBRL format. CSRD extends this requirement to sustainability reporting.

XBRL vs iXBRL

  • XBRL: a data format (XML-based) that encodes tagged data points. Not human-readable.
  • iXBRL (inline XBRL): an HTML document with XBRL tags embedded directly in the human-readable report. You see a normal sustainability report in your browser; a machine sees structured, tagged data underneath.

CSRD requires iXBRL — your sustainability report must be readable by humans and machines simultaneously.

What Is ESEF?

The European Single Electronic Format (ESEF) is the regulatory framework that mandates how listed companies file annual reports with EU securities regulators. ESEF requires:

  1. The annual report in XHTML format
  2. Financial statements tagged with iXBRL using the IFRS taxonomy
  3. A reporting package (ZIP) containing the XHTML file, taxonomy extension schemas, and linkbase files

CSRD extends ESEF to include sustainability reporting. The sustainability section of your annual report must be tagged with iXBRL using the ESRS taxonomy (not the IFRS taxonomy used for financial data).

The ESRS XBRL Taxonomy

EFRAG has published the ESRS XBRL taxonomy, which provides standardised tags for every disclosure requirement across all ESRS standards. The taxonomy covers:

  • ESRS 2 (General Disclosures): governance structure, strategy, IRO management, metrics
  • ESRS E1–E5 (Environmental): GHG emissions by scope, energy consumption, water withdrawal, biodiversity metrics, circularity rates
  • ESRS S1–S4 (Social): workforce metrics, pay gaps, health and safety rates, value chain due diligence
  • ESRS G1 (Governance): anti-corruption, political engagement, payment practices

Each tag has a unique identifier, a data type (monetary, percentage, text block, boolean), and a position in the taxonomy hierarchy. When you tag your sustainability report, each data point gets linked to its corresponding taxonomy element.

Extension Taxonomy

Not every disclosure fits a standard tag. Companies may need to create extension elements for:

  • Company-specific KPIs not covered by the base ESRS taxonomy
  • Industry-specific metrics (e.g., sector-specific SASB-aligned disclosures reported voluntarily)
  • Narrative sections with custom topic structures

Extension elements must follow XBRL naming conventions and include proper linkbase files (presentation, label, definition) so that validators and regulators can interpret them correctly.

What CSRD Filing Actually Requires

Here is the concrete output you need to produce:

1. An iXBRL-Tagged Sustainability Report

Your sustainability report — the actual narrative with tables, charts, and text — must be an XHTML document with iXBRL tags embedded around every reportable data point. This is not a separate data file; it is the report itself, with invisible markup that machines can parse.

2. An ESEF Reporting Package

The tagged report must be wrapped in a ZIP package containing:

  • report.xhtml — the iXBRL-tagged sustainability report
  • reportPackage.xml — metadata about the package
  • Extension taxonomy files (if any custom tags are used)
  • Linkbase files — presentation, calculation, definition, and label linkbases
  • catalog.xml — mapping of taxonomy namespaces to local file paths

3. Validation

Before filing, the ESEF package must pass validation checks:

  • Taxonomy validation: every tag maps to a valid ESRS taxonomy element
  • Calculation consistency: tagged numbers that have defined calculation relationships must be consistent
  • Filing rules: ESMA-specific filing rules applied to the package structure

Tools like Arelle (open-source XBRL processor) are commonly used for validation.

Common Pitfalls

1. Treating XBRL as an Afterthought

The most expensive mistake: writing your sustainability report in Word or PDF, then trying to "tag it" after the fact. This creates a manual mapping exercise where someone must identify every taggable data point and match it to the taxonomy — often under deadline pressure, with errors.

Better approach: use a report editor that maps to the ESRS taxonomy natively, so tags are applied as you write.

2. Ignoring Text Block Tags

XBRL is not only for numbers. The ESRS taxonomy includes tags for narrative disclosures — transition plan descriptions, governance role definitions, due diligence process descriptions. These "text block" tags are required and frequently missed.

3. Wrong Periods and Dimensions

Every XBRL fact needs a context: the reporting period, the reporting entity, and any dimensional breakdowns (e.g., Scope 1 vs Scope 2 vs Scope 3 emissions). Tagging a Scope 2 figure with a Scope 1 dimension makes the data meaningless to machines — even if the human-readable report is correct.

4. Extension Overuse

Creating extension elements when a standard taxonomy tag exists is a red flag for validators and auditors. It suggests the preparer did not understand the taxonomy. Use extensions only when genuinely necessary.

How to Prepare

Step 1: Understand Your Tagging Scope

Start with your Double Materiality Assessment — see our full DMA guide for the step-by-step process. Only material topics require full ESRS disclosure — and therefore XBRL tagging. If E3 (Water) is not material, you do not need to tag E3 metrics (though you must tag the disclosure explaining why it is not material).

Step 2: Assess Your Current Readiness

Use our CSRD Readiness Checker to evaluate your data infrastructure and framework coverage. A low score on "data infrastructure" or "framework coverage" is a strong signal that XBRL tagging will be difficult until those foundations are in place.

Step 3: Choose the Right Tool

Manual XBRL tagging in a text editor is theoretically possible but practically insane. You need a tool that either:

  • Generates iXBRL natively — the report editor produces tagged XHTML as you write, with taxonomy element selection built into the authoring workflow
  • Converts from structured data — the tool exports XBRL from a structured database of ESG metrics, generating the ESEF package automatically

Emistra's report editor takes the first approach: ESRS-aligned report templates with iXBRL tag visualisation built directly into the editor. Tags are applied as content is created, not retrofitted afterwards. The ESEF package — including extension schemas, linkbases, and validation — is generated automatically on export.

Step 4: Validate Early and Often

Do not wait until filing day to validate your ESEF package. Run validation against the ESRS taxonomy early in the process, fix any taxonomy mapping issues, and validate again after each significant edit cycle. Piecemeal validation catches errors when they are cheap to fix.

Limited Assurance and XBRL

Under CSRD, sustainability reports require limited assurance from an approved auditor. The auditor reviews both the substance of disclosures and the accuracy of tagging. Common assurance findings related to XBRL include:

  • Tags mapped to wrong taxonomy elements
  • Missing tags for required disclosures
  • Calculation inconsistencies between tagged values
  • Extension elements used instead of available standard tags
  • Period/dimension errors

Under the Omnibus Directive's revised timeline, reasonable assurance (a stricter standard with more testing) is targeted from FY2028. Audit-ready XBRL tagging becomes even more critical as assurance standards tighten.

The Bottom Line

XBRL tagging is a technical requirement with real compliance consequences. It is not something to solve in the last week before filing. The companies that handle it well share three characteristics:

  1. They use a tool that generates iXBRL natively — not a bolted-on export from PDF or Word
  2. They validate continuously — not once at the end
  3. They align tagging with their DMA — only material topics get full disclosure, reducing the tagging surface to what is actually required

Emistra generates audit-ready iXBRL/ESEF packages directly from its report editor, with ESRS taxonomy mapping built in, extension schema generation, linkbase files, and Arelle validation. Explore the platform →