GiroCode auf der Rechnung: Aufbau, Grenzen und der Weg über JTL-Wawi

Ein GiroCode ist ein QR-Code auf der Rechnung, der alle Daten einer SEPA-Überweisung trägt: Name, IBAN, Betrag und Verwendungszweck. Technisch heißt er EPC-QR-Code und folgt der Spezifikation EPC069-12 des European Payments Council. Der Kunde scannt ihn mit seiner Banking-App, statt die IBAN abzutippen. JTL-Wawi kennt dafür keine eigene Funktion — der Weg führt über das Barcode-Objekt der Druckvorlage.

Prüfstand am 6. September 2026: Die Spezifikation wurde für diesen Beitrag als Originaldokument beim European Payments Council geladen und vollständig gelesen (Fassung EPC069-12 v3.1 vom 19. März 2024). Die Angaben zum Formulareditor stammen aus dem JTL-Guide und dem Handbuch von combit, die Sicherheitshinweise vom BSI. Softwareoberflächen ändern sich — prüfen Sie Ihre eigene Version, bevor Sie eine Vorlage umbauen.

1. GiroCode, EPC-QR-Code, SEPA-QR: was der Code wirklich ist

Drei Namen, ein Datensatz. Wer nach dem Standard sucht, findet unter GiroCode vor allem Sparkassen-Seiten, unter EPC-QR-Code die technische Beschreibung und unter SEPA-QR eine Mischung aus beidem. Die Aufklärung ist kurz: Das Wort GiroCode kommt in der Spezifikation kein einziges Mal vor. Es ist der Produktname, unter dem die deutsche Kreditwirtschaft den Code vermarktet; die Domain girocode.de leitet auf die Seite der S-Public Services aus der Sparkassen-Finanzgruppe weiter.

Der Standard dahinter heißt EPC069-12 und stammt vom European Payments Council, dem Gremium hinter den SEPA-Regelwerken. Die aktuelle Fassung trägt die Version 3.1 und das Datum 19. März 2024 (Quelle: EPC069-12 v3.1). Dasselbe Gremium schreibt auch das Regelwerk für die Lastschrift, das wir im Beitrag zur SEPA-Lastschrift im Onlineshop auseinandergenommen haben. Der Unterschied in einem Satz: Bei der Lastschrift holen Sie das Geld, beim QR-Code erleichtern Sie dem Kunden das Überweisen.

Wichtig für die Erwartungshaltung ist die Rechtsnatur. Das Dokument bezeichnet sich selbst als rein informativ und die Umsetzung als optional für die Zahlungsdienstleister. Es gibt also keine Pflicht — weder für Sie, den Code zu drucken, noch für die Bank Ihres Kunden, ihn zu lesen. Wie viele Institute mitmachen, veröffentlicht niemand belastbar; wir geben deshalb bewusst keine Liste und keine Quote wieder.

Eine zweite Abgrenzung nennt die Spezifikation selbst. Diese Leitlinie gilt für Fälle, in denen die Zahlungsdaten dem Zahler gleichzeitig im Klartext vorliegen, also typischerweise auf einer Rechnung. Für Codes am Point of Interaction — am Kassenterminal oder in der Warenkorbseite eines Shops — verweist der EPC auf ein eigenes Dokument. Wer den Code also an die Ladentheke hängen will, arbeitet nicht mehr im Anwendungsbereich dieser Leitlinie.

2. Die Anatomie: elf Zeilen, 331 Byte

Ein EPC-QR-Code enthält keinen Link und keine verschlüsselte Nutzlast, sondern schlichten Text: bis zu elf Felder in fester Reihenfolge, getrennt durch Zeilenumbrüche. Die Reihenfolge ist die Bedeutung — es gibt keine Feldnamen im Datensatz. Wer eine Zeile verschiebt, schreibt den Betrag in den Verwendungszweck.

