Welche ZUGFeRD-Version unterstützt QuoteCash?

Die aktuelle Implementierung beansprucht keine konkrete ZUGFeRD- oder Factur-X-Version. Sie erzeugt generisches EN-16931-CII-XML ohne releasespezifische Guideline-ID und ohne die D22B-Validierungsartefakte von ZUGFeRD 2.5 / Factur-X 1.09.

Welche Profile unterstützt die API?

QuoteCash erzeugt derzeit ausschließlich das Profil EN16931; es ist zugleich der Standardwert. MINIMUM, BASIC WL, BASIC und EXTENDED werden von diesem Endpunkt nicht erzeugt. Empfängerspezifische Anforderungen können zusätzlich gelten.

Wird nur das XML oder auch die PDF/A-Konformität validiert?

Nur das erzeugte CII-XML wird an den konfigurierten Validator gesendet. QuoteCash führt derzeit keine unabhängige PDF/A-3-Konformitätsprüfung durch und validiert weder Attachment- noch XMP-Metadaten des PDFs.

Darf ich ein bei Validierungsfehlern zurückgegebenes PDF versenden?

Nein. Der Legacy-Endpunkt baut nach einer fehlgeschlagenen XML-Validierung kein PDF zusammen; die 422-Antwort enthält XML und Validierungsdetails ausschließlich zur Diagnose. Korrigieren Sie das Payload und validieren Sie erneut, bevor Sie das Ergebnis versenden oder final archivieren.

Wie hängen ZUGFeRD und Factur-X zusammen?

Beim aktuellen gemeinsamen Release sind ZUGFeRD 2.5 und Factur-X 1.09 die deutsche und französische Bezeichnung technisch identischer Formate. Diese Aussage macht die aktuelle generische CII-Ausgabe von QuoteCash nicht automatisch zu diesem Release.

Liefert QuoteCash ein Hybrid-PDF oder nur XML?

Bei erfolgreicher XML-Validierung liefert der Endpoint ein PDF mit angehängter factur-x.xml sowie das XML separat. Die Antwort belegt jedoch keine PDF/A-3-Konformität.

Ist ZUGFeRD für öffentliche Auftraggeber geeignet?

Das hängt vom Empfänger und Profil ab. Viele öffentliche Prozesse erwarten XRechnung oder klare Portalvorgaben. Vor dem Versand sollte das gewünschte Format beim Empfänger geprüft werden.

Wie sollte die hybride Rechnung aufbewahrt werden?

Bewahren Sie die erfolgreich übermittelte hybride Originaldatei unverändert auf. Das zusätzlich zurückgegebene XML kann für Verarbeitung und Prüfung gespeichert werden; entscheidend ist, dass der strukturierte Originalinhalt unversehrt erhalten bleibt.

API für hybride Rechnungen

ZUGFeRD API für hybride PDF/XML-Rechnungen

Erzeugen Sie per REST API ein lesbares Rechnungs-PDF mit eingebettetem strukturiertem CII-XML.

PDF und XML entstehen aus demselben angenommenen Rechnungs-Payload. QuoteCash validiert das XML vor der Einbettung und liefert das Ergebnis mit den erzeugten Dateien zurück.

Hybrid-PDF + CII-XMLProfil EN 16931XML-Validierung inklusive

01QuoteCash

Hybrides Rechnungsdokument

Bei Erfolg liefert POST /api/v1/invoices/zugferd ein Base64-PDF mit angehängter factur-x.xml sowie das erzeugte CII-XML als separates Antwortfeld.

02QuoteCash

Transparente XML-Validierung

Das erzeugte XML wird über den konfigurierten KoSIT-kompatiblen Dienst geprüft. Eine 422-Antwort enthält XML und Fehlerdetails zur Diagnose, aber kein versandfertiges PDF.

03QuoteCash

REST API für Integrationen

