gPdf
Anwendungsfälle · EU-E-Rechnung und Finanzen

EU-E-Rechnungen: PDF/A-3 mit eingebettetem Factur-X / ZUGFeRD

Generieren Sie EN-16931-E-Rechnungen aus JSON: PDF/A-3-Hülle mit eingebettetem CII-XML-Anhang, konform mit Factur-X oder ZUGFeRD. Prüfen Sie beide Ebenen kostenlos auf gpdf.com/validator/.

Zu erledigende Aufgabe

EU-konforme elektronische Rechnungen aus einem JSON DocumentRequest ausstellen: eine PDF/A-3-Hülle, die ein Kreditorenteam lesen kann, mit eingebettetem CII-XML-Anhang nach EN 16931, den eine Steuerbehörde maschinell verarbeiten kann. Ein API-Aufruf muss beides erzeugen, und beide Ebenen müssen gegen Referenz-Engines validieren, nicht nur gegen den eigenen Checker des Anbieters.

Warum gPdf dafür passt

  • POST /api/v1/e-invoice/render: ein einzelner Endpoint, der ein Factur-X- oder ZUGFeRD-PDF/A-3 in einem Roundtrip zurückgibt.
  • PDF/A-3b-Hülle wird automatisch mit korrektem XMP-Namespace, AFRelationship='Alternative' und Metadaten für eingebettete Dateien gemäß Factur-X- / ZUGFeRD-Basis erzeugt.
  • EN 16931 CII XML wird als kanonische strukturierte Nutzlast angehängt und ist für AP-Automation-Tools in der gesamten EU lesbar.
  • Der Strict-Validation-Modus führt vollständige Schematron-Prüfungen asynchron aus und gibt neben dem PDF ein Report-Artefakt zurück.
  • Datenresidenzprofile (`eu` / `global` / `auto`), damit AP/AR-Teams unter GDPR E-Rechnungsartefakte in EU-Regionen halten können.
  • Der kostenlose öffentliche Validator auf gpdf.com/validator/ führt veraPDF (PDF/A-Ebene) UND Mustang (CII-XML- / EN-16931-Ebene) parallel aus: unabhängige Verifikation, bevor Sie Produktion anbinden.

Beispiel-Request

POST /api/v1/e-invoice/render: minimale Factur-X-Anfrage mit eingebettetem CII XML.

{
  "settings": {
    "profile": "pdfa-3b",
    "e_invoice": {
      "standard": "factur_x",
      "profile": "en16931",
      "document_type": "invoice",
      "xml": {
        "format": "cii",
        "encoding": "utf8",
        "content": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
      }
    }
  },
  "pages": [
    { "size": "a4", "elements": [] }
  ]
}

Compliance und Konformität

  • Factur-X 1.0: gemeinsame französisch-deutsche Spezifikation, für französische B2B-Rechnungen ab 2026 schrittweise verpflichtend.
  • ZUGFeRD 2.x: deutsche Spezifikation, konform mit EN 16931; seit 2025 für den Empfang deutscher B2B-Rechnungen verpflichtend.
  • EN 16931: das paneuropäische semantische Modell für E-Rechnungen, das sowohl Factur-X als auch ZUGFeRD verpacken.
  • PDF/A-3: das Archivhüllenformat, das nötig ist, um einen eingebetteten XML-Anhang rechtssicher aufzunehmen (ISO 19005-3).
  • Validierung: Verlassen Sie sich nicht auf die Eigenprüfung eines einzelnen Anbieters. Unabhängige Prüfung mit veraPDF (PDF/A) + Mustang (CII XML) ist das audit-taugliche Muster.

Die Form einer EU-E-Rechnung und warum zwei Formate übereinanderliegen

Eine moderne EU-E-Rechnung besteht aus zwei Dokumenten in einer Datei:

  1. Einem PDF/A-3, das Menschen lesen können: Rechnungsnummer, Positionen, Summen, Lieferantenbranding. Die PDF/A-3-Spezifikation (ISO 19005-3) ist die einzige PDF/A-Variante, die beliebige Dateianhänge innerhalb der Archivhülle erlaubt.
  2. Einem EN 16931 CII XML-Anhang innerhalb dieses PDFs: dieselbe Rechnung als strukturierte Daten, die AP-Automation, ERP-Importe und Systeme von Steuerbehörden ohne OCR parsen können.

Factur-X (Frankreich) und ZUGFeRD (Deutschland) sind dieselbe Idee unter unterschiedlichen nationalen Bezeichnungen. Beide hängen ein EN 16931 Cross-Industry Invoice (CII) XML an eine PDF/A-3-Hülle. ZUGFeRD ist seit 2025 für den Empfang deutscher B2B-Rechnungen verpflichtend; Factur-X wird in Frankreich 2026-2027 schrittweise für die B2B-Ausstellung verpflichtend.