Dazu kommen drei technische Vorgaben aus demselben Abschnitt: Der Code arbeitet mit Fehlerkorrektur-Level M, bei dem sich 15 Prozent der Codewörter wiederherstellen lassen. Die maximale QR-Version ist 13, was einer Kantenlänge von 69 Modulen entspricht. Und die gesamte Nutzlast ist auf 331 Byte begrenzt.

Ein durchgerechnetes Beispiel

So sieht der Datensatz für eine Rechnung über 149,90 Euro aus. Die IBAN stammt aus dem Beispiel der Spezifikation selbst, ist also nachweislich keine echte Bankverbindung:

1. BCD — die Kennung, immer gleich
2. 002 — Version 2, damit der BIC entfallen darf
3. 1 — Zeichensatz UTF-8
4. SCT — es geht um eine Überweisung
5. (leere Zeile) — kein BIC, weil beide Konten im Europäischen Wirtschaftsraum liegen
6. Muster Handel GmbH — der Kontoinhaber
7. DE71110220330123456789 — die IBAN
8. EUR149.90 — Währung und Betrag mit Punkt
9. (leere Zeile) — kein Verwendungsschlüssel
10. (leere Zeile) — keine strukturierte Referenz
11. Rechnung RE-2026-04711 — der Verwendungszweck im Klartext

Nachgerechnet nach den Regeln der Spezifikation: 81 Zeichen Inhalt plus zehn Zeilenumbrüche ergeben 91 Zeichen. Weil kein Umlaut vorkommt, sind das zugleich 91 Byte — rund ein Viertel des erlaubten Budgets. Ein Betrieb mit langem Firmennamen und ausführlichem Verwendungszweck kommt der Grenze näher, sprengt sie im Rechnungsalltag aber selten.

3. Vier Regeln, an denen selbstgebaute Codes scheitern

Die Fehler, die uns in Projekten begegnen, wiederholen sich. Alle vier stehen in der Spezifikation, aber keiner davon in den Ratgebern, die bei der Suche nach dem Begriff oben stehen.

1. Zeichen sind nicht Byte. Die Grenze von 331 gilt für Byte, nicht für Zeichen. In UTF-8 belegt jeder Umlaut zwei Byte. Die Spezifikation führt das an ihrem eigenen Beispiel vor: Der Datensatz hat 95 Zeichen, aber 96 Byte — allein wegen eines einzigen ä im Namen. Wer knapp kalkuliert und den Zeichensatz wechselt, ändert damit die Größe des Codes.
2. Leere Felder in der Mitte bleiben stehen. Ein nicht befülltes Feld wird nicht weggelassen, sondern als leere Zeile mitgeschrieben — sonst rutschen alle folgenden Felder eine Position nach oben. Nur nach dem letzten befüllten Feld folgt kein Trennzeichen mehr. Genau daran scheitern selbstgebaute Codes am häufigsten: Sie werden gelesen, füllen aber die falschen Formularfelder.
3. Verwendungszweck: entweder oder. Zeile 10a nimmt eine strukturierte Referenz mit 35 Zeichen, Zeile 10b den freien Text mit 140 Zeichen. Die Spezifikation erlaubt ausdrücklich nur eines von beiden. Wer beide füllt, verlässt den Standard und muss damit rechnen, dass eine App den Code ablehnt.
4. Der Betrag folgt der englischen Schreibweise. Das Feld beginnt mit EUR, danach folgt der Betrag mit einem Punkt als Dezimaltrennzeichen. Zwei Nachkommastellen sind üblich, aber nicht vorgeschrieben — das Beispiel der Spezifikation nennt EUR12.3. Ein deutsches Komma macht den Datensatz ungültig.

Eine fünfte Stolperstelle ist keine Regel, sondern eine Entscheidung: Sie können den Betrag auch weglassen. Bei Teilzahlungen, offenen Rechnungen mit Skontoabzug oder Spendenaufrufen ist genau das sinnvoll — der Kunde trägt den Betrag dann selbst ein, alles andere steht bereits im Formular.

