GiroCode vs. trackbarer QR-Code: Was Agenturen auf Rechnungen wissen müssen

# GiroCode vs. trackbarer QR-Code: Was Agenturen auf Rechnungen wissen müssen

Ein Kunde reicht Ihnen eine Rechnungsvorlage und bittet um „einen QR-Code, mit dem man einfach bezahlen kann". Irgendwo im Briefing taucht dann auch noch ein QR-Code auf, der UTM-Parameter tragen und im monatlichen Scan-Report des Kunden erscheinen soll. Das sind zwei völlig unterschiedliche Aufgaben, und ein Großteil der Verwirrung in Agentur-Briefings entsteht dadurch, dass beide wie ein und dasselbe Quadrat behandelt werden.

Der Zahlungs-QR-Code ist so gut wie sicher ein EPC-QR-Code, in Deutschland besser bekannt als GiroCode. Es handelt sich um einen festen, bankdefinierten Standard zum Auslösen einer SEPA-Überweisung, nicht um einen trackbaren Marketing-Code, und er lässt sich nicht durch einen Ihrer dynamischen Codes ersetzen, ohne dass genau das verloren geht, was ihn funktionsfähig macht. Dieser Leitfaden erklärt, was ein EPC-QR-Code tatsächlich enthält, warum er sich nicht wie ein dynamischer QR-Code tracken lässt, wo beide wirklich auf demselben Dokument nebeneinander stehen können, und welches Betrugsmuster jede Agentur kennen sollte, die Kundenrechnungen bearbeitet.

Was ein EPC-QR-Code wirklich ist

EPC steht für European Payments Council, das Branchengremium, das das Regelwerk des einheitlichen Euro-Zahlungsverkehrsraums (SEPA) verwaltet. Im Februar 2013 veröffentlichte es ein Leitliniendokument, das einen standardisierten QR-Code-Payload zur Auslösung einer SEPA-Überweisung definiert, aufbauend auf einem Datenerfassungsformat, das der österreichische Zahlungsdienstleister STUZZA bereits 2012 den Banken vorgestellt hatte. Dieser Standard trägt offiziell die Bezeichnung EPC069-12.

Der Standard wurde unter verschiedenen regionalen Namen übernommen, was die Hauptquelle der Verwirrung ist. Deutschland nennt ihn GiroCode. Österreich nennt ihn nach wie vor Stuzza QR. Belgien und die Niederlande sprechen meist einfach von „EPC-QR-Code" oder „SEPA-QR-Code". In allen Fällen handelt es sich um denselben EPC069-12-Payload: Der Markenname unterscheidet sich, die Bytes im Code nicht. Finnland und Deutschland integrierten ihn 2015 in ihre Banking-Apps, die Niederlande folgten 2016, und heute wird er von mobilen Banking-Apps im gesamten Euroraum erkannt, darunter Apps von Sparkasse, ING, ABN AMRO, Rabobank, N26 und Bunq, unter anderem.

Es gibt zwei Versionen des Payloads. Version 001 verlangt neben der IBAN zusätzlich eine BIC (den SWIFT-Code der Bank). Version 002, seit 2018 aktuell, macht die BIC bei inländischen SEPA-Überweisungen optional und ist das, was jede neue Implementierung erzeugen sollte. Wenn die alte Rechnungssoftware eines Kunden noch Codes der Version 001 ausgibt, lohnt sich ein Hinweis: Manche Banking-Apps haben begonnen, die BIC-Prüfung bei innereuropäischen SEPA-Überweisungen fallen zu lassen, sodass das zusätzliche Feld nicht mehr nötig ist.

Erwähnenswert ist, dass die Schweiz auf dieser Liste fehlt. Die Schweizer QR-Rechnung sieht ähnlich aus und erfüllt für eine Überweisung in Schweizer Franken denselben Zweck, ist aber ein eigenständiger nationaler Standard, der von SIX verwaltet wird, kein EPC069-12-Payload. Ein GiroCode-Generator erzeugt keine gültige Schweizer QR-Rechnung, und umgekehrt genauso wenig.

Welche Daten tatsächlich im Code stecken

