ESEF reporting: iXBRL under IFRS for listed companies

ESEF (European Single Electronic Format) is the mandatory electronic format for the annual financial reporting of issuers on regulated markets in the EU. The entire annual report is prepared in XHTML; where it contains consolidated financial statements under IFRS, the figures and notes are additionally marked up with Inline XBRL (iXBRL) using the ESEF taxonomy. In the Netherlands, issuers file their ESEF report with the AFM. The regime is separate from the regular filing obligation at KVK (the Dutch Chamber of Commerce), although the two worlds are technically converging.

Key facts

• For whom: issuers whose securities are admitted to trading on a regulated market in the EU, such as Euronext Amsterdam.

• Legal basis: Commission Delegated Regulation (EU) 2019/815, a regulatory technical standard (RTS) under the Transparency Directive, updated annually by the European Commission on a draft from ESMA.

• Format: the full annual report in XHTML; the IFRS consolidated financial statements marked up with iXBRL and submitted as a single report package.

• Taxonomy: the ESEF taxonomy, an extension of the IFRS Accounting Taxonomy maintained by the IFRS Foundation; a new version every year.

• Introduction in the Netherlands: detailed tagging of the primary statements mandatory from financial year 2021 (the Netherlands used the deferral option for financial year 2020); block tagging of the notes from financial year 2022.

• Entity identification: the LEI (Legal Entity Identifier), which Dutch entities can obtain from KVK.

• Supervision in the Netherlands: the Dutch Authority for the Financial Markets (AFM).

What is ESEF?

ESEF stands for European Single Electronic Format. The standard was developed by the European Securities and Markets Authority (ESMA) to make the annual financial reports of listed companies across the EU machine-readable and comparable. Before ESEF, each issuer published its annual report in its own format, ranging from PDF to Word, which made automated comparison and analysis nearly impossible.

ESEF solves this with two obligations. First, the entire annual report is prepared as an XHTML document, readable in any browser. Second, where the report contains consolidated financial statements under IFRS, the figures and notes are provided with embedded XBRL tags. That is exactly what Inline XBRL (iXBRL) does: one file that is both human-readable and machine-processable. The tags refer to concepts from the ESEF taxonomy, so every amount is labelled the same way regardless of country of origin.

Who does the ESEF mandate apply to?

The XHTML obligation applies to all issuers that must make an annual financial report generally available under the Transparency Directive. The additional iXBRL tagging obligation applies only when two cumulative conditions are met:

• The company's securities are admitted to trading on a regulated market in the EU (such as Euronext Amsterdam).

• The annual report contains consolidated financial statements prepared in accordance with IFRS as adopted by the EU.

Issuers that only prepare stand-alone financial statements, or that report under a national GAAP, therefore do not need to tag, but they must still publish their annual report in XHTML. According to the AFM, tagging is not even permitted for reporting frameworks other than IFRS. Companies from outside the EU with a listing on a Dutch regulated market are also in scope of ESEF.

Non-listed companies fall entirely outside ESEF: they file their annual accounts with KVK via SBR (Standard Business Reporting) based on the Dutch taxonomy. Do not confuse the two regimes; see the comparison later in this article.

What must be tagged — and since when?

The ESEF mandate was introduced in phases. The Netherlands used the European member-state option (a COVID-19 measure) to postpone first application by one year; that deferral did not apply to the block tagging of the notes.

Detailed tagging means that every amount in the four primary statements — statement of financial position, statement of profit or loss and other comprehensive income, statement of cash flows, and statement of changes in equity — receives its own XBRL tag referring to a concept in the ESEF taxonomy, or to a company-specific extension anchored to the taxonomy. This includes the correct period, currency unit, scale, and sign.

Block tagging means that entire note disclosures, for example the accounting policies or the revenue note, are marked up as one text block with an XBRL tag. A machine can then retrieve exactly which type of information sits where, even if the individual figures inside that block are not tagged separately. A block tag may contain text, amounts, and tables.

