Wenn du Entwickler bist und gerade gehört hast „die Rechnungen müssen bis zum nächsten Quartal PDF/A-3 mit ZUGFeRD sein”, und dein einziger Kontext ist, dass jemand in der Rechtsabteilung diese Worte gesagt hat, ist dieser Beitrag für dich.

Wir schneiden den Standardisierungs-Dokumente-Ton ab und erklären, was diese Profile tatsächlich einschränken, warum Regierungen anfingen, sie vorzuschreiben, und die kleinste praktische Pipeline, um aus einem strukturierten-Daten-Renderer ein konformes PDF auszugeben.

PDF/A in zwei Absätzen

PDF ist ein flexibles Format. Zu flexibel — dieselbe PDF-Spezifikation lässt dich JavaScript einbetten, auf externe Ressourcen verlinken, die in 50 Jahren möglicherweise nicht existieren, Inhalt mit reversibler Kryptographie verschlüsseln, externe Schriften referenzieren, und hundert weitere Dinge, die ein Dokument nicht-selbsthaltend machen.

PDF/A („A” für Archival) ist ein Profil von PDF, das die Teile verbietet, die das Dokument davon abhalten würden, in 50 Jahren identisch zu rendern. Die High-Level-Regeln:

Alle Schriften müssen eingebettet sein.
Kein JavaScript, keine externen Links, keine Audio-/Video-Daten.
Keine Verschlüsselung.
Alle Transparenz muss geflattet sein oder von der Profilversion unterstützt werden.
Farben müssen geräteunabhängig sein (ICC-Profil erforderlich).
Aller Inhalt muss in der Datei sein — keine Referenzen, die vom Netzwerk abhängen.

Es gibt mehrere Versionen, jede mit Toleranz für neuere Features:

Profil	Jahr	Was es hinzufügt
PDF/A-1b	2005	Original-Baseline — strengste
PDF/A-2b	2011	Erlaubt JPEG2000, Transparenz, Layer
PDF/A-3b	2012	Erlaubt beliebige Datei-Anhänge (Grundlage für ZUGFeRD/Factur-X)
PDF/A-4	2020	ISO 32000-2 (PDF 2.0) Basis, vereinfachte Konformitätsstufen

Das „b”-Suffix bedeutet „basic”-Konformität (visuelle Treue). Es gibt auch „u”- (Unicode-gemappt) und „a”- (Accessibility-getaggt) Varianten — für die meisten Rechnungs-/Quittungs-Workflows ist „b” was du willst, weil die Steuerarchivierung sich für visuelle Reproduzierbarkeit interessiert, nicht für Screenreader-Semantik.

Praktische Erkenntnis: Wenn dein Renderer sagt, er unterstützt PDF/A-3b, sollte es ein einzelnes Konfigurations-Flag sein ({ profile: "PDF/A-3b" } oder Äquivalent). Wenn du ein zweites Tool fahren musst (Ghostscript, qpdf, Acrobat), um danach zu konvertieren, ist das eine Workflow-Lücke, die du in deinen Ops einkalkulieren musst.

Warum PDF/A-3 spezifisch wichtig ist: Es ist der Träger für E-Rechnungen

PDF/A-3 fügte eine Fähigkeit hinzu, die sich als weltverändernd herausstellte: beliebige Datei-Anhänge innerhalb des PDF.

Klingt langweilig. Ist es nicht. Es ist die gesamte technische Grundlage für die E-Rechnungs-Mandate, die gerade über Europa rollen.

Die Architektur: Eine einzige PDF-Datei, die sowohl:

Eine menschenlesbare Rechnung (visuelles Layout, Summen, Branding) — der Teil, den der Mensch liest.
Eine maschinenlesbare XML-Rechnung — der Teil, den die Software der Steuerbehörde parst.

Beides in einer Datei, beides repräsentiert dieselbe Rechnung, und der PDF/A-3-Wrapper garantiert, dass die Datei jahrzehntelang parsbar bleiben wird.

Die zwei Hauptformate:

ZUGFeRD (Deutschland) — XML-Profil basierend auf UN/CEFACT Cross Industry Invoice
Factur-X (Frankreich) — substantiell identisch mit ZUGFeRD (die zwei Standards verschmolzen technisch 2018)
EN 16931 — die europäische Norm, der beide Implementierungen entsprechen

Für die meisten Workflows sind „ZUGFeRD” und „Factur-X” austauschbare Begriffe — sie teilen ein Schema, teilen den Einbettungs-Mechanismus, und ein einzelnes PDF, das mit einem konform ist, ist im Allgemeinen mit dem anderen konform.

Was vorgeschrieben ist, wo, wann

Eine nicht-erschöpfende Momentaufnahme für Entwickler, die Q2/Q3 2026 Rollouts planen:

Land	Status	Erforderliches Format
Deutschland	B2B-Empfang verpflichtend seit 2025-01-01; ab 2027 auch für Ausstellung	EN 16931 (ZUGFeRD / Factur-X / XRechnung)
Frankreich	Ausstellung verpflichtend für Großunternehmen 2026-09; KMU 2027-09	Factur-X via Chorus Pro
Italien	B2B verpflichtend seit 2019	FatturaPA via SDI
Polen	Verpflichtend seit 2024-07	KSeF
Spanien	Verpflichtend ab 2026 (B2B)	Facturae via FACe
Belgien	Verpflichtend ab 2026-01	Peppol BIS 3

Das Muster: Jeder EU-Mitgliedsstaat implementiert eine Variante von EN-16931-konformer E-Rechnung auf einer 2024–2027-Timeline. Wenn deine Kunden in einem dieser Märkte operieren, muss dein PDF-Generator eingebettetes XML neben der visuellen Rechnung ausgeben.

