Auf dieser Seite

Dieser Artikel richtet sich an ERP-Berater, IT-Verantwortliche und Steuerberater, die verstehen wollen, wie aus einer eingehenden XRechnung-XML eine menschenlesbare Ansicht entsteht – vollständig im Browser, ohne Server-Roundtrip – und was das für die GoBD-konforme Archivierung bedeutet. Den kaufmännischen Einstieg liefert die Viewer-Übersicht.

Visualisierung ist keine Konvertierung

Ein häufiges Missverständnis: wer eine XRechnung „als PDF speichert", glaubt manchmal, das Original ersetzt zu haben. Das Gegenteil ist richtig.

Visualisierung bedeutet: das strukturierte XML wird für einen Menschen lesbar gemacht – dieselben Daten, andere Darstellung. Die semantischen Felder (BT-1 Rechnungsnummer, BT-9 Fälligkeitsdatum, BG-25 Positionszeilen) erscheinen als layoutierte Ansicht statt als Markup. Das Quelldokument bleibt unverändert.

Konvertierung würde bedeuten: ein Format wird in ein anderes überführt, das gleichwertig oder original ist. Das trifft auf eine gerenderte HTML- oder PDF-Ansicht ausdrücklich nicht zu. Die Ansicht ist eine abgeleitete Arbeitskopie, kein rechtsverbindliches Dokument.

Diese Unterscheidung ist nicht akademisch: Sie bestimmt, was GoBD-pflichtig archiviert werden muss und was nicht (dazu weiter unten).

Die Ausgangslage: zwei Syntaxen, ein semantisches Modell

XRechnung erklärt beschreibt die Grundstruktur. Für die Visualisierung ist entscheidend: XRechnung liegt in zwei Syntaxvarianten vor, die strukturell verschieden sind.

Merkmal UBL 2.1 (OASIS) UN/CEFACT CII D16B
Root-Element <Invoice> <CrossIndustryInvoice>
Namespace-Präfixe cbc, cac ram, rsm, udt
Rechnungsnummer cbc:ID direkt unter Root rsm:ExchangedDocument/ram:ID
Belegdatum cbc:IssueDate ram:IssueDateTime/udt:DateTimeString
ZUGFeRD/Factur-X nicht vorgesehen ausschließlich CII
Peppol BIS Billing 3.0 verpflichtend nicht gefordert

Ein Viewer, der nur UBL kennt, schlägt bei CII fehl – und umgekehrt. Ein robuster Stack muss beide Syntaxen erkennen und korrekt verarbeiten. Die Syntax-Erkennung erfolgt zuverlässig anhand des Root-Namespace: urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 für UBL, urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 für CII.

ZUGFeRD und Factur-X verwenden ausschließlich CII – ein Viewer für eingehende hybride ZUGFeRD-PDFs muss daher zwingend den CII-Pfad beherrschen.

KoSIT-Visualisierungs-XSLT: zweistufiges Rendering

Die Koordinierungsstelle für IT-Standards (KoSIT) stellt unter Apache 2.0 ein XSLT-Paket bereit, das den Industriestandard für die XRechnung-Visualisierung in Deutschland darstellt. Das aktuelle Release 2026-01-31 ist kompatibel mit XRechnung 3.0.x.

Stufe 1: Normalisierung (Format-Zweig → XR-Zwischenmodell)

Die erste Transformationsstufe gleicht die strukturellen Unterschiede zwischen UBL und CII aus:

  • ubl-invoice-xr.xsl überführt UBL-Eingaben in das XR-Zwischenmodell
  • cii-xr.xsl überführt CII-Eingaben in dasselbe Zwischenmodell

Das XR-Zwischenmodell ist eine syntax-neutrale Zwischenrepräsentation: alle semantischen Felder sind in einem einheitlichen XML-Vokabular verfügbar, unabhängig davon, ob die Eingabe UBL oder CII war.

Stufe 2: Rendering (XR-Zwischenmodell → Ausgabe)

Auf das Zwischenmodell wird anschließend eines der Ausgabe-Stylesheets angewendet:

  • xrechnung-html.xsl → HTML-Ansicht (für Browser-Darstellung und Druck)
  • xr-pdf.xsl → PDF-Rendering (für serverseitige Ausgabe)

Die Zweistufigkeit hat einen technischen Vorteil: Fehler in der Syntax-Normalisierung und Fehler im Layout sind klar trennbar. Wer das Rendering anpassen will (Firmenlogo, abweichende Spaltenanordnung), greift ausschließlich in Stufe 2 ein, ohne Stufe 1 anfassen zu müssen.

Saxon-JS: XSLT 3.0 im Browser