Geschäftsbezogene API-Keys und planbare JSON-Antworten passen in Billing-, ERP-, Agentur- und SaaS-Workflows. Der Legacy-Endpunkt speichert die Rechnung nicht.

API-Details

Wie QuoteCash das hybride Dokument erzeugt und prüft

POST /api/v1/invoices/zugferd überführt das angenommene JSON-Payload in generisches EN-16931-CII-XML, validiert dieses XML, erzeugt das sichtbare PDF und hängt factur-x.xml an. Die erfolgreiche Antwort enthält PDF, XML, Validierungsergebnis und Dateinamen.

Der Generator verwendet den UN/CEFACT-CII-Namespace mit der Endung :100 und die generische Guideline-ID urn:cen.eu:en16931:2017. Eine releasespezifische ZUGFeRD-/Factur-X-Kennung fehlt; QuoteCash beansprucht deshalb derzeit keine Konformität mit ZUGFeRD 2.5 / Factur-X 1.09.

Die Validierung umfasst die XML-Regeln des konfigurierten Dienstes. PDF-Container, PDF/A-Stufe, Attachment-Relationship und XMP-Metadaten werden nicht unabhängig validiert. Eine 422-Antwort enthält nur Diagnose-XML und Validierungsdetails.

Zielgruppen

Für wen eignet sich der hybride Workflow?

Freiberufler und kleine Unternehmen

Ein vertrautes Rechnungsdokument erzeugen und zugleich strukturierte Daten für die automatische Verarbeitung bereitstellen.

Software- und SaaS-Anbieter

Serverseitige PDF/XML-Erzeugung und eindeutige Validierungsergebnisse in Billing-Produkte integrieren.

Agenturen und Reseller

Einen dokumentierten Antwortvertrag nutzen und ungültiges XML kontrolliert in die Korrektur geben.

ERP-Integratoren

Rechnungsdaten, XML-Validierung und Artefaktbehandlung ohne manuellen Export verbinden.

Redaktioneller Hinweis

Zuletzt fachlich geprüft: 24. Juli 2026

Technischer Stand mit klaren Grenzen

QuoteCash erzeugt derzeit ein PDF mit angehängtem generischem EN-16931-CII-XML. XML-Validierung, PDF/A-Konformität und die formale Unterstützung einer konkreten ZUGFeRD-/Factur-X-Version sind getrennte Aussagen.

Praxiswissen

Aktueller Standard und tatsächlicher Implementierungsstand

Das aktuelle gemeinsame Release ZUGFeRD 2.5 / Factur-X 1.09 ist technisch identisch, basiert auf UN/CEFACT CII D22B und soll laut FeRD seit dem 1. Juli 2026 verwendet werden. Es umfasst eigene XSD- und Schematron-Artefakte für fünf Profile.

QuoteCash verwendet diese releasespezifischen Artefakte derzeit nicht. Der interne xmlbuilder2-Generator schreibt CII im Namespace :100 mit der generischen Guideline-ID urn:cen.eu:en16931:2017. Deshalb nennt die Produktbeschreibung keine unterstützte ZUGFeRD-Version.

Praxiswissen

Profil EN16931 und Empfängeranforderungen

Der Generator erzeugt ausschließlich die generische EN16931-Ausprägung; EN16931 ist zugleich der Standardwert. Andere Profilwerte verändern das XML nicht und werden im kanonischen Artefakt-Request abgewiesen.

MINIMUM und BASIC WL würden die normalen EN-16931-basierten Anforderungen an eine deutsche B2B-E-Rechnung nicht erfüllen. QuoteCash bietet diese Profile ebenso wenig an wie BASIC oder EXTENDED. Öffentliche Auftraggeber und andere Empfänger können zusätzlich XRechnung, Leitweg-ID oder Portalvorgaben verlangen.

Praxiswissen

XML-Validierung ist keine PDF/A-3-Validierung

