One change, three files: How late edits cascade through the German ESEF file, the English ESEF file and the translation

Under Section 51 of the Börsenordnung für die Frankfurter Wertpapierbörse, a Prime Standard issuer doesn’t file one annual report—it files two: German and English, each a separate ESEF package with matching XBRL tags. One late number change therefore lands in three files: the German XHTML, the English XHTML, and the translation between them.

ESEF is the European Single Electronic Format. Under Delegated Regulation (EU) 2019/815, which § 328 HGB implements into German law, listed issuers disclose their annual financial report in a unified electronic reporting format: a single XHTML document that reads like a normal annual report to a human, with inline XBRL woven through it. The consolidated financial statements are tagged—each material figure wrapped in markup that tells a machine what the number means, not just what it says. The visible page is still the annual report; underneath it is a second, machine-readable layer.

A tagged fact carries more than the figure. Each <ix:nonFraction> binds the visible number to an element name from the core taxonomy (what the figure is), a context (which entity, which period), a unit (euros, shares, percent), and scale and decimals (stated in millions, rounded to the nearest hundred thousand, say). Change the number and every one of those bindings still has to be true. That’s the machinery a late edit has to survive.

Prime Standard issuers then do all of that twice. Section 51 BörsO FWB requires the Jahresfinanzbericht “in deutscher und englischer Sprache spätestens 4 Monate nach Ablauf des Geschäftsjahres elektronisch zu übermitteln”—submitted electronically in German and English, within four months of fiscal year-end. Deutsche Börse’s English-language obligations page says the same thing: all Prime Standard issuers “prepare and transmit via electronic means their Annual Financial Report in German and English,” with foreign-domiciled issuers allowed English only. The Exchange Reporting System accepts each language version as a single .XHTML file, a .ZIP file, or a single .PDF—and a report subject to ESEF goes up as a ZIP.

For years, the English annual report was a translation deliverable: typeset after the German, posted somewhere on the IR page, legally present but practically an afterthought. ESEF ended that. ESMA’s ESEF Reporting Manual settles what a second language means in a tagged filing, in one sentence this whole article hangs on:

“Where the presentation of the AFR is required by law to be made available in more than one language version, each language version shall be a separate XHTML report contained in a separate ESEF report package.” —ESMA ESEF Reporting Manual, Guidance 1.1.2

Two packages, not one bilingual file. Vendor guidance for issuers puts the practical consequence plainly: the second-language report must be in the same format as the first and tagged the same way. So the English report is not a translation riding along with the German filing—it is a filing, with its own validation, its own tags, and its own obligation to correspond to the German package. For the translator, that changes the job description: you’re no longer producing a document that happens to be published; you’re working inside a machine-readable submission where every corrected sentence has a tagged twin.

The English file also inherits things that used to be mere layout. Its internal numbering has to let its content list resolve; its cross-references have to point somewhere real; its tables have to hold the tags they carry. And it inherits a hard deadline: filing day is filing day for both languages, so the English package can’t lag comfortably behind the German one anymore.

Here’s the scenario every Prime Standard IR team knows. It’s 18:00 on the day before submission, and a final auditor adjustment moves consolidated revenue—from €412.6 million to €409.8 million, say. In the German XHTML, that figure isn’t just typed text. It’s a tagged fact:

<!-- German XHTML: -->
Umsatz: <ix:nonFraction name="ifrs-full:Revenue" contextRef="c-FY2025" unitRef="u-EUR" scale="6" decimals="-3">409,8</ix:nonFraction> Mio. €

<!-- English XHTML: same element name, local display format -->
Revenue: <ix:nonFraction name="ifrs-full:Revenue" contextRef="c-FY2025" unitRef="u-EUR" scale="6" decimals="-3">409.8</ix:nonFraction> €m

One change, five touchpoints, in order:

1. The German XHTML: the sentence changes—text in the income statement, probably also the key-figures table, a highlights page, maybe a passage in the management report.
2. The German XBRL: the fact must survive—same element (ifrs-full:Revenue), same context, same unit, same scale and decimals, or the package stops validating.
3. The English XHTML: every translated sentence carrying that figure changes with it—statement, segment note, wherever the number is quoted.
4. The English XBRL: the same element name as the German package, because the two taxonomies are supposed to match.
5. The translation: the affected segments need an explicit correction instruction, or the old figure lives on in the translation memory.

This is why the “quick fix in InDesign” is never quick. Layout software knows nothing about inline XBRL: the tag is invisible markup inside the text flow, and a designer who retypes a figure—or worse, re-exports a spread from an older master—can strip the tag or orphan its context reference. Then the English text runs longer than the German, so the corrected sentence pushes a tagged row out of its table or misaligns a figures block. And because each package is validated on its own, neither file warns you about the other: the German can be clean while the English is stale, or the reverse.

The third file keeps its own memory. A CAT tool stores every translated segment, and a number that changes without a correction note comes back as a perfect match in the next document—the interim report, next year’s filing—with the old figure inside it. That’s why late changes need explicit handling: which segments, which numbers, both language directions.

