Nordlet

← Dokumentation / Glossar

Was ist ein EPC-QR-Code? Scan-to-Pay auf Rechnungen

Der QR-Standard des European Payments Council für SEPA-Überweisungen – was die Nutzdaten enthalten, warum er Zahlungsfehler vermeidet und wo er eingesetzt wird.

Ein EPC-QR-Code ist ein quadratischer Barcode auf einer Rechnung, den Kundinnen und Kunden mit ihrer Banking-App scannen, um die Zahlungsdaten automatisch vorausfüllen zu lassen: Ihre IBAN, Ihren Namen, den Betrag und den Verwendungszweck. Sie müssen die Zahlung nur noch bestätigen und absenden.

Er ist vom European Payments Council in den Quick Response Code Guidelines to Enable Data Capture for the Initiation of a SEPA Credit Transfer definiert und bewusst schlank gehalten: Er initiiert eine SEPA-Überweisung und sonst nichts.

Welches Problem er löst

Manuelle Zahlungseingaben sind eine häufige Fehlerquelle, bei der Geld verloren gehen kann. Wenn Kundinnen oder Kunden eine 20-stellige IBAN und eine Referenznummer aus einem PDF manuell in ihre Banking-App übertragen, vertippen sie sich gelegentlich bei einer Ziffer, vergessen den Verwendungszweck oder tippen den Betrag falsch ein.

Jeder dieser Fehler verursacht auf Ihrer Seite Aufwand und Kosten. Eine falsche Referenz führt dazu, dass die Zahlung unzugeordnet auf Ihrem Konto eingeht, und jemand muss klären, zu welcher Rechnung sie gehört – genau das Problem, das der Zahlungsabgleich (Bank Reconciliation) lösen soll. Eine falsche IBAN kann dazu führen, dass das Geld vollständig auf einem anderen Konto landet.

Ein gescannter QR-Code macht das Tippen überflüssig, womit diese gesamte Fehlerklasse entfällt. Zudem verkürzt er den Weg vom „Rechnung lesen“ bis zum „Zahlung gesendet“ auf wenige Sekunden, was bei B2C- und Kleinunternehmerrechnungen messbar die Zahlungseingangsquote verbessert.

Was die Nutzdaten enthalten

Der Payload nach EPC069-12 besteht aus Klartext, ein Feld pro Zeile, in einer festen Reihenfolge:

BCD                        ← Service-Tag
002                        ← Version
1                          ← Zeichensatz (1 = UTF-8)
SCT                        ← Identifikation (SEPA Credit Transfer)
                           ← BIC (im EWR optional)
UAB Pavyzdys               ← Name des Zahlungsempfängers
LT121000011101001000       ← IBAN des Zahlungsempfängers
EUR605.00                  ← Betrag mit Währungsvorsilbe
                           ← Zweckcode (optional)
                           ← Strukturierte Überweisungsreferenz
Invoice S-1041             ← Unstrukturierter Verwendungszweck
                           ← Informationen vom Zahlungsempfänger an den Zahler

Wichtige Einschränkungen: Die Gesamtnutzlast darf 331 Bytes nicht überschreiten; der Betrag muss zwischen 0,01 und 999.999.999,99 EUR liegen; es wird ausschließlich der Euro unterstützt; und Sie verwenden entweder die strukturierte Referenz oder den unstrukturierten Text, niemals beides gleichzeitig.

Das strukturierte Feld ist für eine Gläubigerreferenz wie ISO 11649 RF gedacht, deren Verwendung sich anbietet, sofern Ihr Markt dies unterstützt – eine maschinenprüfbare Referenz lässt sich zuverlässiger abgleichen als Freitext.

Bemerkenswert ist, dass die Nutzdaten weder eine Signatur noch Sicherheitsmerkmale enthalten. Es handelt sich um eine Erleichterung für die Dateneingabe und nicht um eine authentifizierte Anweisung: Der Zahler autorisiert die Zahlung nach wie vor in seiner eigenen Banking-App im Rahmen seiner eigenen Authentifizierung. Aus diesem Grund kann ein QR-Code nicht eigenständig Geld bewegen – und deshalb ist ein QR-Code auf einer betrügerischen Rechnung genau so gefährlich wie eine als Text abgedruckte betrügerische IBAN.

Wo er eingesetzt wird

Er ist im gesamten Euroraum weit verbreitet und in einigen Ländern – Österreich, Deutschland, Belgien, den Niederlanden, Finnland – de facto Standard, da große Banking-App-Anbieter ihn nativ erkennen. Einige Länder nutzen eigene etablierte Varianten: die Schweizer QR-Rechnung (ein anderer, stärker reglementierter Standard) und diverse nationale Verfahren, die älter sind als EPC069-12.