Wenn Sie 2026 Rechnungen an französische oder deutsche Kunden senden, ist eines dieser beiden Formate nicht mehr optional.

Warum die Generierung von Grund auf mühsam ist und warum gPdf daraus einen Endpoint macht

Das von Grund auf zusammenzusetzen bedeutet:

  1. PDF-Bytes erzeugen: Satz, Fonts, Layout.
  2. Das CII XML separat erzeugen und auf EN 16931 abstimmen.
  3. Den PDF/A-3-XMP-Namespace korrekt setzen (urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# für Factur-X; der ZUGFeRD-2.x-Namespace unterscheidet sich).
  4. Das XML gemäß Spezifikation mit AFRelationship="Alternative" einbetten.
  5. Die eingebettete Datei im /AF-Array von PDF/A-3 korrekt markieren.
  6. Das Ergebnis mit veraPDF (PDF/A-Ebene) UND Mustang (CII-XML-Ebene) validieren. Beide müssen bestehen.

Ein typisches Team macht das zweimal falsch, bevor beide Engines bestehen. Die gPdf API reduziert alle sechs Schritte auf einen einzigen Aufruf von POST /api/v1/e-invoice/render. Sie liefern:

  • settings.e_invoice.standard: factur_x oder zugferd
  • settings.e_invoice.xml.content: Ihr CII XML
  • pages[]: das sichtbare Rechnungslayout
  • alles andere wird automatisch mit den korrekten PDF/A-3-Metadaten erzeugt.

Siehe §5 der E-Invoice API Referenz für das vollständige Request-Schema, Validierungsmodi (basic versus strict) und den asynchronen Job-Lifecycle für Strict-Validation-Läufe.

Ausgabe prüfen: das Audit-Muster

Die Aussage eines Anbieters “ja, unser PDF besteht PDF/A-3” ist wenig wert, wenn der Auditor die Referenz-Engines verwendet. Das audit-taugliche Muster ist:

  1. Generieren Sie die E-Rechnung über POST /api/v1/e-invoice/render.
  2. Laden Sie das resultierende PDF in den validator. Er führt aus:
    • veraPDF: die offizielle Referenzimplementierung der PDF Association für PDF/A-3-Konformität.
    • Mustang: ein deutsches Open-Source-Projekt (mustangproject.org), das de facto als Referenzchecker für Factur-X / ZUGFeRD dient. Es extrahiert das eingebettete CII XML, validiert gegen EN 16931 Schematron und berichtet feldweise.
  3. Beide Berichte erscheinen nebeneinander in derselben UI. Beide müssen “Pass” zeigen, bevor Sie die Rechnung in produktive AP-Automation schicken.

Dieses Muster ist wichtig, weil:

  • Ein PDF, das veraPDF besteht, aber Mustang nicht besteht, eine konforme Hülle hat, aber fehlerhaftes XML enthält. Das AP-System weist die Rechnung beim Empfang zurück.
  • Ein PDF, das Mustang besteht, aber veraPDF nicht besteht, hat korrektes XML, erfüllt aber nicht die PDF/A-3-Anforderungen an die Archivhülle. Die Langzeitarchivierung weist es zurück.
  • Jeder der beiden Fehler bricht den End-to-End-Fluss. Beide müssen bestehen.

Der Validator ist kostenlos, erfordert kein Login und erzeugt JSON-Reports, die Sie Ihren QA-Nachweisen beilegen können. Es ist dasselbe Zwei-Engine-Muster, das Big-Four-Prüfungsgesellschaften intern verwenden. gPdf stellt es nur öffentlich bereit.

Über Factur-X / ZUGFeRD hinaus

Wenn Sie auch mit Folgendem arbeiten:

  • FatturaPA (Italien, seit 2019 verpflichtend): bereits auf der Validator-Roadmap.
  • Peppol BIS 3.0 UBL (Nordics / Benelux / zunehmend grenzüberschreitend): Roadmap.
  • KSeF (Polen, verpflichtend 2026): Roadmap.

Der E-Rechnungs-Endpoint von gPdf erweitert die Abdeckung, sobald jedes Format von “frühe Roadmap” zu “live im Validator und Renderer” übergeht. Die Form bleibt gleich: ein JSON-Request, der richtige XMP-Namespace und AFRelationship intern erledigt, beide Engines prüfen vor dem Versand.

TL;DR

  • Ein API-Aufruf → PDF/A-3 + eingebettetes EN 16931 CII XML.
  • Wählen Sie Factur-X oder ZUGFeRD über settings.e_invoice.standard.
  • Prüfen Sie mit dem validator: veraPDF + Mustang parallel, kostenlos.
  • Beide Engines müssen bestehen. Die gPdf API ist dafür gebaut; der Validator ist der öffentliche Beleg.

Weiterlesen