--- title: "ESEF-Bericht auf Englisch übersetzen: die Kaskade im Detail – Jetzt Übersetzt" description: "Warum eine späte Zahländerung deutsche ESEF-Datei, englische ESEF-Datei und Übersetzung trifft – § 51 BörsO FWB, identische XBRL-Tags, Praxishandbuch." url: "https://jetzt-uebersetzt.de/blog/esef-spaetanderungen-deutsch-englisch-xbrl-einreichung" language: de-DE alternates: de-DE: "https://jetzt-uebersetzt.de/blog/esef-spaetanderungen-deutsch-englisch-xbrl-einreichung" en-US: "https://jetzt-uebersetzt.de/en/blog/esef-late-changes-cascade-german-english-filing" x-default: "https://jetzt-uebersetzt.de/blog/esef-spaetanderungen-deutsch-englisch-xbrl-einreichung" image: "https://jetzt-uebersetzt.de/assets/images/og-image.de.png" organization: name: Jetzt Übersetzt telephone: "+49 157 9259 6395" email: "alexander@jetzt-uebersetzt.de" address: "523 Jackson Street, Unit #210, Saint Paul, Minnesota 55101, US" --- ESEF Inline XBRL Geschäftsbericht Finanzberichterstattung Fachübersetzung # Eine Änderung, drei Dateien: Wie Spätänderungen durch deutsche ESEF-Datei, englische ESEF-Datei und Übersetzung kaskadieren Wenn § 51 BörsO FWB aus einer späten Zahländerung zwei getaggte XHTML-Pakete und eine Übersetzung macht – ein Praxishandbuch für die Einreichungswochen ![Alexander Kirsch-Clayton](https://jetzt-uebersetzt.de/assets/images/alexander.jpg) von [Alexander Kirsch-Clayton](https://www.linkedin.com/in/alexanderkc/), Fachübersetzer DE ↔ EN 3. November 2026 ·9 Min. Lesezeit [Jetzt Übersetzt auf LinkedIn](https://www.linkedin.com/company/jetztuebersetzt/) [ProZ](https://www.proz.com/profile/138291) Um 18:00 am Vorabend der Einreichung kippt eine Zahl im Konzernabschluss. Früher war das eine Korrektur im Layout. Heute sind es drei Dateien: die deutsche ESEF-Datei, die englische ESEF-Datei und die Übersetzung, die beide verbindet. § 51 BörsO FWB macht aus einem Geschäftsbericht zwei getrennte, getaggte XHTML-Pakete – jede späte Änderung muss beide gleichzeitig treffen. Emittenten mit Geschäftsjahresende zum 31. Juli reichen spätestens Ende November ein; die November-Wochen sind in jedem Jahr Einreichungswochen. Genau dann erreichen mich die beiden Fragen, die dieser Artikel beantwortet. Erstens: Was passiert mit der englischen ESEF-Datei, wenn sich im deutschen Bericht kurz vor der Einreichung noch eine Zahl ändert? Zweitens, die kürzere Frage dahinter: Müssen deutsche und englische ESEF-Einreichungen identische XBRL-Tags haben? Die kurze Antwort lautet ja. Die längere beginnt bei der Börsenordnung und endet bei einer Checkliste mit sieben Punkten. ## Was ESEF ist – ein ehrlicher Absatz ESEF steht für European Single Electronic Format, das einheitliche elektronische Berichtsformat nach der Delegierten Verordnung (EU) 2019/815. Technisch verbirgt sich dahinter Inline XBRL: Der Bericht bleibt ein XHTML-Dokument mit gewohntem Layout – aber die Zahlen und Sachverhalte des Konzernabschlusses sind mit XBRL-Tags ausgezeichnet, die den Wert maschinenlesbar machen. In Deutschland setzt § 328 HGB das um: Inlandsemittenten legen die Unterlagen des Jahresfinanzberichts im XHTML-Format offen und zeichnen den Konzernabschluss nach den Artikeln 4 und 6 der Delegierten Verordnung aus. Wer die Datei einreicht, bewegt sich also immer auf zwei Ebenen: der lesbaren Seite und der darunterliegenden Maschinenebene. ## Zwei Sprachen, zwei getrennte Einreichungen Für Prime-Standard-Emittenten kommt eine dritte Ebene hinzu, und die ist die eigentliche Wurzel der Kaskade. § 51 BörsO FWB bestimmt: „Der Jahresfinanzbericht ist in deutscher und englischer Sprache spätestens 4 Monate nach Ablauf des Geschäftsjahres elektronisch zu übermitteln.“ Deutsche Börse formuliert es auf ihren Folgepflichten-Seiten entsprechend: Alle Emittenten im Prime Standard müssen den Jahresfinanzbericht auf Deutsch und Englisch erstellen und elektronisch übermitteln – über die Schnittstelle des Exchange Reporting System (ERS) an die Börsengeschäftsführung. Emittenten mit Sitz außerhalb Deutschlands dürfen nach den dortigen Regeln mitunter nur die englische Fassung einreichen. Dabei akzeptiert das ERS je Sprachversion eine einzelne XHTML-Datei, eine ZIP-Datei oder eine einzelne PDF-Datei – die Sprachfassungen sind also getrennte, in sich geschlossene Liefergegenstände. Und für ESEF-pflichtige Berichte gilt ohnehin: Sie laufen als ZIP-Paket durch das System. Wer zweisprachig einreicht, liefert damit zwei vollständige, getaggte Pakete – nicht ein Dokument plus Anhang. ## Warum die englische Fassung kein PDF-Anhang mehr ist Früher war die englische Version des Geschäftsberichts eine Zierde für internationale Investoren: ein PDF neben dem deutschen Original, inhaltlich wichtig, technisch nachrangig. Diese Zeit ist vorbei. Das ESEF Reporting Manual der ESMA hält in Guidance 1.1.2 fest: „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.“ Auf Deutsch: Jede gesetzlich verlangte Sprachversion ist ein eigenständiges XHTML-Dokument im eigenen ESEF-Paket – mit denselben Format- und Tagging-Pflichten wie die erste. Für die Übersetzung ändert das die Position im Produktionsprozess grundlegend. Ich arbeite nicht mehr am Ende einer PDF-Kette, sondern innerhalb einer maschinenlesbaren regulatorischen Einreichung. Der englische Text, den ich liefere, sitzt am Ende direkt neben XBRL-Elementen; jede Formulierung, die eine getaggte Zahl umgibt, steht im selben Markup. Auch Anbieterleitfäden formulieren es bündig: Die zweite Sprachversion muss dasselbe Format haben und entsprechend getaggt sein wie die erste. Genau das ist der Grund, warum aus einer späten Zahländerung kein kurzer Handgriff wird – sondern eine Kaskade. ## Die Kaskade Schritt für Schritt Nehmen wir den Fall vom Anfang konkret durch. Es ist 18:00 am Tag vor der Einreichung, der Konzernabschluss ist geprüft, beide XHTML-Pakete sind valide – und dann kippt eine Position im Bereich des sonstigen Finanzergebnisses. Nicht groß, aber sie ändert eine konsolidierungsrelevante Zahl. Verfolgen wir, was alles passiert: 1. Deutsche ESEF-Datei: Die Zahl wird im deutschen XHTML an allen Fundstellen geändert – Tabelle, Textverweis, Anhang. Das Layout wird neu exportiert. 2. Deutsche Tags: Der XBRL-Wert muss dieselbe Änderung tragen; der Tag führt den Wert, das Layout nur die Schreibweise. Nach dem Re-Export prüft jemand, ob die Auszeichnung die neue Ziffer noch umschließt. 3. Englische ESEF-Datei: Dieselbe Zahl erscheint in der englischen Fassung – im englischen Zahlenformat (1,234.5 statt 1.234,5) und in englischem Textumfeld. Auch hier wird neu exportiert. 4. Englische Tags: Dasselbe Element, derselbe Name, neuer Wert. Getrenntes Paket, dieselbe Pflicht. 5. Die Übersetzung: Alle Formulierungen um die Zahl herum ändern sich mit – „steigt auf“ statt „betrug“, Vorjahresvergleich, Tabellenfußnoten, allenfalls die Diskussionslage im Lagebericht. Das ist der Teil, den niemand einplant, der aber am längsten dauert. So sieht das im Quelltext aus, stark vereinfacht – die Zahl, die der Leser sieht, steckt in einem Element mit Namen, Kontext, Einheit und Skalierung: ``` 1.234 ``` Ein Re-Export, der dieses Element zerlegt oder den Wert daneben setzt, erzeugt eine Datei, die gegen die Verordnung verstößt – nicht gegen den Lesegenuss. Der berühmte „kurze Handgriff in InDesign“ ist deshalb nie kurz: Ein erneuter Export kann Tags verschieben oder löschen; eine geänderte Zeilenhöhe bricht eine getaggte Tabelle um; eine neue Zahl zieht Fließtext nach sich, der im Deutschen länger ausfällt als geplant und im Englischen wieder ganz anders. Was als eine Änderung beginnt, endet als Abstimmung über zwei Dateien, zwei Layouts und eine Sprachversion – meist an einem Abend, an dem alle lieber fertig wären. ## Extension-Elemente: gleiche Namen in beiden Paketen Jetzt zur zweiten Frage: Müssen deutsche und englische ESEF-Einreichungen identische XBRL-Tags haben? Ja – und zwar ausdrücklich. Guidance 1.1.2 des ESMA-Manuals verlangt, dass alle Sprachversionen eines Jahresfinanzberichts inhaltlich konsistent sind und mit denselben Kerntaxonomie-Elementen und/oder Extension-Elementen getaggt werden, wie sie in der Extension-Taxonomie des Emittenten definiert sind – und diese Extension-Taxonomie soll über die Sprachversionen hinweg geteilt werden. Sie ist damit das Band, das beide Pakete zusammenhält. Kurz beantwortet: Müssen deutsche und englische ESEF-Einreichungen identische XBRL-Tags haben? Ja. ESMA Guidance 1.1.2 verlangt gleiche Kerntaxonomie-Elemente und/oder Extension-Elemente aus einer über beide Sprachversionen geteilten Extension-Taxonomie des Emittenten – eingereicht als zwei getrennte XHTML-Pakete. Extension-Elemente sind eigens definierte Elemente für Sachverhalte, die die Core-Taxonomie nicht hergibt – ein branchenspezifischer Posten, eine unternehmensspezifische Kennzahl. Der technische Elementname muss in beiden Paketen identisch sein; die Labels dagegen folgen der Sprache des jeweiligen Berichts. ESMA ermutigt Emittenten zusätzlich zu englischen Labels – der Sprache, die im internationalen Finanzwesen üblich ist. Genau an dieser Stelle sitzt die Übersetzung: Der deutsche Label steht in der deutschen Datei, der englische in der englischen, und beide müssen denselben Begriff sauber tragen. Die stille Gefahr ist der sogenannte Tag-Drift: Wer die englische Entsprechung eines Custom-Elements ad hoc prägt, erzeugt in der englischen Datei eine Bezeichnung, die mit dem deutschen Fachbegriff nur noch lose verwandt ist. Beim nächsten Zyklus findet niemand die Verbindung wieder. Eine DE-EN-Termbank hält die Extension-Elemente deshalb strikt parallel: deutscher Fachbegriff, technischer Elementname, englisches Label, Definition, Fundstelle. Das klingt bürokratisch – und ist im November die ruhigste Stunde des gesamten Projekts. ## Wo der Workflow in der Praxis bricht Die Kaskade selbst ist noch berechenbar – kippen tut es meist an den Nahtstellen dazwischen. In Projekten sehe ich immer wieder dieselben vier Bruchstellen: - Layout-Re-Exports überschreiben Tags. Jemand exportiert nach der Zahländerung neu, und die Auszeichnungen rutschen aus ihren Zahlen oder verschwinden ganz. Der Fehler fällt selten im Layout auf – er fällt in der Validierung auf, im ungünstigsten Fall bei der Prüfstelle. - Englische Textlängen brechen getaggte Tabellen. Was im Deutschen eine Zeile ist, sind im Englischen zwei; Spalten rutschen, Zahlen wandern, und der Tag umschließt plötzlich die Nachbarspalte. - Der Prüfer gibt die deutsche Fassung frei, während die englische weiterläuft. Zwischen deutschem Endstand und englischem Endstand liegen Stunden oder Tage – genug für die stillen Abweichungen, die später niemand mehr zuordnen kann. - Der „Native Speaker“ wird zur letzten Instanz. Ein Controller mit gutem Englisch soll kurz „drüberschauen“ – am Abend vor der Einreichung, ohne Terminologie, ohne Kontext der Vorjahre. Das ist keine finale Qualitätskontrolle, das ist Glücksspiel. ## Ein kaskadensicherer Workflow Die gute Nachricht: Die Kaskade lässt sich zähmen, wenn vier Disziplinen greifen. Keine davon ist kompliziert; alle vier müssen aber vor dem Endspurt stehen, nicht währenddessen. 1. Änderungsprotokoll vom Kunden: Jede Änderung mit Datum, Fundstelle und Art (Zahl, Text, Layout) – lückenlos, auch die „winzigen Sachen“. Gerade die winzigen landen sonst nur in einer der beiden Dateien. 2. Terminologie-Freeze: ein Stichtag, ab dem keine Neuprägungen mehr ins Projekt kommen. Was danach neu ist, muss über die Termbank laufen und in beiden Paketen erscheinen. 3. Übersetzen aus der getaggten Quelle: nicht aus der ungetaggten Word-Datei, die irgendwo auf einem Fileserver liegt, sondern aus dem XHTML, das am Ende eingereicht wird. Nur so ist die Übersetzung von Anfang an Teil der Einreichung, kein Anhängsel. 4. Paralleler Schlussabgleich beider Pakete: dieselbe Stelle in deutscher und englischer Datei nebeneinander, zusammen mit dem Zahlenabgleich – die letzte Chance, stille Abweichungen zu finden, bevor die ZIP-Pakete Richtung Börse gehen. Der dritte Punkt verdient eine Anmerkung: Der Aufwand, aus dem XHTML zu arbeiten, ist am Anfang größer als bei einer Word-Vorlage. Er zahlt sich in der Nacht vor der Einreichung zurück, wenn die einzige Frage lautet, ob die Übersetzung wirklich auf dem Stand ist, der eingereicht wird – und nicht auf dem von gestern früh. ## Was als Nächstes kommt: ESRS zieht in dieselbe Kaskade Ein Ausblick, der für Terminologie-Verantwortliche jetzt handlungsrelevant wird: Die EFRAG hat am 17. September 2026 den Entwurf der XBRL-Taxonomie für die überarbeiteten ESRS veröffentlicht; die öffentliche Konsultation läuft bis zum 11. November 2026. Die Taxonomie liefert die technische Grundlage, um Nachhaltigkeitsangaben nach ESRS maschinenlesbar darzustellen. Die Tagging-Regeln sollen durch eine Änderung der Verordnung (EU) 2019/815 angenommen werden – also derselben Verordnung, die heute die deutschen und englischen XHTML-Pakete regiert. Zwingend ist das ESRS-Tagging damit noch nicht; es wird es erst mit der künftigen Verordnungsänderung. Die Richtung ist aber eindeutig: Die Nachhaltigkeitserklärung wächst in dieselbe zweisprachige, getaggte Kaskade hinein, die dieser Artikel beschreibt. Wer dann nicht von null anfangen will, aktualisiert die DE-EN-Termbank vor dem Geschäftsjahr 2026 – nicht danach. Die Konsultation läuft ohnehin bis Mitte November; wer die Entwurfstaxonomie kennt, kennt die Begriffe, die als Nächstes Extension-Elemente und englische Labels brauchen. ## Checkliste vor der Einreichung: sieben Punkte Zum Schluss das Nützlichste aus den Einreichungswochen: sieben Checks, bevor beide XHTML-Pakete zur Deutschen Börse gehen. Sie ersetzen keine Validierung – aber sie finden die Fehler, die Validatoren nicht sehen. 1. Tag-Parität stichprobenartig prüfen: dieselbe Zahl in deutscher und englischer Datei aufrufen und prüfen, ob beide Tags denselben Wert tragen. Fünf bis zehn Stellen reichen, verteilt über Konzernabschluss, Anhang und Lagebericht. 2. Extension-Elemente abgleichen: Liste der Custom-Elemente aus beiden Paketen nebeneinander – identische Namen, dazu die Labels in der jeweiligen Sprache. 3. Zahlenabgleich über beide Dateien: jede geänderte Zahl aus dem Änderungsprotokoll muss in beiden Paketen an allen Fundstellen stehen. Das klingt banal und ist der häufigste Fund. 4. Verzeichnisse parallel halten: Kapitel- und Seitenverweise der englischen Datei müssen auf die englische Struktur zeigen, nicht auf die deutsche. Verzeichnisse zeigen Abweichungen am ehesten, weil sie alles auf einen Blick bündeln. 5. Zahlen- und Datumsformate prüfen: 1.234,5 gegen 1,234.5, 31.12.2025 gegen 31 December 2025 – systematisch, nicht nach Gefühl. 6. Labels der Extension-Taxonomie abschließen: deutscher Label in der deutschen Datei, englischer in der englischen, und der technische Elementname identisch. 7. Finale Parallelkorrektur beider Pakete aus einer Hand: dieselbe Person oder dasselbe Team sieht beide Dateien in derselben Version – erst danach wird eingereicht. Zwei getaggte XHTML-Pakete, vier Monate Frist, und im Herbst die Einreichungswochen: Die zweisprachige ESEF-Einreichung ist kein Nebenprodukt des Geschäftsberichts, sondern zwei regulatorische Liefergegenstände mit gemeinsamer Terminologie. Wer die Kaskade einmal sauber durchlaufen hat, hat den schwierigsten Teil schon erledigt – verstanden, dass die Übersetzung Teil der Einreichung ist. Details zu Leistungen und Abläufen im Finanzberichtsbereich finden Sie auf der [Leistungsübersicht](https://jetzt-uebersetzt.de/leistungen); wenn Sie in diesem Zyklus vor der Kaskade stehen, schreiben Sie mir über das [Kontaktformular](https://jetzt-uebersetzt.de/kontakt) – gerne auch am Vorabend der Einreichung. ## Quellen 1. [Börsenordnung für die Frankfurter Wertpapierbörse (BörsO FWB), offizielle PDF-Fassung der Deutschen Börse](https://www.cashmarket.deutsche-boerse.com/resource/blob/35136/8025231f8e15e7c726b3c22706c25078/data/2026_07_07_fwb_boersenordnung.pdf) (abgerufen 2026-11-03) 2. [Follow-up Obligations Regulated Market – Deutsche Börse Cash Market (englischsprachige Folgepflichten-Seite)](https://www.cashmarket.deutsche-boerse.com/cash-en/Being-Public/Follow-up-Obligations-Exchange-Reporting-System/regulated-market) (abgerufen 2026-11-03) 3. [Folgepflichten Regulierter Markt – Deutsche Börse Cash Market (deutschsprachige Folgepflichten-Seite)](https://www.cashmarket.deutsche-boerse.com/cash-de/Being-Public/ipo-line-being-public/regulierter-markt/Folgepflichten-Regulierter-Markt--4305738) (abgerufen 2026-11-03) 4. [Exchange Reporting System – Deutsche Börse Cash Market (Eurex Group)](https://www.eurexgroup.com/dbcm-en/primary-market/being-public/exchange-reporting-system) (abgerufen 2026-11-03) 5. [§ 328 HGB – Form, Format und Inhalt der Unterlagen bei der Offenlegung (gesetze-im-internet.de)](https://www.gesetze-im-internet.de/hgb/__328.html) (abgerufen 2026-11-03) 6. [ESMA ESEF Reporting Manual (ESMA32-60-254), Preparation of Annual Financial Reports in ESEF format](https://www.esma.europa.eu/sites/default/files/library/esma32-60-254%5Fesef%5Freporting%5Fmanual.pdf) (abgerufen 2026-11-03) 7. [5 things to have in place before your 2022 ESEF reporting – IRIS CARBON](https://iriscarbon.com/5-things-to-have-in-place-before-your-2022-esef-reporting/) (abgerufen 2026-11-03) 8. [Validating your iXBRL document for ESEF compliance – IRIS CARBON](https://iriscarbon.com/validating-your-ixbrl-document-for-esef-compliance/) (abgerufen 2026-11-03) 9. [EFRAG releases Draft XBRL Taxonomy for the Revised ESRS and launches public consultation – EFRAG News](https://www.efrag.org/en/news-and-calendar/news/efrag-releases-draft-esrs-xbrl-taxonomy-for-the-revised-esrs-and-launches-public-consultation) (abgerufen 2026-11-03) 10. [Exposure Draft Consultation – ESRS XBRL Taxonomy, EFRAG](https://www.efrag.org/en/projects/esrs-xbrl-taxonomy/exposure-draft-consultation) (abgerufen 2026-11-03)