Ein EPC-QR-Code ist kein Link. Er enthält keine URL und kontaktiert beim Scannen keinen Server; jedes Feld, das die Banking-App benötigt, steht als Klartext direkt im QR-Payload, in einer vom Standard festgelegten festen Reihenfolge. Die elf Elemente sind:

• Service-Tag: die feste Zeichenfolge „BCD", die der lesenden App mitteilt, dass es sich um einen EPC-Payload handelt.
• Version: „001" oder „002".
• Zeichensatz: ein numerischer Code, fast immer 1 für UTF-8.
• Identifikation: die feste Zeichenfolge „SCT" (SEPA Credit Transfer).
• BIC: die Kennung der Empfängerbank. Bei Version 002 optional.
• Empfängername: bis zu 70 Zeichen.
• IBAN: die Kontonummer des Empfängers, das einzige Feld, das jede Implementierung als verpflichtend behandelt.
• Betrag: ausschließlich Euro, formatiert als EUR gefolgt von bis zu zwei Nachkommastellen. Optional; bleibt das Feld leer, kann der Zahler den Betrag selbst eingeben.
• Verwendungszweck-Code: eine optionale SEPA-Zweckkategorie, in den meisten Rechnungssystemen leer gelassen.
• Strukturierte Gläubiger-Referenz: eine ISO-11649-Referenz, die mit „RF" beginnt, gefolgt von zwei Prüfziffern und bis zu 21 weiteren alphanumerischen Zeichen, insgesamt maximal 25 Zeichen. Vor allem in Finnland und Belgien für den automatisierten Abgleich mit offenen Forderungen genutzt.
• Unstrukturierte Verwendungszweckangabe: Freitext, maximal 140 Zeichen, typischerweise die Rechnungsnummer. Wird überall dort statt der strukturierten Referenz genutzt, wo das ISO-11649-Format nicht der lokalen Konvention entspricht.

Der gesamte Payload hat UTF-8-kodiert eine feste Obergrenze von 331 Byte, und der Standard legt die Fehlerkorrekturstufe fest auf M, das heißt, der Code verkraftet etwa 15 Prozent Beschädigung oder Verdeckung, bevor er nicht mehr scannbar ist. Das ist eine bewusste Entscheidung auf Ebene der Spezifikation, kein Parameter, den ein Generator einstellen lässt. Wer unseren Beitrag Wie viele Daten passen in einen QR-Code kennt, findet hier dasselbe Prinzip im Kleinen: Ein kurzer, fester Payload mit fest verankerter Fehlerkorrekturstufe scannt zuverlässiger als ein langer, und der Standard ist so geschrieben, dass er diese Zuverlässigkeit garantiert, statt sie dem Generator zu überlassen.

Warum sich Scans von EPC-QR-Codes nicht tracken lassen

Das ist der Punkt, an dem die meisten Briefings stolpern. Ein trackbarer Marketing-QR-Code, wie ScanKit ihn erzeugt, kodiert eine kurze URL, die auf einen Weiterleitungsserver zeigt. Jeder Scan ist eine HTTP-Anfrage, die der Server sieht und protokolliert, bevor er den Browser des Telefons zum eigentlichen Ziel weiterleitet. Diese Anfrage ist es, die einen Scan-Zähler, einen Zeitstempel, einen Gerätetyp und einen Standort erzeugt.

Ein EPC-QR-Code stellt diese Anfrage nie. Der Payload ist die Zahlungsinformation selbst, die lokal von der Banking-App verarbeitet wird, sobald die Kamera sie einliest. Es gibt keinen Server im Ablauf, keine Weiterleitung, und nichts, was irgendeine Plattform, ScanKit eingeschlossen, protokollieren könnte. Die Frage, ob ein EPC-QR-Code „in Analytics auftaucht", ist im Grunde die Frage, ob ein Stück Papier nach Hause telefonieren kann; das kann es konstruktionsbedingt nicht, denn der ganze Sinn des Standards ist, dass eine Zahlungsanweisung nicht davon abhängen soll, ob der Server eines Drittanbieters gerade online ist.

