ESEF extensions: when to create one, and when not to

Most of the review findings raised against extension elements in European Single Electronic Format (ESEF) filings come from the same root cause: an issuer created a new element when a core taxonomy element already carried the same meaning. The second largest group comes from extensions that were created legitimately but anchored badly, or not at all.

Both are avoidable, and both are decided long before the tagging software is opened. This is a short account of how the decision should run.

An extension is an element you create because the core taxonomy has none

ESEF requires annual financial reports to be prepared in Inline eXtensible Business Reporting Language (Inline XBRL), with the primary financial statements tagged against the IFRS Taxonomy. The taxonomy is large, but it is not infinite, and it was never intended to carry every line item every issuer reports.

When an issuer reports something the core taxonomy does not model, it creates an extension element: a new concept, defined by the issuer, in the issuer's own namespace. That is a normal and expected part of ESEF. The difficulty is not that extensions exist. It is that an extension is, by construction, a private concept that no consumer of the filing has seen before.

Everything that follows is about making that private concept legible to someone who is reading a thousand filings and has no access to the issuer's finance team.

The first test is whether a core element already means the same thing

Before creating an extension, the question is not whether a core element has the same label. It is whether a core element has the same accounting meaning and the same scope.

If it does, the core element must be used. A different caption in the issuer's own presentation is not a reason to extend. Neither is a different position in the statement, a different level of aggregation that the taxonomy already supports, nor a preference for the issuer's internal terminology. The label is presentational; the element is semantic.

This is where most false extensions originate. A team maps the annual report line by line, finds no element whose label matches the caption, and creates one. The correct step is to search on meaning, check the element's standard definition and its place in the taxonomy's structure, and only then conclude that nothing fits.

Anchoring is what makes an extension readable to an outside consumer

Where an extension is genuinely required, ESEF requires it to be anchored: linked to the core taxonomy element or elements that are closest to it in meaning. Anchoring is what allows an automated consumer to place an unfamiliar concept inside a structure it already understands.

The link records a relationship of scope. An extension that is narrower than a core concept is anchored to that wider core element. Where an extension is wider than the core elements it covers, the relationship runs the other way, to the narrower core elements that fall within it.

Anchoring is not a formality and it is not satisfied by picking a plausible-looking element. An extension anchored to a concept that does not actually contain it is worse than one that is poorly named, because it asserts a relationship that is false and a consumer has no way to detect that.

Subtotals are the main exception, and the reason is worth understanding

Extension elements that represent subtotals within a statement are generally not required to be anchored. The reason is structural rather than administrative: a subtotal's meaning is already fully determined by the elements that sum into it, which are themselves tagged. The calculation relationships carry the information that anchoring would otherwise have to supply.

That logic is a useful test in its own right. If an extension's meaning is genuinely established by its calculation structure, it is probably a subtotal. If it is not, it needs an anchor, whatever it is called.

The exact scope of the exemption, and the current expectations around how anchoring relationships are presented, are set out in ESMA's ESEF Reporting Manual, which the European Securities and Markets Authority updates periodically. Work from the current version rather than from a previous year's copy, because the guidance has been refined more than once.

Where extension decisions go wrong in practice

A handful of patterns account for most of the problems we see.

• Extending for a renamed core concept. The most common failure, and the one with the clearest fix.
• Extending for a presentation choice. Splitting or combining lines for layout reasons does not change what the underlying amounts mean.
• Carrying extensions forward unexamined. An extension created three years ago may now be covered by a core element, because the taxonomy is updated annually. Extensions deserve an annual review, not just a roll-forward.
• Anchoring to the nearest label rather than the nearest meaning. This passes a cursory check and misleads every automated consumer downstream.
• Inconsistent extensions across the group. Two concepts with the same meaning and two different extension elements, usually because two people tagged two statements.

None of these produces a filing that obviously fails. That is what makes them persistent: a report can validate cleanly and still be substantially less useful than it should be.

A clean filing and a useful filing are not the same thing

It is worth being blunt about this, because it shapes how teams allocate effort. Technical validation checks structure, arithmetic, and conformance to the filing rules. It cannot tell you that an extension was unnecessary, or that an anchor points at the wrong concept.

Those are judgements about accounting meaning, and they need a person who understands both the financial statements and the taxonomy. The practical consequence is that the tagging review has to be a review of element choices, not just a review of error messages.

Issuers who treat it that way tend to find their extension count falling year on year, which is usually a good sign rather than a sign of lost detail.

What to do before your next filing

Start the extension review before the report is final, not after. Produce a list of every extension element with, for each one, the core element that was considered and rejected and a one-line reason. That document takes an hour, answers most auditor and regulator questions directly, and makes next year's roll-forward a review rather than an excavation.

Then check every anchor for meaning rather than for presence, re-examine extensions inherited from prior years against the current taxonomy, and reconcile element choices across the group so that the same concept is tagged the same way everywhere.

Semansys maintains versioned taxonomy libraries and validation across ESEF and other regulatory reporting frameworks. Would you like to talk through how your extension and anchoring decisions are reviewed before filing? Explore our taxonomy coverage, see how ESEF annual report filing works, or book a discovery call.

_{This article explains the mechanism rather than restating the rules. The operative requirements sit in the ESEF regulatory technical standards and in ESMA's ESEF Reporting Manual, and national filing rules may add to them. Confirm the current version of both before applying any of this to a live filing. General information only; not legal, accounting, or regulatory advice.}