Die Unterstützung hängt von der Banking-App des Zahlers ab, nicht von Ihrer. Das Hinzufügen des Codes kostet Sie nichts und hilft jedem Kunden, dessen App ihn lesen kann; diejenigen, deren Apps dies nicht unterstützen, bezahlen einfach auf dem gewohnten Weg.

Ähnlich, aber anders

  • SEPA Request-to-Pay (RTP) – ein Nachrichtenstandard, bei dem der Zahlungsempfänger eine strukturierte Zahlungsanforderung sendet, die der Zahler in seiner App annehmen oder ablehnen kann. Dies gleicht eher einem Dialog als einem gedruckten Code und kann ein Fälligkeitsdatum sowie Ratenzahlungsoptionen enthalten.
  • Zahlungslinks (Payment Links) – eine URL zu einem gehosteten Checkout, meist über einen Zahlungsdienstleister (PSP), die Kreditkarten und Wallets unterstützt. Dies läuft über einen anderen Weg mit anderen Kosten; eine Kartenzahlung ist mit Acquiring-Gebühren verbunden, während eine per QR-Code initiierte SEPA-Überweisung gebührenfrei ist, was bei Rechnungen über höhere Beträge einen echten wirtschaftlichen Unterschied macht. Solche PSP-Prozesse erzeugen Abrechnungen, die einen Zahlungsabgleich erfordern.

Status in Nordlet

Nicht implementiert. Rechnungs-PDFs enthalten derzeit keinen EPC-QR-Code, und es findet keine Generierung von Zahlungslinks statt. Beides ist geplant; aktuell ist jedoch nichts davon verfügbar, und es ist zielführender, dies offen zu kommunizieren, als eine Absicht als bereits vorhandenes Feature darzustellen.

Bereits vorhanden sind die für den Code benötigten Daten – Unternehmens-IBAN, Partnerdetails, Rechnungsbetrag, Währung und die vollständige Rechnungsnummer als Verwendungszweck – sowie der entsprechende Generierungspfad: Rechnungs-PDFs werden über die API erstellt, sodass der QR-Code künftig eher eine visuelle Ergänzung bei der Darstellung (Rendering) als ein neues Datenmodell darstellt.

Zwei Einschränkungen, die eine künftige Implementierung vom Standard selbst übernimmt: Nur Euro, sodass Rechnungen in anderen Fremdwiruchgen keinen entsprechenden QR-Code tragen können, sowie die Begrenzung der Nutzlast auf 331 Bytes, welche limitiert, wie viel Text aus einer langen Rechnungsnummer und dem Firmennamen maximal im Verwendungszweck untergebracht werden können.

Bis dahin sind die Mechanismen auf der Abgleichseite entscheidend: die Rechnungsnummer gut sichtbar auf der Rechnung zu platzieren und auf den Bankabgleich zu vertrauen, der Zahlungsbeschreibungen mit enthaltener Dokumentennummer zuordnet.

FAQ

Was ist ein EPC-QR-Code?

Ein QR-Code nach dem Standard des European Payments Council, der die Details einer SEPA-Überweisung codiert – Name des Empfängers, IBAN, Betrag und Verwendungszweck –, sodass ein Zahler diesen mit seiner Banking-App scannen kann, anstatt die Daten manuell einzutippen.

Ist eine Zahlung per QR-Code sicher?

Der Code selbst enthält keinerlei Sicherheitsmerkmale oder Signaturen; er dient lediglich dem Vorausfüllen eines Überweisungsformulars. Der Zahler autorisiert die Überweisung weiterhin in seiner eigenen Banking-App mit seiner persönlichen Authentifizierung. Es handelt sich um eine Erleichterung bei der Dateneingabe, weshalb ein Code auf einer gefälschten Rechnung genauso riskant ist wie eine betrügerische IBAN im Klartext.

Welche Währungen werden unterstützt?

Ausschließlich Euro. Der Standard ist speziell auf SEPA-Überweisungen ausgelegt, weshalb Rechnungen in anderen Währungen keinen konformen EPC-QR-Code tragen können.

Unterstützen alle europäischen Banking-Apps EPC-QR-Codes?

Die meisten großen Apps im Euroraum tun dies, und in einigen Ländern ist der Standard fest etabliert. Die Unterstützung hängt jedoch letztlich von der Bank des Zahlers ab. Das Hinzufügen des Codes unterstützt alle Kunden, die ihn nutzen können, und verursacht keine Nachteile für diejenigen, bei denen dies nicht der Fall ist.

Worin besteht der Unterschied zwischen einem EPC-QR-Code und einem Zahlungslink?

Ein QR-Code initiiert eine Banküberweisung, die der Zahler eigenständig ohne Bearbeitungsgebühren ausführt. Ein Zahlungslink öffnet einen gehosteten Checkout, meist für Kreditkarten oder Wallets über einen Zahlungsdienstleister, welcher mit Gebühren verbunden ist und Abrechnungen erzeugt, die im Nachgang abgeglichen werden müssen.