Ob ein GiroCode einen festen Betrag tragen soll, hängt auch an Ihren Zahlungsbedingungen. Gewähren Sie Skonto, zahlt der Kunde in der Frist weniger als den Rechnungsbetrag, den ein fester Code vorgibt. In JTL-Wawi hängt der Skonto an der Zahlungsart oder am einzelnen Auftrag. Wie Sie Skontosatz, Frist und Formulierung festlegen und was die Software beim Zahlungseingang daraus macht, zeigt der Beitrag Skonto berechnen, formulieren und in JTL-Wawi abbilden.

4. Realitätscheck JTL-Wawi: keine Funktion — und trotzdem ein Weg

Jetzt der unbequeme Teil. Wer in der Dokumentation von JTL nach einer GiroCode-Funktion sucht, findet nichts. Wir haben das nicht überflogen, sondern gemessen.

Befund vom 6. September 2026: Die Volltextsuche des JTL-Guide liefert für GiroCode, EPC QR und Zahlungs-QR jeweils null Treffer. Die Suchen nach QR-Code Rechnung, SEPA QR und Barcode Druckvorlage führen ausschließlich zu Shipping 2.0, Kassenbons, WMS und DATEV-Export. Zur Gegenprobe: Der Begriff combit liefert drei Treffer, obwohl er in keiner der drei Überschriften vorkommt — die Suche durchsucht also den Fließtext. Der Null-Treffer ist damit ein echter Befund, kein Suchfehler.

Trotzdem ist die Sache nicht erledigt, denn der Formulareditor von JTL-Wawi ist kein Eigenbau. Er ist combit List und Label; der JTL-Guide verweist für die Arbeit damit ausdrücklich auf das Handbuch des Herstellers. Und dieses Handbuch führt in der Übersicht der 2D-Codes einen Typ auf, der genau das kann: EPC (GiroCode), mit dem knappen Zusatz „Laut Spezifikation der European Payments Council. Beachten Sie den Optionsdialog." (Quelle: combit Designer-Handbuch).

Damit verschiebt sich die Frage. Sie lautet nicht mehr „Kann JTL-Wawi das?", sondern „Steht dieser Barcodetyp in meiner Installation zur Auswahl?". Welche Designer-Generation in welcher Wawi-Version steckt, gibt weder JTL noch combit an — deshalb ist der erste Blick in die Typenliste ein Prüfschritt und keine Formsache.

Acht Schritte von der Vorlage zum Code

1. Prüfen Sie zuerst, ob Sie Druckvorlagen der Ausgabe 2.0 verwenden. Sie erkennen sie an den englischen Variablennamen; Vorlagen der alten Ausgabe tragen in JTL-Wawi den Zusatz „(veraltet)". Auf einer veralteten Vorlage lohnt der Aufwand nicht.
2. Vervollständigen Sie Ihre Firmenstammdaten unter Admin > Firmen-/E-Mail-Einstellungen in der Registerkarte „Firmendaten". Aus diesen Feldern zieht die Vorlage später Name und Bankverbindung.
3. Öffnen Sie die Rechnungsvorlage im Formulareditor. Dieser Editor ist kein JTL-Eigenbau, sondern combit List und Label — der JTL-Guide verweist für Details ausdrücklich auf das Handbuch von combit.
4. Setzen Sie über „Einfügen > Barcode" ein Barcode-Objekt auf die Vorlage und ziehen Sie es auf die gewünschte Größe auf. Der Inhalts-Dialog öffnet sich anschließend von selbst.
5. Sehen Sie in der Typenliste nach, ob der Barcodetyp „EPC (GiroCode)" angeboten wird. Fehlt er, ist die eingebaute Designer-Generation zu alt — dann bleibt nur ein externer Generator oder ein Zusatzprogramm.
6. Wählen Sie als Inhaltsart „Formel" und setzen Sie den Datensatz Zeile für Zeile zusammen: feste Texte für die Kennungen, Variablen aus dem Zweig „Variablen > JTL > Wawi" für Firma und Beleg, dazwischen jeweils ein Zeilenumbruch.
7. Wandeln Sie das Ergebnis mit der Funktion Barcode() in den Datentyp „Barcode" um und sehen Sie sich den Optionsdialog an. Genau darauf weist combit beim Typ EPC ausdrücklich hin.
8. Testen Sie mit einer echten Rechnung und mindestens zwei verschiedenen Banking-Apps. Vergleichen Sie das ausgefüllte Formular Zeichen für Zeichen mit dem Klartext auf dem Beleg.