Für deutsche Teams spezifisch: Das Wachstumschancengesetz (verabschiedet 2024-03) ist die rechtliche Grundlage. Praktisch bedeutet es, dass jedes deutsche B2B-Unternehmen ab 2025-01-01 in der Lage sein muss, strukturierte E-Rechnungen zu empfangen und zu verarbeiten — nicht nur PDFs als Bilder, sondern PDF/A-3-Dateien mit eingebettetem ZUGFeRD-XML.

Die kleinste praktische Pipeline

Vergiss, was die Standardisierungs-Dokumente vorschreiben. Hier die Engineering-Sicht:

   ┌─────────────────────┐
   │  Deine Rechnungs-   │  (bereits ein JSON-Objekt irgendwo)
   │       daten         │
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ EN-16931-XML bauen  │  (deterministisches Mapping; bewährte Libs existieren)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ PDF/A-3b rendern +  │
   │ XML anhängen        │  (einzelner API-Aufruf zu gPdf — oder Zwei-Schritt anderswo)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Übergabe an        │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

Die zwei nicht-trivialen Schritte:

Schritt 1: XML bauen

Das ist nervig, aber mechanisch. Du mappst deine Rechnungsdaten (Posten, Steuern, Summen, Parteien) auf EN-16931-XML-Feldnamen. Mehrere Java/Node/Python-Libraries machen das für dich — suche nach „zugferd library” oder „factur-x library” in deiner Sprache. Schreib es nicht von Grund auf neu, es sei denn, du genießt XML-Schema-Spezifikationen wirklich.

Schritt 2: PDF/A-3 rendern und XML anhängen

Hier zählt die Renderer-Wahl.

Ohne eingebaute Unterstützung: Du renderst ein gewöhnliches PDF, dann post-prozessierst mit einem Tool, das zu PDF/A-3 konvertiert und die XML als eingebettete Datei anhängt. Übliche Stacks: Ghostscript + qpdf, oder ein bezahltes Tool wie Aspose. Zwei zusätzliche Schritte, zwei zusätzliche Fehlerpunkte, und du musst sicherstellen, dass das Post-Processing das visuelle Layout nicht driften lässt.

Mit eingebauter Unterstützung (gPdfs Ansatz): Ein Aufruf.

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": {
      "pages": [{ "size": "a4", "elements": [...] }]
    },
    "einvoice": {
      "format": "zugferd",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output rechnung-mit-zugferd.pdf

Das ist die ganze Pipeline. Der Renderer gibt PDF/A-3b aus, hängt deine XML als factur-x.xml (oder zugferd-invoice.xml, beide werden von jedem Konsumenten erkannt) an und gibt die Bytes zurück.

Häufige Stolperfallen

Ein paar Dinge, die Leute auf die harte Tour lernen:

„PDF/A” und „mit PDF/A-konformen Schriften” sind nicht dasselbe

Eine PDF/A-3-Datei verlangt, dass alle Schriften eingebettet sind mit voller Glyphen-Abdeckung der verwendeten Zeichen. Wenn deine Rechnung einen ausländischen Kundennamen hat und der Renderer auf eine Schrift zurückfällt, die nicht voll einbettbar ist, werden Validierungs-Tools sie ablehnen. Prüfe, ob dein Renderer im PDF/A-Modus CJK-Schriften einbettet — viele tun das standardmäßig nicht.

Visuell + XML müssen übereinstimmen

Die XML-Rechnung und die visuelle Rechnung sollen dieselbe Rechnung repräsentieren. Steuerprüfer werden sie diffen. Wenn dein Code XML mit total: 119,00 und das visuelle PDF Gesamt: 120,00 ausgibt (wegen eines Rundungs-Bugs oder eines veralteten Templates), hast du eine Steuer-Diskrepanz in der Akte. Generiere beides aus derselben Source-of-Truth, idealerweise im selben Code-Pfad.

„Profil”-Stufen in EN 16931

Factur-X / ZUGFeRD haben Profile: MINIMUM, BASIC, EN 16931, EXTENDED. Sie unterscheiden sich darin, wie viele Daten in der XML stecken. Verwende BASIC, es sei denn dein Kunde verlangt explizit mehr — es deckt Steuercodes, Posten, Parteien, Summen ab, was für ~95 % der B2B-Rechnungsstellung reicht. Das EN-16931-Profil fügt weitere Details für Edge Cases hinzu.

Validierung vor Einreichung

Validiere immer das generierte PDF gegen einen PDF/A-Validator (veraPDF ist der Open-Source-Standard) und validiere die XML gegen das EN-16931-Schema bevor du an die Steuerbehörde sendest. Fehlgeschlagene Einreichungen bei Chorus Pro / SDI zählen gegen deine Reliability-Metriken beim Regulator.

TL;DR

PDF/A ist ein Selbsthaltend-Dokumenten-Profil. PDF/A-3 lässt dich Dateien anhängen. ZUGFeRD / Factur-X ist „eine EN-16931-XML angehängt in einem PDF/A-3”. E-Rechnungs-Mandate über die EU machen diese Kombination zum De-facto-B2B-Rechnungsformat von 2025–2027.

Wenn dein Renderer PDF/A-3 + ZUGFeRD/Factur-X als einzelnes Konfigurations-Flag behandelt, ist die Migration mechanisch. Wenn nicht, baust du eine Multi-Schritt-Ops-Pipeline. gPdfs /api/v1/e-invoice/render ist die Einzel-Flag-Version — die API-Referenz hat das vollständige Schema, oder probiere ein Beispiel-Rendering im Playground.