Serverseitige XSLT-Verarbeitung (Saxon-HE/EE in Java oder .NET) ist für Backend-Systeme der Standardweg. Für einen Browser-basierten Viewer ist dieser Weg nicht gangbar – ein Upload auf einen Verarbeitungsserver würde die Rechnungsdaten das Gerät verlassen lassen.

Saxon-JS 2.7 löst das: Es ist eine XSLT-3.0-Implementierung in JavaScript, die vollständig im Browser ausgeführt wird. Die KoSIT-Stylesheets laufen damit client-seitig – keine Serververbindung, kein Upload.

Build-Schritt: .xsl → .sef.json

Saxon-JS verwendet kein rohes .xsl zur Laufzeit. Im Build-Prozess werden die Stylesheets mit dem Saxon-EE-Compiler in ein compiled stylesheet format (.sef.json) überführt:

Compile-Zeit (Node.js / Ant):
  ubl-invoice-xr.xsl  →  ubl-invoice-xr.sef.json
  cii-xr.xsl          →  cii-xr.sef.json
  xrechnung-html.xsl  →  xrechnung-html.sef.json

Die .sef.json-Dateien werden statisch ausgeliefert. Im Browser lädt Saxon-JS die passende .sef.json per fetch, führt die Transformation gegen das eingelesene XML aus und schreibt das Ergebnis-HTML in den DOM.

Bundlegröße: Das Saxon-JS-Paket hat unkomprimiert eine Größe von ca. 2,3 MB. Gzip- oder Brotli-Komprimierung im HTTP-Layer ist Pflicht; nach Komprimierung liegen die tatsächlich übertragenen Daten deutlich darunter. Die .sef.json-Dateien sind deutlich kleiner.

Ablauf im Browser (vereinfacht)

1. Nutzer wählt XML-Datei
2. FileReader liest Datei lokal (kein Upload)
3. Root-Namespace-Erkennung → UBL oder CII
4. Saxon-JS lädt passende sef.json (Stufe 1)
5. Transformation → XR-Zwischenmodell
6. Saxon-JS lädt xrechnung-html.sef.json (Stufe 2)
7. Transformation → HTML
8. HTML wird im Browser gerendert

Der gesamte Vorgang läuft im Browser-Thread; die XML-Datei verlässt zu keinem Zeitpunkt das Gerät des Nutzers.

ZUGFeRD: Extraktion des eingebetteten XML aus dem PDF

ZUGFeRD-Dateien sind reguläre PDFs mit einem eingebetteten XML-Anhang – kein reines XML. Bevor der XSLT-Stack greifen kann, muss dieser Anhang aus der PDF-Hülle herausgelöst werden.

Dateiart-Erkennung: PDF oder XML?

Der Viewer prüft zuerst, womit er es zu tun hat. Eingaben mit MIME-Typ application/pdf oder Dateiendung .pdf starten den ZUGFeRD-Extraktionspfad; Eingaben mit .xml landen direkt bei der Root-Namespace-Erkennung (UBL oder CII).

Extraktion mit PDF.js

Die Extraktion des eingebetteten XML erfolgt über PDF.js (Mozilla, Apache 2.0) – die verbreitete JavaScript-Bibliothek für PDF-Verarbeitung im Browser. PDF.js kann auf eingebettete Dateianhänge (EmbeddedFiles) zugreifen, ohne die PDF-Datei serverseitig zu übermitteln.

ZUGFeRD-konforme PDFs tragen den XML-Anhang unter einem von zwei Standardnamen:

  • factur-x.xml – Factur-X und ZUGFeRD 2.x
  • zugferd-invoice.xml – älteres ZUGFeRD-1.0-Schema (heute selten)

PDF.js gibt den Anhang als ArrayBuffer zurück; dieser wird als UTF-8-String dekodiert und dem XSLT-Stack übergeben. Ab diesem Punkt ist der Verarbeitungspfad identisch mit dem für reine XRechnung-XML.

Erweiterter Ablauf für ZUGFeRD-Eingaben

1. Nutzer wählt PDF-Datei (ZUGFeRD)
2. FileReader liest Datei lokal (kein Upload)
3. Dateiart-Erkennung → PDF → ZUGFeRD-Pfad
4. PDF.js extrahiert eingebetteten XML-Anhang (factur-x.xml)
5. ArrayBuffer → UTF-8-String
6. Root-Namespace-Erkennung → CII (ZUGFeRD ausschließlich CII)
7. Saxon-JS 2.7 lädt cii-xr.sef.json (Stufe 1)
8. Transformation → XR-Zwischenmodell
9. Saxon-JS 2.7 lädt xrechnung-html.sef.json (Stufe 2)
10. Transformation → HTML
11. HTML wird im Browser gerendert