Which taxonomy version applies to your financial year?

The ESEF taxonomy is updated annually to stay aligned with the IFRS Accounting Taxonomy of the IFRS Foundation. Each update is enacted through an amendment of the RTS. Always use the taxonomy entry point that matches the financial year; a wrong version leads to validation errors.

The 2025 update additionally requires that both the iXBRL instance document and the extension taxonomy are valid under the Calculations 1.1 specification, XBRL's more modern calculation-checking rules. The 2025 taxonomy also already contains elements for IFRS 18 and IFRS 19; those elements may only be used once these standards have been formally endorsed in the EU. ESMA has furthermore consulted on a revision of the mark-up rules for the notes and on extending ESEF tagging to sustainability reporting; follow ESMA and AFM publications for the current state.

Extensions and anchoring

The ESEF taxonomy covers the common IFRS presentation lines, but not every issuer uses the same structure. If a company reports a line item that does not exist in the standard taxonomy, it may create an extension: a custom XBRL concept that applies specifically to that issuer.

Extensions used in the primary statements are subject to an anchoring obligation (anchoring): the extension is linked to the closest wider concept in the ESEF taxonomy. Where an extension combines two or more standard concepts, it must additionally be anchored to each of those narrower concepts. Two exceptions apply: a pure subtotal of other lines in the same statement does not need a wider anchor (but must still participate in the calculation structure), and extensions used only in the notes do not need to be anchored.

An example: an airline reporting the line "flight equipment" creates an extension for it and anchors it to the wider IFRS concept for property, plant and equipment. Data aggregators and regulators can then still place the company-specific line within the standard structure. The AFM advises keeping the use of extensions to a minimum: every extension reduces comparability.

Entity identification: the LEI

Every ESEF filing identifies the reporting entity with the LEI (Legal Entity Identifier), a globally unique 20-character code under ISO 17442. In ESEF, the LEI replaces national identification codes: where an SBR filing at KVK uses the KVK number, an ESEF report refers to the issuer's LEI. Without a valid LEI, the AFM portal will not accept the filing.

In the Netherlands, the LEI can be requested from KVK, which as an issuing organisation meets the requirements of the Global Legal Entity Identifier Foundation (GLEIF). An application costs EUR 80 and the code must be renewed annually (EUR 49.20); a non-renewed LEI receives the status "lapsed" and is then no longer valid for the filing. Check the status of the LEI well before the filing deadline.

Filing with the AFM

Dutch issuers make their ESEF report generally available through the AFM's filing portal. The file must at minimum meet these technical requirements:

• no executable code in the document;

• a valid LEI code for the company;

• a maximum file size of 100 MB;

• correct XML, XHTML, and iXBRL specifications;

• the iXBRL instance document and the extension taxonomy submitted together as a single report package under the Report Packages 1.0 specification.

On submission, the portal generates a validation report. An ERROR can lead to rejection of the file or to further investigation by the AFM; a WARNING calls for your own assessment, for example whether a mandatory mark-up is genuinely missing. In practice, an incorrectly constructed report package is a common cause of rejected filings — so test the package with an ESEF validator beforehand.

Supervision and common errors

The AFM supervises compliance with the ESEF requirements and can take enforcement action in the event of non-conformity. The external auditor also checks compliance with the ESEF Regulation and reports on it in the auditor's report. In addition, the AFM periodically publishes points of attention; its exploratory review of 2023 reporting highlighted, among others, the following:

• Sign and scale: check that tagged amounts carry the correct direction (positive or negative) and scale; an error here leads to misinterpretation of the figures.

• Consistent linkbases: the relationships between elements (presentation, calculation) must be complete and consistent with the human-readable financial statements.

• Limit extensions: use an extension only when the standard taxonomy genuinely does not cover the item, and anchor it correctly.

• Package structure: a mistake in the structure of the report package leads to rejection at upload.