Zwei Hinweise aus der Praxis. Erstens werden die Variablen im Formulareditor in der Regel englisch angezeigt; deutsche Bezeichnungen sind laut JTL-Guide ein Anzeichen für eine veraltete Vorlage. Zweitens gibt es den Ordner mit den Firmendaten und den Ordner mit den Kundendaten nebeneinander, und beide enthalten gleichlautende Felder wie die Postleitzahl. Für den QR-Code brauchen Sie durchgehend die eigene Seite — eine Verwechslung fällt im Layout nicht auf, im Zahlungsverkehr sehr wohl.

Sichern Sie die Vorlage, bevor Sie das erste Objekt einfügen. Eine Funktion zum Duplizieren dokumentiert JTL nicht; der belegte Weg führt über die Vorlagenverwaltung und den Export als vlg-Datei. Vom Menü Datei und Speichern als im Editor rät JTL ausdrücklich ab, weil dabei die Verknüpfungen zu JTL-Wawi verloren gehen. Welchen Editor Ihr Ausgabeweg überhaupt öffnet, ordnet der Beitrag zu Druckvorlagen in JTL-Wawi.

Wenn Sie an dieser Stelle merken, dass Ihre Vorlagen ohnehin überarbeitungsbedürftig sind, lohnt es sich, den Umbau zu bündeln. Wir tun das in der Regel zusammen mit dem Blick auf den Zahlungsabgleich und die Übergabe an die Buchhaltung — beides Themen unserer Arbeit an JTL-Wawi.

5. Warum der QR-Code keine E-Rechnung ist

Diese Frage kommt in jedem zweiten Projekt, und die Antwort ist eindeutig. § 14 Abs. 1 UStG definiert:

„Eine elektronische Rechnung ist eine Rechnung, die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht."

Ein QR-Code auf einem Beleg erfüllt das nicht. Er richtet sich an die Kamera des Zahlers, nicht an die Buchhaltungssoftware des Empfängers, und er transportiert nur Zahlungsdaten, keine Rechnungsdaten. Er ersetzt deshalb weder ZUGFeRD noch XRechnung. Welche Formate wann verpflichtend sind, haben wir im Beitrag zur E-Rechnungspflicht mit ZUGFeRD und XRechnung aufgeschrieben.

Aus dieser Definition folgt eine praktische Konsequenz, die selten jemand ausspricht. Der JTL-Guide beschreibt die beiden Formate so: „Die XRechnung ist eine reine XML-Datei", während das ZUGFeRD-Format „eine PDF-Datei, kombiniert mit einer XML-Datei im Anhang" ist. Daraus ergibt sich:

• Reine XRechnung: Es gibt keine Sichtebene und damit keine Fläche, auf der ein QR-Code stehen könnte. Der Code ist hier strukturell unmöglich, nicht bloß unüblich.
• ZUGFeRD: Der Code lässt sich auf das PDF drucken, weil das PDF weiterhin aus Ihrer Druckvorlage kommt. Er ist damit reine Sichtebene — der Guide sagt dazu unmissverständlich: „Für die Buchhaltung ist jedoch der Inhalt der XML-Datei relevant und nicht das, was in der PDF-Datei dargestellt ist."
• Papier und einfaches PDF: Hier entfaltet der Code seinen ganzen Nutzen, weil der Empfänger die Zahlung tatsächlich von Hand auslöst.