Das bedeutet auch, dass sich ein EPC-QR-Code nach dem Druck nicht mehr bearbeiten lässt, anders als das Ziel eines dynamischen QR-Codes. Ändert sich der Rechnungsbetrag, stimmt die IBAN-Prüfsumme nicht mehr mit dem kodierten Wert überein; der Code muss jedes Mal, für jede Rechnung, neu erzeugt und neu gedruckt werden. In dieser Hinsicht verhält er sich genau wie ein statischer QR-Code: Was zum Zeitpunkt der Erzeugung galt, ist dauerhaft fixiert.

EPC-QR-Code vs. trackbarer QR-Code: Wann Sie welchen brauchen

Stellt man beide nebeneinander, ist die Entscheidung einfach, sobald man trennt, wofür jeder der beiden eigentlich gedacht ist.

• Nutzen Sie einen EPC-QR-Code, wenn es darum geht, Geld zu bewegen: eine Rechnung, eine Spendenanfrage, eine Mitgliedschaftsverlängerung, alles, wo die Banking-App des Zahlers eine IBAN-Überweisung vorausfüllen soll. Er funktioniert nur innerhalb des Euroraums und nur für eine Banküberweisung, nicht für eine Kartenzahlung.
• Nutzen Sie einen trackbaren QR-Code, wenn es um Messung oder ein variables Ziel geht: um Traffic auf eine Landingpage zu lenken, einen Bewertungslink, eine Speisekarte, ein Buchungsformular oder überall dort, wo Sie einen Scan-Zähler, eine Aufschlüsselung nach Quelle oder die Möglichkeit brauchen, ohne Neudruck auf ein neues Ziel umzuleiten.
• Nutzen Sie beide auf demselben Dokument, wenn eine Rechnung eine Option „per Überweisung bezahlen" braucht und ein Kunde gleichzeitig wissen möchte, wie viele Empfänger die Rechnung online geöffnet, sich zu einem Zahlungsportal durchgeklickt oder ein zugehöriges Angebot angesehen haben. Beide bedienen unterschiedliche Zeilen auf demselben PDF und konkurrieren nie um denselben Scan.
• Versuchen Sie nicht, einen Code beide Aufgaben erledigen zu lassen. Ein Code kann nicht gleichzeitig einen festen IBAN-Payload tragen und über einen Tracking-Server umleiten; der EPC-Standard hat kein Feld für eine Callback-URL, und eine URL in die Verwendungszweckzeile zu quetschen erzeugt lediglich Text, den eine Banking-App anzeigt, keinen Link, den sie öffnet.

Wenn ein Kunde nach „einem QR-Code fragt, der gleichzeitig Zahlung entgegennimmt und den Scan trackt", lautet die ehrliche Antwort, dass es unter dem aktuellen EPC-Standard keinen einzelnen Code gibt, der das kann. Die praktische Lösung sind zwei Codes: der EPC-Code für die Überweisung und ein kleiner trackbarer Code (oder derselbe, der bereits an anderer Stelle in der Kampagne verwendet wird), der stattdessen auf eine Online-Rechnung oder eine Zahlungsstatusseite verweist, auf der Sie das Engagement messen können.

Das Betrugsrisiko, das Agenturen bei Kundenrechnungen kennen sollten

Weil ein EPC-QR-Code die IBAN direkt trägt und die meisten Menschen Kontonummern vor dem Bestätigen einer Überweisung nicht mehr gegenlesen, ist er zu einem echten Betrugsziel geworden. Das Schweizer Bundesamt für Cybersicherheit (NCSC) hat ein Muster dokumentiert, bei dem Angreifer ein E-Mail-Konto kompromittieren, eine legitime Rechnung abfangen, die IBAN austauschen, den QR-Code passend neu erzeugen und das manipulierte PDF anschließend von der gekaperten Adresse aus erneut versenden. Die optische Gestaltung der Rechnung sieht identisch aus; nur die Kontonummer und der Payload des Codes haben sich geändert.

Eine physische Variante derselben Idee, einen betrügerischen QR-Aufkleber direkt über einen gedruckten Code zu kleben, ist dieselbe Technik, die bei Parkuhren und Ladesäulen für E-Autos zum Einsatz kommt, und sie funktioniert genauso gut bei einer per Post verschickten Rechnung oder einer an eine Tür geklebten Zahlungserinnerung. Unser Leitfaden zu QR-Code-Sicherheit für Agenturen behandelt die allgemeinen Schutzmaßnahmen für gedruckte Codes; speziell für EPC-Codes kommen praktisch noch hinzu:

1. Erzeugen Sie den EPC-QR-Code eines Kunden niemals aus einer weitergeleiteten E-Mail neu, ohne die IBAN telefonisch oder über einen Kanal außerhalb dieses E-Mail-Threads zu bestätigen.
2. Ermutigen Sie Kunden, nach dem Scannen den in der Banking-App angezeigten Empfängernamen zu prüfen, nicht nur den Betrag, denn ein abweichender Name ist häufig das erste sichtbare Anzeichen für eine ausgetauschte IBAN.
3. Wenn Sie wiederkehrende Rechnungen für einen Kunden verwalten, halten Sie IBAN und Erzeugungslogik in einem einzigen kontrollierten System, statt einzelnen Mitarbeitern zu erlauben, Codes ad hoc in unterschiedlichen Tools neu zu erzeugen.

Einen Code richtig erzeugen und testen

Jeder EPC069-12-Generator benötigt mindestens den Empfängernamen, die IBAN und die ausgewählte Version 002. Alles Weitere ist optional, aber ein paar Standardwerte lohnt es sich, bewusst zu setzen:

• Lassen Sie das Betragsfeld bei wiederkehrenden oder variablen Rechnungen leer, damit der Zahler die korrekte Summe selbst einträgt; fixieren Sie den Betrag nur bei einmaligen Anfragen mit festem Wert, etwa einem festen Mitgliedsbeitrag.
• Nutzen Sie die strukturierte Gläubiger-Referenz (ISO 11649), wenn die Buchhaltungssoftware des Kunden automatisch damit abgleichen kann; andernfalls ist das unstrukturierte Verwendungszweckfeld mit der Rechnungsnummer einfacher und funktioniert überall.
• Halten Sie sich an die eigenen Druckvorgaben des Standards: eine physische Mindestgröße von etwa 2 mal 2 Zentimetern, eine Druckauflösung von mindestens 300 DPI und eine Ruhezone von mindestens vier Modulen weißem Rand auf jeder Seite, dieselbe Randregel, die jeden QR-Code, getrackt oder nicht, zuverlässig scannbar hält.
• Bevor ein Druckauftrag rausgeht, scannen Sie den fertigen Code mit zwei oder drei verschiedenen Banking-Apps, nicht nur einer. Die Unterstützung optionaler Elemente wie BIC und strukturierter Referenzen variiert zwischen Banken noch leicht, und ein Code, der in einer App perfekt vorausfüllt, kann in einer anderen gelegentlich ein Feld leer lassen.

Für all das braucht es keine Marketing-QR-Plattform. Es braucht einen konformen EPC069-12-Generator (mehrere kostenlose gibt es bereits) und dieselbe Drucksorgfalt, die Sie bei jedem Code anwenden würden, der auf Papier landet.

Häufig gestellte Fragen

Was ist ein EPC-QR-Code?

Es ist ein QR-Code nach dem EPC069-12-Standard des European Payments Council, der die Daten zum Vorausfüllen einer SEPA-Überweisung, Empfängername, IBAN, Betrag und Referenz, direkt in den Code kodiert, sodass eine Banking-App ihn ohne Umweg über einen Server lesen kann.

Was ist ein GiroCode?

GiroCode ist der deutsche Name für denselben EPC069-12-Standard. Österreich nennt ihn Stuzza QR; Belgien und die Niederlande sprechen meist von EPC-QR-Code oder SEPA-QR-Code. Der zugrunde liegende Payload ist unabhängig vom regionalen Namen identisch.

Ist ein GiroCode dasselbe wie ein EPC-QR-Code?

Ja. GiroCode ist ein regionaler Markenname für den EPC069-12-Payload, kein eigener technischer Standard.

Welche Banken und Länder unterstützen das Scannen von EPC-QR-Codes?

Banking-Apps in Österreich, Belgien, Finnland, Deutschland und den Niederlanden waren früh dabei, wobei Finnland und Deutschland ab 2015 und die Niederlande ab 2016 einführten. Die meisten großen Banking-Apps im Euroraum, darunter Sparkasse, ING, ABN AMRO, Rabobank, N26 und Bunq, unterstützen heute Scan-to-Pay per EPC-QR-Code, auch wenn die Unterstützung optionaler Felder wie BIC von Bank zu Bank leicht variieren kann.