Not every disclosure maps onto an element of the core IFRS taxonomy. Industry-specific KPIs, custom segment breakdowns, regulatory detail with no standard equivalent—those become extension elements, defined in the issuer’s own extension taxonomy on top of the core. The name is coined once, in the taxonomy, and used wherever the concept appears.

Yes—identical. ESMA Guidance 1.1.2 continues: all language versions of the AFR “shall be tagged with the use of the same core taxonomy elements and/or extension elements as defined in an issuer’s extension taxonomy (which should be shared across the reports presented in different languages).” Same core elements, same extension elements, one extension taxonomy shared across languages. The German and English packages aren’t two interpretations of the report; they’re two renderings of the same tagged content.

What differs between the packages is the label—the human-readable name attached to each element. Labels should be in the language of the report, and ESMA encourages issuers to provide labels “in a language customary in international finance”—in practice, English—for extension elements. So the element xyz:GridFeePerMwh carries a German label in the German package and an English label in the English one, while the element name itself never changes. The failure mode is ad-hoc coining: someone translating from the untagged Word file invents a fresh name for a custom concept, and the English package ends up with a different element than the German. Tag drift—two names for one concept, and an uncomfortable validation conversation later. A DE→EN termbase closes that gap before it opens. For every custom concept it pins down:

• the element name—identical in both packages, decided in the taxonomy, never in the layout;
• the German label and the English label;
• the standard translation of the concept wherever it appears in prose;
• unit and scale conventions, so a German “Mio. €” table and an English “€m” table remain the same fact.

Tagging errors get caught by validators. The cascade usually fails in the gaps between the files—in my experience the recurring failure modes look like this:

• Layout re-exports overwrite tags. The designer fixes the number in InDesign, re-exports the page, and the tagging tool re-applies from a stale source: the visible text says one figure, the tagged fact says another.
• English lengths break tagged tables. A corrected sentence runs three lines instead of two and pushes a tagged row out of the table area; the validation error reads like nonsense until someone looks at the layout.
• The auditors sign the German. The opinion covers the German statements; the German freezes for signature while the English keeps moving, and the last delta never reaches the translation desk unless someone tracks it explicitly.
• The controller who “speaks English” becomes the final reviewer. That works until a change lands at 22:00 on filing eve: an in-house correction updates neither tags, nor termbase, nor translation memory—and every shortcut comes back as a match next year.

None of this requires new tools. It requires four pieces of discipline that make the cascade boring:

1. Change-log discipline from the client. Every post-freeze change arrives written down: page, old value, new value, which statements and tables it touches. No verbal “we changed something in the notes.”
2. A terminology freeze. Extension elements and their labels lock before translation starts; anything discovered later goes in as an agreed, logged addition—not as a silent coin in a deadline draft.
3. Translate from the tagged source. My working source is the German XHTML with the tags visible, never an untagged Word export. That way the element name travels with its sentence, and tag parity is checkable segment by segment.
4. A final parallel proof. After the last change: German and English side by side, tag parity on every changed fact, number reconciliation across both packages, then validation of both—before anything goes to the exchange.

Four steps, no exotic tooling. That’s the whole difference between treating the English filing as a document and treating it as half of a two-part machine-readable submission.

The next building block is already in the pipeline. On September 17, 2026, EFRAG published the draft XBRL taxonomy for the revised ESRS and opened a public consultation running until November 11, 2026—aimed, as EFRAG notes, at software vendors, XBRL specialists and digital reporting experts. The draft “provides the technical basis for representing ESRS disclosures in a machine-readable format.” Which is to say: the sustainability statement is on its way into exactly the dual-language, tagged cascade this article describes.

Nothing in that package is mandatory yet—the tagging rules become law only through a future amendment of Regulation (EU) 2019/815, the ESEF Regulation itself. But the route tells you where this goes: a German sustainability statement and its English counterpart, both tagged, both validated, both required to correspond. If you maintain a DE→EN termbase for financial reporting, extend it to the ESRS labels before the FY2026 reporting cycle starts—not after the first validation error.

If your filing week currently runs on a shared drive and hope, this is the part worth fixing first. Seven checks, in order, before both XHTML packages go to Deutsche Börse:

1. Tag-parity spot check. Pick five facts changed after the freeze and confirm the same core-taxonomy element carries each of them in both packages.
2. Extension-name match. Every extension element in the German taxonomy appears in the English package, character for character.
3. Cross-file number reconciliation. Every figure on the change log is correct in both languages—in the statement, the notes, the key-figures table, and anywhere the number is quoted in prose.
4. Label language. German labels in the German package, English labels in the English package, no leftovers from either side.
5. Disclosure index alignment. Content lists and cross-references in both files resolve, including where pagination shifted after the edit.
6. Validation of both packages. Both XHTML packages pass the ESEF checks—not one file as a proxy for the other.
7. Change-log reconciliation. Everything on the client’s change list is present in both files, and nothing else changed.

That list takes an hour, and it has saved more filing days than I can count. If you’re mid-cascade right now, send me what changed and when it’s due—I translate annual reports DE→EN from the tagged source with exactly this workflow. Scope and flat rates for full annual-report projects are on the services page.