Die nüchterne Zusammenfassung: Je weiter Ihre Kunden bei der E-Rechnung sind, desto weniger bringt ein QR-Code. Er ist ein Werkzeug für den manuellen Zahlungsweg — und der verschwindet im B2B-Bereich langsam, im Geschäft mit Privatkunden und kleinen Betrieben aber noch lange nicht.

6. Empfängerprüfung: wenn ein richtiger Code eine Warnung auslöst

Dieser Abschnitt ist neu und in keinem der Ratgeber zu finden, die zu diesem Thema oben stehen. Seit dem 9. Oktober 2025 gleicht die Bank des Zahlers vor jeder Freigabe ab, ob der eingegebene Empfängername zur angegebenen IBAN passt. Passt beides nicht zusammen, erscheint eine Warnung. Die Details dazu — Fristen, Ergebnisse, Haftung und das Opt-out für Sammelaufträge — stehen in unserem Beitrag zur Echtzeitüberweisung und Empfängerprüfung.

Der Punkt für diesen Beitrag ist die Überschneidung. Der EPC-QR-Code befüllt in Zeile 6 den Namen und in Zeile 7 die IBAN — exakt die beiden Felder, die verglichen werden. Vorher tippte der Kunde den Namen selbst ein und lag dabei zufällig richtig oder falsch. Heute übernimmt er wortwörtlich das, was Sie in den Code geschrieben haben. Ihr Datensatz entscheidet damit direkt darüber, ob Ihr Kunde eine grüne Bestätigung oder eine rote Warnung sieht.

Die typischen Auslöser sind harmlos und wirken trotzdem: Der Code trägt die eingeführte Marke, das Konto läuft auf die vollständige Firmierung mit Rechtsform. Oder der Code trägt einen Zusatz wie „Onlineshop", den die Bank nicht kennt. Oder die Vorlage nutzt versehentlich das Namensfeld aus den Adressdaten statt aus den Bankdaten. Alle drei Fälle erzeugen genau die Warnung, die Sie mit dem Code eigentlich vermeiden wollten.

Die Gegenmaßnahme kostet fünf Minuten: Schreiben Sie in Zeile 6 den Namen, unter dem Ihre Bank das Konto führt — nicht Ihren Markennamen und nicht die Bezeichnung des Shops. Wenn beides auseinanderläuft, klären Sie mit Ihrem Institut, ob eine abweichende Bezeichnung hinterlegt werden kann. Und prüfen Sie die Zeile im Testdruck nicht nur auf Tippfehler, sondern auf Übereinstimmung mit dem Kontoauszug.

7. Quishing: was Sie Ihren Kunden schuldig sind

Wer QR-Codes verschickt, wird zum Teil eines Problems, das Behörden inzwischen unter eigenem Namen führen. Das BSI beschreibt in seiner Meldung vom 1. April 2026, wie Angreifer schädliche Adressen in QR-Codes einbetten und mit gut formulierten Nachrichten kombinieren, „die typische Warnsignale eliminieren". Gefälschte Codes tauchen dabei laut BSI „in vermeintlichen E-Mails von Banken auf oder auch an Parkautomaten".

Zahlen dazu geben wir bewusst nicht wieder. Die Werte, die in Sicherheitsblogs zu Quishing kursieren, stehen nicht in der Behördenmeldung selbst, und wir übernehmen sie deshalb nicht. Die Handlungsempfehlung des BSI ist ohnehin eindeutig genug: QR-Codes hinterfragen, Adressen prüfen und wenn möglich manuell eingeben.

Für Ihre Belege heißt das dreierlei. Drucken Sie IBAN, Betrag und Verwendungszweck immer zusätzlich im Klartext. Erklären Sie in einer Zeile neben dem Code, was er tut und wofür er steht. Und verzichten Sie darauf, den Code in Zahlungserinnerungen mit Drucktext zu kombinieren — die Mischung aus Dringlichkeit und QR-Code ist genau das Muster, vor dem Ihre Kunden gewarnt werden. Wie ein sauberer Mahnlauf ohne solche Signale aussieht, beschreibt unser Beitrag zum automatisierten Mahnwesen.