Das eingebettete PDF-Bild (der menschenlesbare Teil des ZUGFeRD-Dokuments) bleibt dabei ungenutzt – der Viewer arbeitet ausschließlich mit dem extrahierten CII-XML.

UBL vs. CII: wo sich Renderprobleme zeigen

Die meisten Felder sind in beiden Syntaxen äquivalent abgebildet. Einige Stellen erfordern dennoch Aufmerksamkeit bei der Implementierung:

Positionsebene (BG-25 Invoice line): UBL-Positionen liegen in cac:InvoiceLine-Elementen; CII-Positionen in ram:IncludedSupplyChainTradeLineItem. Unterpositionszeilen (Sub-Invoice-Lines) werden in CII anders strukturiert als in UBL – die KoSIT-Stylesheets haben für diesen Fall in Release 2026-01-31 Korrekturen erhalten.

Datum-Formate: CII kodiert Datumsfelder mit einem Qualifikator (format="102" für YYYYMMDD), UBL verwendet ISO-8601-Strings direkt. Falsches Parsing hier führt zu unlesbaren Datumswerten im Sichtdokument.

Steuerzusammenfassung (BG-23): Die Steueraufschlüsselung nach Steuerkategorie liegt in beiden Syntaxen auf ähnlicher Ebene, aber mit unterschiedlichen Element-Tiefen. Rendering-Fehler zeigen sich hier typischerweise als leere Steuerblöcke oder falsch summierte Beträge.

Zahlungsmittel (BG-16): SEPA-Bankverbindung (BT-84 IBAN) und Zahlungsreferenz (BT-83) sind in CII in ram:SpecifiedTradeSettlementPaymentMeans verschachtelt; in UBL flacher in cac:PaymentMeans. Beide Stylesheets lösen das korrekt auf – bei Eigenentwicklungen ist dieser Pfad aber ein häufiger Fehlerort.

GoBD und das Sichtdokument

Der Begriff „Sichtdokument" ist in keiner gesetzlichen Norm legal definiert – er bezeichnet in der Praxis das menschenlesbare Pendant zur strukturierten XML: die gerenderete Ansicht, die ein Mensch lesen, prüfen und freigeben kann.

Was das BMF-Schreiben vom 14. Juli 2025 festlegt

Das BMF-Schreiben vom 14. Juli 2025 (PDF) präzisiert die Archivierungspflichten für E-Rechnungen:

  • Aufzubewahren ist der strukturierte Teil – also die XML-Datei so, wie sie empfangen wurde.
  • Das menschenlesbare Sichtdokument (HTML-Ansicht, PDF-Ausdruck) muss nicht separat archiviert werden, solange die Original-XML vollständig vorliegt und keine zusätzlichen steuerlich relevanten Informationen enthält.
  • Bei hybriden Formaten (ZUGFeRD/Factur-X) ist ebenfalls der strukturierte XML-Datenteil das primäre Aufbewahrungsobjekt – das eingebettete PDF muss nur zusätzlich aufbewahrt werden, wenn es steuerlich relevante Abweichungen enthält.

Für die Praxis bedeutet das: Die Browser-Ansicht im Viewer ist zum Lesen, Prüfen und Freigeben gedacht. Sie ist kein GoBD-konformes Archivdokument. Die Original-XML muss unveränderlich, maschinell auswertbar und für 10 Jahre (§ 147 Abs. 1 Nr. 1 i.V.m. Abs. 3 AO) archiviert bleiben.

Quellen: Bundesfinanzministerium – GoBD-Änderung 2025 (PDF) · IHK Darmstadt – Archivierung von E-Rechnungen

Im Zweifel Rücksprache mit dem Steuerberater – die vorstehenden Angaben geben den Stand des BMF-Schreibens vom 14. Juli 2025 wieder und ersetzen keine steuerliche Einzelberatung.

Einbindung in Portal- und Workflow-Systeme

Wer den KoSIT-XSLT-Stack nicht im Browser, sondern serverseitig in einen Rechnungseingangs-Workflow integriert, hat drei typische Muster:

1. DMS/ECM mit XSLT-Plugin Viele Dokumentenmanagementsysteme (z. B. ELO, d.velop, DocuWare) unterstützen XSLT-Transformationen als eingebetteten Verarbeitungsschritt. Das KoSIT-Stylesheet lässt sich dort direkt als Renderer-Konfiguration einbinden. Ergebnis: Die Rechnungsansicht liegt als PDF-Rendition neben der Original-XML im Dokumentenarchiv.

2. Peppol-AP / OZG-RE / ZRE-Portale Rechnungen, die über Peppol oder die deutschen B2G-Portale eingehen, sind bei Ankunft bereits gegen das offizielle KoSIT-Schematron validiert. Der Visualisierungs-Schritt kann direkt auf das gelieferte XML angewendet werden, ohne vorherige Syntaxprüfung.