QuoteCash sendet das erzeugte CII-XML an den konfigurierten KoSIT-kompatiblen Validierungsdienst. Dessen konkrete XSD-, Schematron- und Codelistenstände werden durch die Dienstkonfiguration bestimmt und sind nicht im Repository versioniert.

Erst nach erfolgreicher XML-Prüfung wird factur-x.xml mit pdf-lib an das sichtbare PDF angehängt. Es läuft kein unabhängiger PDF/A-3-Validator; auch XMP-Metadaten und die Beziehung der eingebetteten Datei werden nicht geprüft. Das Ergebnis darf daher nicht als nachgewiesen PDF/A-3-konform beworben werden.

Praxiswissen

Inhaltsidentität, Fehlerfälle und Aufbewahrung

Sichtbares PDF und strukturiertes XML müssen dieselben Rechnungsangaben abbilden. QuoteCash leitet beide aus demselben angenommenen API-Payload ab, nutzt dafür aber getrennte Transformationen; Summen, Steuern, Parteien, Zahlungsdaten und Positionen sollten deshalb in Integrationstests verglichen werden. Bei Abweichungen ist bei einer hybriden E-Rechnung der strukturierte Teil maßgeblich.

Schlägt die XML-Validierung fehl, liefert der Legacy-Endpunkt nur XML und Fehlerdetails mit Status 422; ein PDF wird nicht zusammengebaut. Das Diagnose-XML darf nicht als gültige E-Rechnung versendet oder final archiviert werden. Für die Aufbewahrung sollte die übermittelte hybride Originaldatei unverändert erhalten bleiben; umsatzsteuerlich nennt das BMF acht Jahre. Dies ist keine Rechtsberatung.

Beispiel

API-Beispiel: hybrides PDF erzeugen

Dieses Beispiel entspricht dem tatsächlichen Request-Schema. Der Legacy-Endpunkt verwendet EN16931 als festes Profil und speichert die Rechnung nicht.

POST /api/v1/invoices/zugferd
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "schema_version": "1",
  "invoice_number": "RE-2026-2048",
  "issue_date": "2026-07-24",
  "due_date": "2026-08-07",
  "currency": "EUR",
  "seller": {
    "name": "Muster GmbH",
    "vat_id": "DE123456789",
    "street": "Musterstraße 1",
    "city": "Berlin",
    "postal_code": "10115",
    "country": "DE",
    "email": "rechnung@muster.example",
    "phone": "+49 30 123456"
  },
  "buyer": {
    "name": "Kunde GmbH",
    "vat_id": "DE987654321",
    "street": "Kundenweg 2",
    "city": "Hamburg",
    "postal_code": "20095",
    "country": "DE"
  },
  "line_items": [
    {
      "description": "Support package",
      "quantity": 10,
      "price": 95,
      "total": 950,
      "vatRate": 19,
      "unitCode": "C62"
    }
  ],
  "totals": {
    "net": 950,
    "tax": 180.5,
    "gross": 1130.5
  },
  "payment": {
    "iban": "DE02120300000000202051",
    "bic": "BYLADEM1001"
  }
}

Umsetzung

Implementierungs-Checkliste für ZUGFeRD

1Prüfen, ob der Empfänger EN16931, XRechnung oder eine andere konkrete Ausprägung erwartet.
2Das dokumentierte Payload mit vollständigen Parteien, Positionen, Summen und Zahlungsdaten senden.
3validation.valid prüfen und 422-Antworten ausschließlich zur Diagnose verwenden.
4Beträge, Steuerlogik und Kerndaten im sichtbaren PDF und im XML vergleichen.
5Vor Produktivversand eine unabhängige PDF/A- und Metadatenprüfung ergänzen, wenn formale ZUGFeRD-Konformität erforderlich ist.
6Die erfolgreich übermittelte hybride Originaldatei unverändert im eigenen Aufbewahrungsprozess sichern.

Weiterführende QuoteCash-Seiten