8. Lohnt sich der Code für Ihren Betrieb?

Hier wird es unbequem, weil belastbare Zahlen fehlen. Der Markeninhaber des GiroCode nennt als Vorteile „weniger Zahlendreher, weniger Mahnungen, weniger Aufwand" — qualitativ, ohne einen einzigen Messwert. Der European Payments Council quantifiziert nichts. Wir geben deshalb keine Prozentwerte zum Zahlungseingang wieder, auch wenn solche Zahlen im Netz kursieren. Was bleibt, ist eine Einschätzung anhand Ihrer Zahlungsarten.

Der Code zahlt sich aus, wenn:

• ein nennenswerter Teil Ihrer Kunden per Überweisung zahlt, also auf Rechnung oder per Vorkasse;
• Sie an Privatkunden, Vereine oder kleine Betriebe fakturieren, die Rechnungen mit dem Smartphone bearbeiten;
• Ihre Verwendungszwecke lang oder fehleranfällig sind und der Zahlungsabgleich in der Warenwirtschaft daran hängt;
• Sie ohnehin Papier oder einfache PDF-Rechnungen versenden.

Der Aufwand lohnt kaum, wenn:

• Sie überwiegend per Lastschrift einziehen oder Zahlungsdienstleister nutzen — dann löst der Kunde gar keine Überweisung aus;
• Ihre Kunden reine XRechnungen verlangen, für die es keine Sichtebene gibt;
• Ihre Vorlagen noch aus der alten Ausgabe stammen und zuerst grundlegend erneuert werden müssten;
• Ihr Kontoinhabername und Ihre Außendarstellung auseinanderlaufen und Sie das nicht bereinigen wollen.

Ein Nebeneffekt ist die Rüstzeit. Ist der Code einmal in der Vorlage, kostet er pro Rechnung nichts mehr. Der Aufwand steckt vollständig im einmaligen Aufbau der Formel und im Testen. Und weil der gleiche Weg über das Barcode-Objekt auch für andere Belegarten funktioniert, tragen Sie den Aufwand nur einmal — für Rechnung, Mahnung und Zahlungserinnerung gleichermaßen. Wie sich der Zahlungsverkehr darüber hinaus verändert, ordnet unser Beitrag zum digitalen Euro für Händler ein.

9. Fazit: ein kleines Feld mit klaren Regeln

Der GiroCode ist kein Zahlverfahren und keine Innovation, sondern eine Erfassungshilfe mit einer sehr genauen Spezifikation. Wer diese Spezifikation liest, baut den Code in einer Stunde richtig. Wer sie überspringt, produziert Codes, die zwar gelesen werden, aber die falschen Formularfelder füllen — und merkt das erst, wenn Zahlungen ohne brauchbaren Verwendungszweck eingehen.

Für JTL-Wawi lautet die ehrliche Antwort: Es gibt keine fertige Funktion, aber einen belegbaren Weg über das Barcode-Objekt des Formulareditors. Ob dieser Weg in Ihrer Installation offensteht, entscheidet ein Blick in die Typenliste unter „Einfügen > Barcode". Das ist der erste Schritt, nicht der letzte.

Und der wichtigste Satz zum Schluss: Der Code ersetzt nichts. Er ersetzt nicht die E-Rechnung, nicht die Klartextangaben auf dem Beleg und nicht die Sorgfalt beim Empfängernamen. Er nimmt Ihrem Kunden genau eine Arbeit ab — das Abtippen. Das ist wenig und trotzdem der Unterschied zwischen einer Rechnung, die am Abend bezahlt wird, und einer, die auf dem Stapel liegen bleibt.