3. Eigenentwicklung mit Saxon-HE (Java) Für Java-Backends ist der direkte Aufruf über JAXP möglich – Saxon-HE ist kostenlos und unterstützt XSLT 3.0 vollständig. Für .NET-Stacks gibt es Saxon-HE ebenfalls. Die .xsl-Dateien aus dem KoSIT-Repository werden direkt verwendet; keine Kompilierung nach .sef.json nötig.

Validierung vor der Visualisierung: Die KoSIT stellt parallel zum Visualisierungs-XSLT auch Schematron-basierte Validierungsartefakte bereit (validator-configuration-xrechnung). Für produktive Systeme empfiehlt sich eine Validierung vor dem Rendering, damit fehlerhafte Rechnungen frühzeitig zurückgewiesen werden und nicht als visuell „korrekt" erscheinende, aber inhaltlich ungültige Sichtdokumente in den Freigabe-Workflow gelangen.

Was XRechnung 4.0 für bestehende Viewer-Stacks bedeutet

KoSIT hat im März 2026 XRechnung 4.0 als nächste Hauptversion angekündigt – Basis ist die neue europäische Norm EN 16931-1:2026, deren Veröffentlichung für Mitte 2026 erwartet wird. Der XRechnung-4.0-Release ist für H2 2026 vorgesehen.

Die wesentlichen strukturellen Änderungen, die Viewer-Stacks betreffen:

Aufgelöste 1:1:1-Beziehung: XRechnung 3.x bildet streng eine Bestellung – eine Lieferung – eine Rechnung ab. XRechnung 4.0 erlaubt eine Rechnung über mehrere Bestellungen und Lieferungen. Positionen müssen dadurch neu strukturiert werden; Visualisierungen, die auf die heutige flache Struktur optimiert sind, rendern Mehrfach-Referenzen möglicherweise unvollständig oder falsch.

XML-Attachments im Kernmodell: XRechnung 4.0 unterstützt strukturierte XML-Anhänge direkt im Rechnungsdokument. Viewer müssen entscheiden, wie Anhänge dargestellt oder ignoriert werden.

Neue Erweiterungs-Architektur: Eine zentrale Extension Component Library erlaubt branchen- oder länderweite Erweiterungen. Branchenspezifische Zusatzfelder tauchen künftig in regulären XRechnung-Dokumenten auf; Viewer, die unbekannte Extension-Elemente nicht tolerant ignorieren, können Rendering-Fehler zeigen.

XSLT-Update-Pflicht: Die KoSIT wird für XRechnung 4.0 ein neues Visualisierungs-Release veröffentlichen – Zeitpunkt noch offen. Wer Saxon-JS 2.7 im Browser einsetzt, muss dann neue .sef.json-Dateien kompilieren und ausliefern. Das ist operativ überschaubar, muss aber geplant sein. XRechnung 3.0.x-Dokumente validieren unter 4.0-Schematron nicht automatisch – parallele Versions-Unterstützung ist für Übergangsphasen nötig. Hinweis zum XSLT-Prozessor: Saxon-JS 3 befindet sich seit Dezember 2024 in der Beta-Phase; für den Browser-Einsatz gilt es als noch nicht produktionsreif, und die KoSIT-Stylesheets sind derzeit gegen Saxon-JS 2.7 getestet. Für XRechnung 4.0 wird ein Versions-Abgleich nötig sein. (Quelle: Saxon-JS Release Notes)

Empfehlung für heutige Implementierungen: Syntax-Version beim Empfang aus dem Dokument auslesen, versioniert verarbeiten und das Update auf XRechnung-4.0-Stylesheets als geplante Migrationsaufgabe einplanen.

Quelle: xeinkauf.de – XRechnung 4.0 · invoice-portal.de – XRechnung 4.0 & Peppol

Weiterführende Ressourcen

Vom Viewer zur Liquiditätsplanung

Ein Browser-Viewer löst das Sichtbarkeitsproblem für eine einzelne Rechnung. Wer Eingangsrechnungen strukturiert verarbeiten will, braucht mehr als eine Ansicht: Beträge und Fälligkeiten müssen ohne Abtippen in die Planung fließen.

Der Dienst hinter liqui.de liest XRechnung- und ZUGFeRD-XML automatisch ein, extrahiert Fälligkeitsdatum und Betrag und überführt sie direkt in die 13-Wochen-Liquiditätsvorschau. Die Original-XML bleibt dabei GoBD-konform erhalten – nicht als Hinweis im Tool, sondern als strukturelle Eigenschaft des Archivs.