Gravity-PDF Add-on
Das Add-on hängt an das PDF, das Ihr Formular ohnehin erzeugt, eine vollständige Schweizer QR-Rechnung an — Zahlteil und Empfangsschein, 210 × 105 mm an der unteren Schnittkante. Ihr Kunde scannt sie mit jeder Banking-App oder trennt sie ab und gibt sie am Schalter ab.
Auf den Millimeter
Empfangsschein 62 mm, Zahlteil 148 mm, die vorgeschriebenen 5 mm Rand, die Felder für Betrag und Zahlbar durch in ihren festgelegten Größen, der Bereich für die Annahmestelle, Schnittlinien mit Scherensymbol und der Hinweis, vor der Einzahlung abzutrennen. Die Maße unten sind keine Näherungen — sie wurden aus einem erzeugten PDF zurückgemessen.
| Element | Vorgeschrieben | Erzeugt |
|---|---|---|
| Gesamtblock | 210 × 105 mm am Fuß | 210 × 105 |
| Empfangsschein / Zahlteil | 62 / 148 mm | 62 / 148 |
| Swiss QR Code | exakt 46 × 46 mm | 46 × 46 |
| Freiraum um den Code | ≥ 5 mm | 17 / 5 / 5 / 13 |
| Modulgröße | ≥ 0,4 mm | 0,667 mm |
| Schweizerkreuz | 7 × 7 mm, zentriert | 7 × 7, zentriert |
| Eckmarken | 0,75 pt | 0,75 pt |
| Bereich Annahmestelle | ≥ 20 mm hoch | 20 mm |
Im Zahlteil gibt es bewusst keine eigene Überschrift. Abschnitt 3.1 der Guidelines schließt die Nutzung als Werbeträger aus, und ein freier Text im A6-Bereich würde die Rechnung normwidrig machen. Was Sie sagen wollen, steht oberhalb der oberen Schnittlinie — das ist Rechnungsfläche, und der Feed hat eine Einstellung dafür.
Version 2.4
Die Implementation Guidelines 2.4 gelten ab dem 14. November 2026. Drei ihrer Änderungen wiegen schwer genug, dass eine Umsetzung nach dem weit verbreiteten Stand 2.3 heute falsch ist — und jede einzelne kann eine Rechnung ungültig machen.
| Änderung in 2.4 | Was das für Sie bedeutet |
|---|---|
| QR-Referenz und QR-IBAN nur noch in CHF | Da eine QR-IBAN zur QR-Referenz verpflichtet, ist „QR-IBAN plus EUR“ unmöglich geworden. Früher war es erlaubt. Die Feed-Seite meldet das als Blocker, bevor Sie irgendetwas konfigurieren. |
| Die strukturierte Adresse ist Pflicht | Der kombinierte Adresstyp „K“ entfällt. PLZ, Ort und Land des Zahlungsempfängers sind Pflicht, nicht nur Empfehlung. |
| Rätoromanisch als fünfte Korrespondenzsprache | Fünf statt vier Einträge in der Sprachliste. |
Anhang A enthält zwei vollständig durchgerechnete Datensätze. Diese Umsetzung reproduziert beide Byte für Byte — einschließlich des Details, über das handgeschriebene Implementierungen stolpern: Die Versionszeile im Code bleibt 0200, nicht 0240. Abschnitt 7.1 verlangt von Lesern, diese Zeile zu prüfen; 0240 erzeugt also einen Code, der rundweg abgelehnt wird.
QR-Rechnungen in EUR werden spätestens ab November 2027 als SEPA-Überweisung abgewickelt, und die Guidelines warnen, dass die Adresse des Zahlenden und eine Mitteilung neben einer strukturierten Referenz dann nicht garantiert bei Ihnen ankommen. Das Add-on schreibt das bei einer EUR-Rechnung ins Log, statt zu schweigen.
Die Referenz
Welche Art Sie verwenden dürfen, entscheidet Ihr Konto — nicht Ihre Vorliebe. Das Add-on kann es für Sie aus der IBAN ableiten.
| Typ | Voraussetzung | Format |
|---|---|---|
| QRR — QR-Referenz | eine QR-IBAN, seit 2.4 zusätzlich CHF | 27 Ziffern, Modulo 10 rekursiv |
| SCOR — Creditor Reference | eine gewöhnliche IBAN; CHF oder EUR | RF + 2 Prüfziffern + bis zu 21 |
| NON — keine Referenz | eine gewöhnliche IBAN | die Zeile bleibt leer |
Tragen Sie Ihre Rechnungsnummer in ein Feld ein — mit Merge-Tags — und die 27-stellige Referenz wird zusammengesetzt und ihre Prüfziffer berechnet.
Zeigt dasselbe Feld auf eine bereits vorhandene Referenz, wird eine vollständige, gültige erkannt und unangetastet gelassen. Ohne das würde ein Merge-Tag auf eine gespeicherte Referenz stillschweigend Unsinn erzeugen — aus RF18… würde RF97RF18…. Es wird protokolliert, wenn es passiert.
Gemessen statt angenommen: Eine einzelne falsche Ziffer wird immer erkannt — 97.200 Mutationen, keine ist durchgerutscht. Ein Zahlendreher benachbarter Ziffern wird meist, aber nicht immer erkannt; rund 2 % rutschen durch. Die Lücke ist präzise statt zufällig — und sie ist dokumentiert.
Gebaut, um nicht zu brechen
Der Standard erlaubt eine bestimmte Teilmenge von Unicode, und WordPress setzt ungefragt Zeichen ein, die nicht dazugehören — aus einem getippten Apostroph wird stillschweigend ein typografischer. Diese werden in ihre einfachen Entsprechungen umgewandelt statt entfernt, damit „L’Atelier“ lesbar und zahlbar bleibt.
Beides ist zulässig. Der Zahlteil druckt dann ein farbloses Feld mit schwarzen Eckmarken in exakt den Maßen des Standards, zum Ausfüllen von Hand. Ein Spendenformular funktioniert damit ebenso gut wie eine Rechnung.
Der Zahlteil belegt genau die Fläche, in der eine Fußzeile sitzt — deshalb wird die laufende Fußzeile der Vorlage für diese eine Seite abgeschaltet, und nur für diese. Ihre Rechnungsseiten behalten ihre.
Deutsch, Französisch, Italienisch, Rätoromanisch und Englisch. Die Überschriften sind vorgeschriebener Wortlaut, keine Übersetzungen, und der Rechnungssteller wählt die Sprache — ein deutschsprachiges WordPress kann also einen italienischen Zahlteil drucken, und ein Formular kann sich vom nächsten unterscheiden.
Ein Schalter erzeugt die Variante, die die Guidelines für eine nicht zu zahlende Rechnung vorsehen: Betrag fest auf 0.00 und der vorgeschriebene Wortlaut in der gewählten Sprache — das stellt zugleich sicher, dass eine Umwandlung in eine eBill nicht zur Zahlung freigegeben werden kann.
Kein Composer-Schritt, kein bcmath, kein API-Key, kein externer Dienst, kein vendor-Verzeichnis, das mit einem anderen Plugin kollidiert. Payload, Prüfziffern und Layout stecken im Plugin — deshalb läuft es noch unter PHP 7.4. Der QR-Encoder kommt von Gravity PDF selbst.
Das Layout ist ein filterbares Array benannter Konstanten, die Payload-Klasse kommt ohne WordPress aus, sodass sich die Regeln des Standards isoliert testen lassen, und die QR-Referenz liegt als portables Zwei-Datei-Paket bei, das Sie in jedes andere Gravity-Forms-Plugin kopieren dürfen.
Voraussetzungen
| WordPress mit Gravity Forms | 2.5 oder neuer |
| Gravity PDF | 6 oder neuer |
| PHP | 7.4 oder neuer |
| Währung in Gravity Forms | CHF oder EUR |
| IBAN | Schweiz oder Liechtenstein |
Sieben Voraussetzungen werden an einer Stelle geprüft und an zwei Stellen gezeigt: als Liste auf der Feed-Seite, wo jemand handeln kann, und als Log-Zeile zur Renderzeit, wo stilles Überspringen die einzig vernünftige Reaktion ist. Beide können sich nie darin widersprechen, was fehlt.
Einrichtung
Version 2.4 hat die strukturierte Empfängeradresse zur Pflicht gemacht: Straße, PLZ, Ort und Land, nicht nur ein Name. Sie stehen zusammen mit der IBAN auf der gemeinsamen Seite (e)invoice Settings, und jedes Add-on der Familie liest sie von dort.
Ein Feed entscheidet, welches PDF den Zahlteil trägt. Die Überschriften sind vorgeschriebener Wortlaut in Deutsch, Französisch, Italienisch, Rätoromanisch und Englisch — pro Feed gewählt, eine deutsche Website kann also einen italienischen Zahlteil drucken.
Eine QR-IBAN verlangt eine QR-Referenz und CHF; eine gewöhnliche IBAN nimmt eine Creditor Reference oder gar keine. Belassen Sie es bei Aus der IBAN ableiten, und das Add-on wählt die richtige — und sagt Ihnen auf der Feed-Seite, wenn Ihre Kombination nicht funktionieren kann.
Empfangsschein und Zahlteil werden an der unteren Schnittkante der letzten Seite gedruckt, mit Schnittlinien und dem Hinweis, vor der Einzahlung abzutrennen.
Die gemeinsame Seite (e)invoice Settings — seit Version 2.4 ist die Adresse des Rechnungsstellers ein Pflichtbestandteil.
Ein Feed pro Dokument, das den Zahlteil tragen soll.
Feed-Einstellungen: welches PDF, welche der fünf Sprachen und welcher Referenztyp.
Die erzeugte QR-Rechnung — Empfangsschein 62 mm, Zahlteil 148 mm, Schnittlinien mit Scherensymbol.
Nennen Sie uns die Institutsziffern Ihrer IBAN und die Währung, in der Sie fakturieren — die Antwort dauert eine Minute, einschließlich der Frage, ob Version 2.4 Ihre geplante Kombination ausschließt.