Hinweis: Dieser Artikel ist allgemeine Information und ersetzt keine Rechts- oder Steuerberatung. Die Angaben zur Spezifikation geben die Fassung EPC069-12 v3.1 vom 19. März 2024 wieder, abgerufen am 6. September 2026; die Angaben zu JTL-Wawi und zum Formulareditor stammen vom selben Tag. Ob ein QR-Code in Ihrem Fall die Anforderungen an eine ordnungsgemäße Rechnung berührt, hängt vom Einzelfall ab. Ziehen Sie dafür die verlinkten Originalquellen und Ihre steuerliche Beratung heran.

10. Häufige Fragen zum GiroCode

Was ist ein GiroCode?

Ein GiroCode ist ein QR-Code auf einer Rechnung, der die Daten einer SEPA-Überweisung enthält: Name des Empfängers, IBAN, optional Betrag und Verwendungszweck. Der Zahler scannt ihn mit seiner Banking-App, die daraufhin das Überweisungsformular vorausfüllt. Technisch heißt er EPC-QR-Code; GiroCode ist der deutsche Markenname der Sparkassen-Finanzgruppe.

Wie erstelle ich einen GiroCode für meine Rechnungen?

Für einzelne Belege genügt ein Online-Generator. Wer regelmäßig Rechnungen schreibt, erzeugt den Code besser aus dem eigenen System heraus: Die Software setzt den Datensatz aus Firmenstammdaten und Belegdaten zusammen und druckt ihn in die Vorlage. Nur so bleiben Betrag und Verwendungszweck automatisch richtig.

Kann JTL-Wawi einen GiroCode erzeugen?

Eine eigene GiroCode-Funktion gibt es nicht; im JTL-Guide finden sich dazu keine Treffer. Möglich ist der Weg über den Formulareditor, der auf combit List und Label beruht: Sie setzen ein Barcode-Objekt in die Druckvorlage, wählen den Barcodetyp EPC (GiroCode) und bauen den Inhalt als Formel zusammen.

Welche Banken und Apps unterstützen den GiroCode?

Viele, aber längst nicht alle. Der European Payments Council bezeichnet seine Leitlinie ausdrücklich als informativ und die Umsetzung als optional für Zahlungsdienstleister. Eine belastbare Gesamtliste veröffentlicht niemand. Drucken Sie die Zahlungsdaten deshalb immer zusätzlich im Klartext auf die Rechnung. Dann kann auch jemand ohne passende App bezahlen.

Welche Daten stehen in einem EPC-QR-Code?

Bis zu elf Felder in fester Reihenfolge: Kennung BCD, Versionsnummer, Zeichensatz, Kennung SCT, BIC, Name und IBAN des Empfängers, Betrag, Verwendungsschlüssel sowie Verwendungszweck strukturiert oder unstrukturiert und eine Zusatzinformation. Pflicht sind nur Kennungen, Name und IBAN. Alles zusammen darf 331 Byte nicht überschreiten.

Ersetzt ein GiroCode die E-Rechnung?

Nein. Nach § 14 Abs. 1 UStG ist eine elektronische Rechnung ein strukturiertes Format, das eine elektronische Verarbeitung ermöglicht. Ein QR-Code ist dagegen eine optische Erfassungshilfe für den Zahler. Er ersetzt weder ZUGFeRD noch XRechnung und darf auch nicht als Ersatz kommuniziert werden.

Ist ein GiroCode auf der Rechnung Pflicht?

Nein. Weder das Umsatzsteuerrecht noch das SEPA-Regelwerk verlangen ihn. Der European Payments Council bezeichnet seine Leitlinie selbst als rein informativ. Der Code ist ein freiwilliger Service für Ihre Kunden, keine Pflichtangabe. Die gesetzlichen Rechnungsangaben müssen unabhängig davon vollständig im Klartext auf dem Beleg stehen.

Warum zeigt die Banking-App eine Warnung, obwohl der Code stimmt?

