Shopify
WooCommerce
Shopware
JTL-Shop
Magento
PrestaShop
n8n
Zapier
Make
Airtable
HubSpot
Eine Frage, die häufiger kommt, als man denken würde:
„Wenn wir auf E-Rechnung umstellen — verlieren unsere Kunden dann die Angaben, mit denen sie die Rechnung überhaupt zuordnen?"
Der Anlass war diesmal ein Dienstleister aus der Seefracht. Auf seinen Rechnungen stehen Schiffsname, Reisenummer, Konnossement, Ablade- und Bestimmungshafen, Anzahl der Packstücke und Gewicht. Sein Kunde braucht genau diese Angaben, um die Rechnung der richtigen Sendung zuzuordnen. Fehlen sie, ist die Rechnung formal einwandfrei und praktisch unbrauchbar — sie bleibt liegen, bis jemand nachfragt.
In EN 16931 gibt es diese Felder nicht. Die Norm beschreibt eine Rechnung, keine Seefracht.
Das Muster ist nicht auf die Logistik beschränkt. Es trifft jeden, der branchenspezifische Angaben auf der Rechnung führt:
- Handwerk und Bau: Objekt, Bauabschnitt, Auftragsnummer des Auftraggebers
- Maschinenbau: Seriennummer, Maschinennummer, Wartungsintervall
- Agenturen und Beratung: Projektkürzel, Kostenstelle des Kunden, Sprintnummer
- Großhandel: Lieferschein-Nummer, Charge, Abladestelle
Die Sorge dahinter ist berechtigt: Zwingt mich die Umstellung in ein Korsett?
Die kurze Antwort lautet nein. Die etwas längere erklärt, warum — und wo die Grenze tatsächlich verläuft.
Warum die Norm diese Felder nicht hat
Es ist verlockend, das als Lücke zu lesen. Es ist aber eine Entwurfsentscheidung.
EN 16931 definiert ein semantisches Datenmodell: eine feste Menge von Geschäftsbegriffen mit klarer Bedeutung, damit jede Empfängersoftware in Europa dieselbe Rechnung ohne Absprache verarbeiten kann. Genau darin liegt der Nutzen. Eine Norm, die jedem erlaubt, beliebige eigene Felder zu ergänzen, wäre keine Norm mehr — dann müsste jeder Empfänger wieder jeden Absender einzeln anbinden. Also genau der Zustand, den die E-Rechnung ablösen soll.
Der Preis dafür: Ihre Branchendaten stehen nicht im Modell. Das ist kein Versehen, sondern der Zweck.
Nur folgt daraus eben nicht, dass die Angaben von der Rechnung verschwinden müssen.
Eine hybride E-Rechnung hat zwei Ebenen
Genau hier wird das Hybridformat interessant. Eine ZUGFeRD-Rechnung — technisch verwandt mit dem französischen Factur-X — ist ein PDF/A-3, in das die strukturierten Daten als XML eingebettet sind. Das sind zwei Ebenen in einer Datei, und sie haben verschiedene Aufgaben:
Das eingebettete XML ist die maschinenlesbare Ebene. Genormt nach EN 16931, unverändert. Nur weil dort ausschließlich das steht, was die Norm vorsieht, kann die Buchhaltungssoftware des Empfängers die Rechnung automatisch verarbeiten.
Das PDF ist die menschenlesbare Ebene. Das ist Ihr Dokument. Layout, Logo, Reihenfolge, Zusatzangaben — Ihre Entscheidung.
Der Satz, den ich mir für solche Gespräche zurechtgelegt habe:
EN 16931 legt fest, was jeder Empfänger verarbeiten können muss. Nicht, was auf Ihrer Rechnung stehen darf.
In der Praxis: Zusatzdaten mitschicken
Bei invoice-api.xhub sieht das so aus. Sie hängen an die Rechnungsdaten ein zusätzliches Objekt mit Ihren Angaben — hier am Beispiel der Transportdaten:
1{2 "invoice": {3 "invoiceNumber": "RE-2026-0042",4 "type": "invoice",5 "issueDate": "2026-09-01",6 "dueDate": "2026-10-01",7 "currency": "EUR",8 9 "transport": {10 "vessel": "MV MUSTERSCHIFF",11 "voyage": "042",12 "billOfLading": "BL0000000000",13 "portOfLoading": "Musterhafen",14 "portOfDischarge": "Beispielstadt",15 "eta": "2026-10-15",16 "packages": "32",17 "weightKg": "2658"18 },19 20 "seller": { "…": "…" },21 "buyer": { "…": "…" },22 "items": [ "…" ]23 }24}Für die XML-Erzeugung wird dieses Objekt nicht ausgewertet. Die ZUGFeRD-Daten bleiben exakt so, wie sie ohne den Zusatz wären — die Konformität ist unberührt.
Hinweis: Die Vorlagen befinden sich derzeit im Beta-Status. Nutzbar und dokumentiert, aber die API kann sich noch ändern — den jeweils aktuellen Stand zeigt die Dokumentation zu Rechnungsvorlagen.
Im PDF-Template steht jedes Feld des Payloads als Platzhalter zur Verfügung, verschachtelte mit Punkt:
1{{transport.vessel}}2{{transport.billOfLading}}3{{transport.portOfDischarge}}Der natürliche Ort für so eine Liste ist ein keyvalue-Block:
1{2 "type": "keyvalue",3 "data": {4 "items": [5 { "label": "Schiff", "value": "{{transport.vessel}}" },6 { "label": "Reise", "value": "{{transport.voyage}}" },7 { "label": "Konnossement", "value": "{{transport.billOfLading}}" },8 { "label": "Bestimmungshafen", "value": "{{transport.portOfDischarge}}" },9 { "label": "ETA", "value": "{{transport.eta?}}" }10 ]11 }12}Das Fragezeichen hinter eta markiert den Wert als optional. Angaben, die nicht auf jeder Rechnung vorkommen, verschwinden dann einfach, statt eine leere Zeile zu hinterlassen. Wer den ganzen Block nur bei bestimmten Rechnungen zeigen will, hängt eine condition an den Block.
Die vollständige Referenz — alle neun Block-Typen, Design-Tokens, Platzhalter — steht in der Dokumentation zu Rechnungsvorlagen.
Wo die Grenze verläuft
Und jetzt der Teil, der in solchen Artikeln meistens fehlt.
1. Reine XRechnung hat kein PDF
XRechnung ist eine reine XML-Datei. Es gibt dort kein Dokument, auf das man etwas drucken könnte — die Datei ist die Rechnung. Der beschriebene Weg funktioniert also für die hybriden Formate (ZUGFeRD, Factur-X), nicht für reine XRechnung.
Wer an öffentliche Auftraggeber fakturiert und dort XRechnung liefern muss, hat zwei Möglichkeiten: die Felder nutzen, die die Norm selbst für Referenzen und Bemerkungen vorsieht — oder zu klären, ob der Empfänger die Angaben überhaupt maschinell braucht oder ob sie nur ein Mensch liest. Welche Felder dafür in Frage kommen, steht in der Feldreferenz.
2. Was ins XML gehört, gehört auch ins XML
Manches, was auf den ersten Blick nach Branchendatum aussieht, hat in der Norm sehr wohl einen Platz. Die Bestellnummer des Kunden zum Beispiel, oder die Käuferreferenz — bei XRechnung wird dort die Leitweg-ID transportiert.
Solche Angaben gehören in die dafür vorgesehenen Felder, nicht in ein Zusatzobjekt. Sonst stehen sie zwar auf dem Papier, aber die Software des Empfängers findet sie nicht — und genau die soll ja automatisch zuordnen.
Faustregel: Wenn der Empfänger die Angabe maschinell braucht, prüfen Sie zuerst, ob die Norm ein Feld dafür hat. Nur was dort keinen Platz findet und lediglich für den Menschen bestimmt ist, gehört auf die Dokumentebene.
3. Der Empfänger sieht nur das PDF
Klingt banal, wird aber verwechselt. Die Zusatzangaben landen nicht in der Buchhaltungssoftware des Empfängers. Sie stehen auf dem Beleg, den sich jemand ansieht. Wenn Ihr Kunde die Sendungsnummer automatisiert in sein System übernehmen möchte, ist die Dokumentebene der falsche Ort — dann ist das ein Gespräch über die Referenzfelder der Norm.
Ergebnis
Der Empfänger bekommt eine konforme E-Rechnung, die seine Buchhaltung automatisch verarbeitet. Und derselbe Beleg zeigt dem Menschen, der ihn ansieht, zu welcher Sendung, welchem Objekt oder welchem Projekt er gehört.
Es ist kein Kompromiss zwischen Konformität und Praxistauglichkeit. Es sind zwei Ebenen, die für genau diesen Fall gebaut wurden.
Wo Sie stehen, in einem Werktag
Wenn Sie Angaben auf Ihren Rechnungen haben, von denen Sie annehmen, die Norm kenne sie nicht: Der schnellste Weg zu einer belastbaren Antwort ist eine echte Rechnung.
Schicken Sie uns einen Beleg aus Ihrem System. Wir prüfen ihn gegen dieselben KoSIT-Schemas und Geschäftsregeln, die auch der Empfänger anwendet, und sagen Ihnen innerhalb eines Werktags, was durchgeht, was fehlt und welche Ihrer Zusatzangaben wohin gehören. Kostenfrei und ohne Registrierung — den Readiness-Check finden Sie hier.
Wer lieber selbst anfängt: Die Template-Dokumentation enthält alle Block-Typen und Platzhalter, und im Playground lässt sich ein Payload ohne Account durchlaufen.