XRechnung APIReines XML für Empfänger mit strikt strukturiertem Annahmeprozess.XRechnung ValidatorXML prüfen, bevor hybride oder reine strukturierte Rechnungen versendet werden.Cashflow Forecast API für offene RechnungenErwartete Zahlungseingänge und überfällige Forderungen aus gespeicherten Rechnungsdaten abrufen.

Offizielle Quellen und Standards

FeRD: ZUGFeRD 2.5 / Factur-X 1.09FeRD beschreibt das aktuelle gemeinsame Release, CII D22B, die fünf Profile sowie die dazugehörigen XSD- und Schematron-Artefakte.FeRD: Standardübersicht und InhaltsidentitätDie Übersicht erläutert Hybridformat, PDF/A-3 und die erforderliche inhaltliche Identität von sichtbarer und strukturierter Rechnung.BMF: E-Rechnung, führender XML-Teil und AufbewahrungDas BMF erläutert zulässige Formate, den maßgeblichen strukturierten Teil und die umsatzsteuerliche Aufbewahrung von Rechnungen für acht Jahre.

Häufige Fragen

Welche ZUGFeRD-Version unterstützt QuoteCash?: Die aktuelle Implementierung beansprucht keine konkrete ZUGFeRD- oder Factur-X-Version. Sie erzeugt generisches EN-16931-CII-XML ohne releasespezifische Guideline-ID und ohne die D22B-Validierungsartefakte von ZUGFeRD 2.5 / Factur-X 1.09.
Welche Profile unterstützt die API?: QuoteCash erzeugt derzeit ausschließlich das Profil EN16931; es ist zugleich der Standardwert. MINIMUM, BASIC WL, BASIC und EXTENDED werden von diesem Endpunkt nicht erzeugt. Empfängerspezifische Anforderungen können zusätzlich gelten.
Wird nur das XML oder auch die PDF/A-Konformität validiert?: Nur das erzeugte CII-XML wird an den konfigurierten Validator gesendet. QuoteCash führt derzeit keine unabhängige PDF/A-3-Konformitätsprüfung durch und validiert weder Attachment- noch XMP-Metadaten des PDFs.
Darf ich ein bei Validierungsfehlern zurückgegebenes PDF versenden?: Nein. Der Legacy-Endpunkt baut nach einer fehlgeschlagenen XML-Validierung kein PDF zusammen; die 422-Antwort enthält XML und Validierungsdetails ausschließlich zur Diagnose. Korrigieren Sie das Payload und validieren Sie erneut, bevor Sie das Ergebnis versenden oder final archivieren.
Wie hängen ZUGFeRD und Factur-X zusammen?: Beim aktuellen gemeinsamen Release sind ZUGFeRD 2.5 und Factur-X 1.09 die deutsche und französische Bezeichnung technisch identischer Formate. Diese Aussage macht die aktuelle generische CII-Ausgabe von QuoteCash nicht automatisch zu diesem Release.
Liefert QuoteCash ein Hybrid-PDF oder nur XML?: Bei erfolgreicher XML-Validierung liefert der Endpoint ein PDF mit angehängter factur-x.xml sowie das XML separat. Die Antwort belegt jedoch keine PDF/A-3-Konformität.
Ist ZUGFeRD für öffentliche Auftraggeber geeignet?: Das hängt vom Empfänger und Profil ab. Viele öffentliche Prozesse erwarten XRechnung oder klare Portalvorgaben. Vor dem Versand sollte das gewünschte Format beim Empfänger geprüft werden.
Wie sollte die hybride Rechnung aufbewahrt werden?: Bewahren Sie die erfolgreich übermittelte hybride Originaldatei unverändert auf. Das zusätzlich zurückgegebene XML kann für Verarbeitung und Prüfung gespeichert werden; entscheidend ist, dass der strukturierte Originalinhalt unversehrt erhalten bleibt.