Weil die Bank des Zahlers seit dem 9. Oktober 2025 abgleicht, ob der Empfängername zur IBAN passt. Der QR-Code füllt genau diese beiden Felder vor. Steht dort Ihr Markenname, das Konto läuft aber auf die vollständige Firmierung, meldet die App eine Abweichung.

Wie sicher ist das Bezahlen per QR-Code?

Der Datensatz selbst ist unverschlüsselter, lesbarer Text ohne Signatur. Aufgeklebte oder ausgetauschte Codes sind deshalb ein reales Betrugsmuster, das Behörden als Quishing führen. Das BSI rät, QR-Codes zu hinterfragen und Daten wenn möglich manuell einzugeben. Der Klartext neben dem Code ist Ihre wichtigste Gegenmaßnahme.

11. Quellen & offizielle Informationen

Alle wurden am 6. September 2026 abgerufen und im Volltext gegengelesen; die zitierten Formulierungen stammen wörtlich daraus. Spezifikationen und Herstellerangaben ändern sich — bitte prüfen Sie den Stand vor einer Entscheidung erneut. Externe Quellen öffnen in einem neuen Tab.

• European Payments Council: EPC069-12, Version 3.1 (PDF) — Die Primärquelle. Enthält die vollständige Feldliste mit Pflichtangaben und Maximallängen, die Grenze von 331 Byte, die acht Zeichensätze, die Betragsgrenzen und beide Beispieldatensätze.
• European Payments Council: Dokumentseite der QR-Code-Leitlinie — Die dauerhafte Übersichtsseite des Dokuments. Von hier aus finden Sie künftige Fassungen, wenn sich die Versionsnummer ändert.
• combit Designer-Handbuch: Übersicht der allgemeinen 2D-Codes — Belegt den Barcodetyp „EPC (GiroCode)" im Formulareditor mit dem Zusatz „Laut Spezifikation der European Payments Council. Beachten Sie den Optionsdialog."
• combit Designer-Handbuch: Barcode einfügen — Der Bedienweg über „Einfügen > Barcode", die drei Inhaltsarten Text, Formel und Variable sowie die Funktion Barcode() im Formel-Assistenten.
• JTL-Guide: Allgemeines zum Formulareditor — Belegt, dass der Formulareditor von JTL-Wawi auf combit List und Label beruht, und verweist für Details auf das Handbuch des Herstellers.
• JTL-Guide: Aufbau des Formulareditors — Der Variablenbaum mit den Ordnern für Firma und Kunde, der Hinweis auf englische Variablennamen und die Kombination von Variablen und festem Text über Formeln.
• JTL-Guide: XRechnungen ausstellen — Belegt wörtlich, dass die XRechnung eine reine XML-Datei ist und dass für die Buchhaltung bei ZUGFeRD der Inhalt der XML-Datei zählt, nicht die Darstellung im PDF.
• JTL-Guide: FAQ zu E-Rechnungen in JTL-Wawi — Der Weg zu den Firmendaten über Admin > Firmen-/E-Mail-Einstellungen und die Unterscheidung zwischen Vorlagen der Ausgabe 2.0 und den als veraltet gekennzeichneten Vorlagen.
• § 14 UStG — Ausstellung von Rechnungen — Absatz 1 mit der Definition der elektronischen Rechnung als strukturiertes elektronisches Format — der Grund, warum ein QR-Code keine E-Rechnung ist.
• BSI: KI-gestützte QR-Code-Betrügereien — Behördliche Einordnung des Quishing mit Datum 1. April 2026, inklusive der Empfehlung, QR-Codes zu hinterfragen und Adressen wenn möglich manuell einzugeben.
• S-Public Services: GiroCode — Die Seite des Markeninhabers aus der Sparkassen-Finanzgruppe, erreichbar auch über girocode.de. Nutzenaussagen dort ausschließlich qualitativ, ohne Zahlen — eine Anbieterquelle, keine Behörde.