The tagging requirements under ESEF are deepening step by step. The primary statements carry detailed tags, the notes have been block-tagged since financial year 2022, and a proposal for detailed tagging of those same notes is on the table. Each deepening step hits the two ways of working in a different place: in a conversion routine the tagging is anchored to the layout of a finished document; in a process that reports from structured data it is anchored to the source. That difference is not a matter of execution but of architecture, and it becomes more visible with every step.
What is block tagging?
An ESEF annual report is filed in its entirety as an XHTML document; within it, the iXBRL tags sit on the consolidated IFRS financial statements. Figures and text from those statements are made machine-readable with elements from a taxonomy, following the Inline XBRL principle of one document that both people and machines can read. That tagging comes in two depths.
- Detailed tagging — every amount in the reported currency gets its own element from the taxonomy. This is how the consolidated primary statements are tagged: balance sheet, statement of profit or loss and other comprehensive income, cash flow statement, statement of changes in equity.
- Block tagging — an entire section of the notes is tagged as a text block: the accounting policies, an individual note. One block is not the same as one tag. The ESEF Reporting Manual (opens in a new tab) asks for both the wider and the narrower element where both apply, and tables inside a note get their own block tag. The section becomes findable and machine-readable as a whole; the individual figures inside it are not yet tagged separately.
Block tagging is therefore a waypoint between “not tagged” and “fully detailed-tagged”, which is exactly why it is the right place to look at the trajectory as a whole.
The ESEF trajectory: from statements to notes
The sequence so far shows one movement. First the primary statements were detailed-tagged, from financial year 2020. Since financial year 2022, block tagging of the notes has been added — four reporting cycles by now. The next step has not been settled. In December 2024, ESMA (opens in a new tab) put a proposal in two phases out for consultation.
- Phase 1 lets the text blocks follow the notes’ own heading structure, tags every table separately, and drops the list of mandatory elements. ESMA presents that phase explicitly as a reduction of the tagging burden, because multiple and nested tagging goes out.
- Phase 2 brings detailed tagging to the figures in the notes, two years after Phase 1.
As of August 2026 there is no final report and no effective date. The direction is consistent, though: with each step, more of the report becomes machine-readable at a deeper level.
On top of that sits a rhythm independent of the deepening. The ESEF taxonomy follows the IFRS Accounting Taxonomy on a roughly annual cycle that skips years. There is no 2026 version. The 2025 taxonomy remains current and is mandatory for financial years beginning on or after 1 January 2026; the 2023 cycle was skipped earlier. So the frame of reference against which tagging happens shifts with some regularity, even without new requirements.
Why conversion work stays tied to the layout
In a conversion routine, tags are applied after the fact to a finished document. That work does not start from zero every year: most conversion tools offer a roll-forward that carries last year’s tagging onto the new document, and for a stable report that saves a great deal. What rolls forward, however, is tagging anchored to the layout of the document, not to the figures underneath it.
- The transfer is only as stable as the layout. If the report is restructured, a note moves to another chapter, or the section order changes, recognition falls back and that part has to be tagged again. The same holds for a new taxonomy version: elements that have been deprecated or replaced call for a fresh choice, whatever last year’s document said.
- No link to the source is created. What gets recorded is which passage received which element, not which figure from which source system belongs to which element. That knowledge stays outside the reporting process, and reconciling the ledger with the tagged report is manual work again every year.
- More tags means more to place and to check. Detailed tagging of the notes does not mean marking a handful of blocks; it means attaching an element to individual figures in running text and tables. Phase 1 of ESMA’s proposal lightens that work in places, Phase 2 enlarges it. Either way it happens at document level.
- Late changes call for another checking round. When a figure changes late in the process, the document has to be re-converted and re-validated. A roll-forward makes the draft cycles cheaper; what can be expected to grow with tagging depth is the validation and review round around them.
That does not make conversion unusable. But what remains after a financial year is a tagged document, and the knowledge inside it is bound to the form in which that document appeared.
For a data-first platform, the same step is a richer mapping
A reporting platform reverses the order: not finish a document and then tag it, but let figures, text and tags flow through one system. The work product there is not the tagged document but the mapping — the link between the structured source and the elements of the taxonomy. The tagged report is generated from it.
For that way of working, a deepening of the requirements is the same move as always: extend the existing mapping one level deeper. When block tagging becomes detailed tagging, the figures inside the blocks are mapped to the taxonomy — a refinement of work that already exists, not a new project. Work carries forward here too, but it is anchored to the source and the taxonomy instead of to the layout. A report that is restructured or laid out differently leaves the mapping intact, and a new taxonomy version calls for updating the elements being mapped to, not for walking through a document again. It remains work, but it sits in the mapping and in the content of the report.
The structural reason: a taxonomy-agnostic engine
That a platform can absorb deepening rules is not a matter of more features but of foundation. A taxonomy-agnostic engine is not built for one mandate — it is built to read any taxonomy: SBR, ESEF, SEC, CSRD/ESRS and whatever comes next. A new taxonomy version, a deeper tagging level or an entirely new mandate then always comes down to the same thing: load the new taxonomy and update the mapping towards it. No new software, no new project per rule change.
A conversion route lacks that foundation by the nature of how it works. The tagged document is at the same time the carrier of the tagging knowledge, and a roll-forward moves that knowledge onto the next document without turning it into a link to the source. That is what makes PDF conversion a dead end — not because it fails today, but because every deepening step has to be walked again at document level.
Does this mean conversion is never the right choice?
No. With one mandate, one output format and figures that are final well before the deadline, conversion is workable. The arithmetic changes once reporting is an annual process with multiple formats, an auditor who wants to trace figures, and tagging requirements that keep deepening. The full trade-off, including what a platform asks in year one, is laid out in Conversion tool vs platform — what solves what?.
How Taxxor does this
Taxxor Disclosure Manager is built data-first, with a taxonomy-agnostic XBRL engine at the core. Figures, text and tags flow through one system; the source is mapped to the taxonomy once and then rolls forward to every next report. When the requirements deepen, the mapping deepens with them — self-service, including block tagging and custom extension elements where the mandate allows them. The same platform delivers, next to the iXBRL filing, the print-ready PDF, the PDF for online use, the web version and MS Word and MS Excel — all from the same source. What that trade-off looks like in practice: Conversion tool vs platform.