LiveES

VeriFactu QR (ES)

Der QR-Code, der auf eine spanische Rechnung gehört: aus NIF, Serie, Rechnungsnummer, Datum und Gesamtbetrag entsteht die AEAT-Prüf-URL — geliefert als URL, als PNG (Base64) und als SVG.

POST/api/v1/invoice/es/verifactu-qr

Ein QR-Code, keine Meldung an die AEAT

Dieser Endpunkt baut den QR-Code und nichts weiter. Er registriert die Rechnung nicht bei der AEAT und übermittelt keine Daten dorthin — er erzeugt die Prüf-URL, die der Empfänger mit dem Handy aufrufen kann, und rendert sie.

Der Host in der URL folgt der Konfiguration des Dienstes, nicht dem Request. Gemessen am 2026-09-15 zeigte die Antwort des gehosteten Dienstes auf den AEAT-Testdienst (prewww2.aeat.es). Wer den Produktions-Host braucht, klärt das vor dem Druck der ersten Rechnung mit uns.

Request

Feld	Typ	Pflicht	Beschreibung
`sellerNif`	string		NIF/CIF des Ausstellers, z. B. B12345678.
`invoiceSeries`	string		Rechnungsserie. Sie bildet mit invoiceNumber den AEAT-Parameter numserie; Sonderzeichen werden URL-kodiert.
`invoiceNumber`	string		Rechnungsnummer innerhalb der Serie.
`invoiceDate`	string		Rechnungsdatum im AEAT-QR-Format DD-MM-YYYY — nicht ISO.
`total`	number		Gesamtbetrag als Zahl. Negative Beträge sind für Gutschriften zulässig.
`verifactuMode`	boolean	-	Veraltet und ohne Wirkung. Die Plattform ist VERI*FACTU-only, der QR zeigt immer auf den ValidarQR-Prüfdienst. Das Feld wird nur aus Rückwärtskompatibilität angenommen und fällt weg.

Beispiel

bash

1curl -X POST https://service.invoice-api.xhub.io/api/v1/invoice/es/verifactu-qr \
2  -H "Authorization: Bearer sk_live_abc123..." \
3  -H "Content-Type: application/json" \
4  -d '{
5    "sellerNif": "B12345678",
6    "invoiceSeries": "A",
7    "invoiceNumber": "2026-0042",
8    "invoiceDate": "20-03-2026",
9    "total": 5712.00
10  }'

Response

200 OK

json

1{
2  "url": "https://prewww2.aeat.es/wlpl/TIKE-CONT/ValidarQR?nif=B12345678&numserie=A%2F2026-0042&fecha=20-03-2026&importe=5712.00",
3  "png": "iVBORw0KGgoAAAANSUhEUgAAAMQAAA...",
4  "svg": "<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 49 49\" shape-rendering=\"crispEdges\">..."
5}

Gemessen am 2026-09-15: numserie entsteht als Serie, Schrägstrich, Rechnungsnummer (hier A/2026-0042) und wird URL-kodiert — das Beispiel in der OpenAPI-Datei schreibt es ohne Trennzeichen. Der Wert in der Antwort ist maßgeblich; die URL selbst wird nicht zusammengebaut, sondern übernommen.

Feld	Typ	Beschreibung
`url`	string	Die AEAT-Prüf-URL, die im QR-Code steckt.
`png`	string	Der QR-Code als PNG, Base64-kodiert und ohne data:-Präfix.
`svg`	string	Derselbe QR-Code als SVG-Markup.

Fehlerfälle

Status	Code	Beschreibung
400	`Bad Request`	Ein Feld fehlt oder hat den falschen Typ.
401	`UNAUTHORIZED`	API-Schlüssel fehlt oder ist ungültig.
403	`FORBIDDEN`	Die Berechtigung fehlt: gebraucht wird e-invoice:es:facturae:create.

Die spanische Rechnung selbst

Der QR-Code ist ein Zusatz auf dem Beleg, nicht der Beleg. Die Rechnung selbst entsteht über den Creator: für Spanien stehen dort Facturae und PDF bereit — der QR wird in die PDF-Vorlage gesetzt.

Creator API

Weiterführende Dokumentation

Creator API

Spanische Rechnungen erzeugen

Formats API

Formate je Land abrufen

Validator API

Rechnungen validieren

Error Handling

Fehler verstehen