Kann man Scans eines EPC-QR-Codes tracken?

Nein. Der Payload wird lokal von der Banking-App verarbeitet; das Scannen löst nie eine HTTP-Anfrage an irgendeinen Server aus, sodass es für eine Weiterleitungsplattform oder ein Analytics-Tool nichts zu protokollieren gibt. Das ist eine strukturelle Eigenschaft des Standards, keine Einschränkung eines bestimmten Generators.

Wie viele Daten passen in einen EPC-QR-Code?

Der vollständige Payload ist UTF-8-kodiert auf 331 Byte begrenzt, verteilt auf elf feste Felder, darunter ein Empfängername mit maximal 70 Zeichen und eine Verwendungszweckangabe mit maximal 140 Zeichen.

Kann ich den Betrag auf einem EPC-QR-Code nach dem Druck ändern?

Nein. Jedes Feld, einschließlich Betrag und IBAN-Prüfsumme, wird bei der Erzeugung fest kodiert. Eine Änderung des Betrags bedeutet, einen neuen Code zu erzeugen und zu drucken; es gibt keine Möglichkeit, den Payload eines bereits gedruckten EPC-Codes nachträglich zu bearbeiten.

Ist ein EPC-QR-Code sicher vor Betrug?

Der Standard selbst ist nicht die Schwachstelle; das Risiko besteht darin, dass Betrüger die IBAN im Rechnungs-PDF austauschen, einen passenden Code neu erzeugen und die Rechnung anschließend erneut versenden, oft von einem kompromittierten E-Mail-Konto aus. Den nach dem Scannen angezeigten Empfängernamen zu prüfen und IBANs über einen Kanal außerhalb der ursprünglichen E-Mail zu verifizieren, sind die praktischen Schutzmaßnahmen.

Was ist der Unterschied zwischen einem EPC-QR-Code und einer Schweizer QR-Rechnung?

Sie sehen ähnlich aus und erfüllen denselben Zweck, das Vorausfüllen einer Überweisung, sind aber unterschiedliche Standards. Der EPC-QR-Code folgt EPC069-12 für SEPA-Überweisungen im Euroraum; die Schweizer QR-Rechnung ist ein eigenständiger nationaler Standard für Überweisungen in Schweizer Franken, verwaltet von SIX. Ein Generator, der für den einen gebaut wurde, erzeugt keinen gültigen Code für den anderen.

Welche Fehlerkorrekturstufe verwenden EPC-QR-Codes?

Stufe M, vom Standard fest vorgegeben, die etwa 15 Prozent Beschädigung oder Verdeckung verkraftet, bevor der Code unlesbar wird.

Können ein EPC-QR-Code und ein trackbarer QR-Code auf derselben Rechnung stehen?

Ja, und das ist oft die richtige Lösung: Der EPC-Code übernimmt die eigentliche Überweisung, während ein separater trackbarer Code auf eine Online-Rechnung, eine Zahlungsstatusseite oder ein zugehöriges Angebot verweisen kann, sodass Sie Scan-Daten erhalten, ohne den Zahlungs-Payload selbst anzufassen.

Die Kurzfassung

Ein EPC-QR-Code, in Deutschland GiroCode und in Österreich Stuzza QR genannt, ist ein fester EPC069-12-Payload, der eine SEPA-Überweisung direkt in einer Banking-App vorausfüllt. Er trägt keine URL, kontaktiert keinen Server und lässt sich deshalb, anders als ein dynamischer QR-Code, weder tracken noch nach dem Druck bearbeiten. Behandeln Sie ihn als Zahlungsinstrument, nicht als Marketingkanal: Verifizieren Sie die IBAN über einen zweiten Kanal, bevor Sie den Code eines Kunden neu erzeugen, lassen Sie das Betragsfeld bei wiederkehrenden Rechnungen leer, testen Sie den fertigen Code in mehr als einer Banking-App, und greifen Sie zu einem separaten trackbaren Code, wann immer das eigentliche Ziel Messung statt Zahlung ist.