The correct application of ESEF is also one of the European common enforcement priorities that ESMA publishes annually and that the AFM follows in its supervision.

The difference with KVK filing (Dutch GAAP / SBR)

ESEF and the Dutch filing obligation are two separate regimes, each with its own legal basis, taxonomy, and filing counter:

The two worlds are converging, though. From financial year 2025, all size classes — including large legal entities, are required to file their annual accounts electronically with KVK, and the SBR Business Register domain supports, alongside XBRL, an iXBRL report package that follows the ESEF rules as closely as possible. Issuers in scope of ESEF can moreover file their ESEF report directly with the Business Register, supplemented with a few mandatory Dutch data elements.

For a Dutch listed company this means, in practice: the IFRS consolidated financial statements fall under ESEF and go to the AFM; the statutory publication at the Business Register continues to exist alongside it, but can increasingly be served with the same iXBRL file.

Frequently asked questions

What is ESEF?

ESEF stands for European Single Electronic Format: the mandatory electronic reporting format for the annual financial reporting of issuers on regulated markets in the EU. The annual report is prepared in XHTML; IFRS consolidated financial statements within it are marked up with Inline XBRL using the ESEF taxonomy.

From which financial year does ESEF apply in the Netherlands?

The EU starting point was financial year 2020, but the Netherlands used the European deferral option: Dutch issuers are required to report in ESEF from financial year 2021. Block tagging of the notes is mandatory from financial year 2022; that component was outside the deferral.

Which companies must report in ESEF?

All issuers with securities on a regulated market in the EU prepare their annual report in XHTML. The iXBRL tagging obligation applies only to those that include consolidated financial statements under IFRS. Non-listed companies fall outside ESEF; for them, the KVK filing via SBR applies.

What is the difference between ESEF and iXBRL?

ESEF is the regulation, iXBRL the technical format. ESEF prescribes that issuers publish their annual report in XHTML with embedded XBRL tags; iXBRL (Inline XBRL) is the technical standard that makes this possible: one file usable by both human readers and automated systems.

Does ESEF require extensions and anchoring?

Extensions are permitted when the standard taxonomy does not cover an item. Extensions in the primary statements must be anchored to the closest wider ESEF concept; combination extensions also to each narrower base concept. Pure subtotals and extensions used only in the notes are exempt from (wider) anchoring. The AFM advises keeping extensions to a minimum.

Doc2iXBRL for ESEF reporting

Doc2iXBRL supports issuers and their advisors in converting the approved annual report into an ESEF-compliant iXBRL file. The platform converts PDF or Word documents into tagged XHTML, proposes AI-based mapping suggestions from the ESEF taxonomy, and validates the result with Arelle plus proprietary pre-filing checks, including a check for missing anchoring. The reviewer stays in control of every tag and every extension; ESMA or AFM acceptance is not guaranteed. Read more on the page about ESEF reporting with Doc2iXBRL.

Sources

• esma.europa.eu — Electronic Reporting: overview of the ESEF mandate, the taxonomy, and the ESEF Reporting Manual.

• EUR-Lex — Commission Delegated Regulation (EU) 2019/815: the RTS establishing the ESEF format.

• EUR-Lex — Commission Delegated Regulation (EU) 2026/283: the 2025 taxonomy update, mandatory for financial years starting on or after 1 January 2026.

• afm.nl — Annual reporting in ESEF: technical filing requirements and the validation report of the AFM portal.

• afm.nl — Points of attention for applying ESEF: findings from the AFM review of ESEF in 2023 reporting.

• officielebekendmakingen.nl — Parliamentary letter on the ESEF deferral: the Dutch choice for the member-state option (first mandatory financial year 2021).

• kvk.nl — Legal Entity Identifier (LEI): requesting and renewing an LEI at KVK.

• sbr-nl.nl — RTS for the SBR Business Register domain: iXBRL report packages and the overlap with ESEF at the Business Register.