Gravity-PDF Add-on
Das Add-on hängt an das PDF, das Ihr Formular ohnehin erzeugt, eine Zahlseite an. Sie trägt einen EPC-QR-Code, den jede europäische Banking-App liest — Empfänger, IBAN, Betrag und Verwendungszweck sind bereits ausgefüllt. Kein Abtippen, keine Zahlendreher, kein „welches Konto war das noch gleich“.
Die Seite selbst
Beides pro Feed konfigurierbar und Merge-Tag-fähig — der Text kann also die Rechnungsnummer tragen, die Ihr Dokument bereits verwendet.
45 mm im Quadrat, Fehlerkorrekturstufe M, nach EPC069-12 für SEPA-Überweisungen. Empfänger, IBAN, BIC, Betrag, Zweck und Referenz stecken darin — genau so, wie der Standard es vorschreibt.
Erzeugt aus dem Datensatz, den der Code selbst kodiert hat — nicht aus den Einstellungen. Die Tabelle kann also nichts behaupten, was der Code nicht enthält. Sie macht die Seite auch für jemanden ohne Banking-App nutzbar, und ein falscher Empfänger wird sichtbar, statt im Punktequadrat verborgen zu bleiben. Pro Feed abschaltbar.
Die Seite übernimmt den Einzug der Vorlage nicht und sieht deshalb immer gleich aus, an welche Rechnungsvorlage sie auch angehängt wird. Über einen Filter anpassbar.
Die Rechnung, die Ihre Vorlage erzeugt, bleibt unverändert. Der Code kommt als zusätzliche Seite am Ende hinzu.
Woher die Werte kommen
Es ist dieselbe Summe, die Gravity Forms anzeigt — kein zweites Feld, das jemand pflegen muss. Der Code kann nie einen anderen Betrag verlangen als die Rechnung ausweist. Ein Formular ohne Preisfelder ergibt einen offenen Betrag; die Banking-App fragt dann beim Zahlenden nach — besser als gar kein Code.
Gravity PDF führt keine eigene Rechnungsnummer — je nach Setup stammt sie aus einer Vorlage, einem Formularfeld oder einem anderen Add-on. Statt eine Quelle fest zu verdrahten, ist der Verwendungszweck Merge-Tag-fähig: Schreiben Sie die Tags hinein, die Ihr Dokument ohnehin verwendet, und jede Quelle ist erreichbar.
Der EPC-Standard erlaubt entweder eine strukturierte Creditor Reference oder freien Verwendungszweck — nie beides. Statt daran zu scheitern, bietet der Feed die Wahl: die Referenz, wenn eine konfiguriert ist, immer die Referenz oder immer den Text.
Aus ISO 20022, von der Lieferantenzahlung bis zur Steuerzahlung.
Firmenname, IBAN, BIC und Creditor Reference werden einmal unter (e)invoice Settings hinterlegt und von jedem Add-on der Familie gelesen. Keine IBAN zweimal getippt — und damit auch keine zwei IBANs.
Gebaut, um nicht zu brechen
Ein PDF entsteht in teuren Momenten — während eine Benachrichtigung versendet wird, während ein Besucher auf einen Download wartet. Ein fehlerhafter BIC kostet deshalb den BIC, nicht den Code. Ein unbekannter Zweckcode kostet den Zweck. Ein Verwendungszweck über 140 Zeichen wird gekürzt. Jede dieser Entscheidungen steht im Log, die Seite bleibt also erklärbar — aber keine davon macht aus einer zahlbaren Rechnung ein fehlgeschlagenes Dokument.
IBAN-Prüfziffern, BIC-Struktur mit echter ISO-3166-1-Länderprüfung und die ISO-7064-MOD-97-10-Prüfziffern der Creditor Reference. Ein Tippfehler fällt beim Speichern auf — nicht dann, wenn ein Kunde auf das falsche Konto zahlt.
Die Feed-Seite benennt, was fehlt: falsche Währung, Gravity PDF nicht aktiv, kein PDF an diesem Formular oder Firmenname und IBAN noch nicht hinterlegt. Dieselben Prüfungen laufen zur Renderzeit als Log-Zeile.
Die Payload-Bibliothek liegt dem Plugin bei, der QR-Encoder kommt von Gravity PDF selbst. Kein Composer-Schritt, kein API-Key, kein externer Dienst — der Code wird auf Ihrem eigenen Server berechnet.
Ein PDF, das vor dem Anlegen des Feeds gespeichert wurde, behält seinen alten Inhalt, weil Gravity PDF gespeicherte Dateien wiederverwendet. Ein Schalter baut es neu — standardmäßig aus, damit im Normalbetrieb nichts langsamer wird. Deutsch und Englisch liegen bei; alle Texte sind übersetzbar.
Voraussetzungen
| WordPress mit Gravity Forms | 2.5 oder neuer |
| Gravity PDF | 6 oder neuer |
| PHP | 8.1 oder neuer |
| Währung in Gravity Forms | EUR |
Die Währungsanforderung stammt nicht von uns: Der EPC-QR-Standard unterstützt keine andere. Das Plugin ist ein Gravity-Forms-Feed-Add-on und wird deshalb pro Formular konfiguriert — ein Formular, das Rechnung und Bestätigung erzeugt, kann die Zahlseite auch nur an der Rechnung tragen.
Einrichtung
Firmenname, IBAN und — falls vorhanden — BIC und ISO-11649-Creditor-Reference stehen auf der gemeinsamen Seite (e)invoice Settings unter Formulare → Einstellungen. IBAN, BIC und Referenz werden beim Speichern geprüft, ein Tippfehler fällt also dort auf und nicht auf der gedruckten Rechnung.
Ein Feed entscheidet, welches PDF des Formulars die Zahlseite trägt. Erzeugt ein Formular Rechnung und Bestätigung, gehört der Code nur auf die Rechnung.
Der EPC-Standard erlaubt entweder eine strukturierte Creditor Reference oder freien Verwendungszweck — nie beides. Der Feed wählt automatisch, oder Sie erzwingen eines von beidem. Merge-Tags funktionieren im Text, aus Rechnung {Invoice Number:12} vom {date_dmy} wird also der Verwendungszweck.
Die Zahlseite hängt am Ende. Ihre Vorlage bleibt unberührt.
Formulare → Einstellungen → (e)invoice Settings — einmal hinterlegt, von jedem Add-on der Familie gelesen.
Die EPC-QR-Feed-Liste eines Formulars. Ein Feed pro Dokument, das den Code tragen soll.
Feed-Einstellungen: welches PDF, welcher ISO-20022-Zweckcode und ob Referenz oder Text verwendet wird.
Das Ergebnis: die angehängte Seite. Die Tabelle entsteht aus dem QR-Code selbst und kann deshalb nie einen Wert zeigen, den der Code nicht enthält.
Die Demo erzeugt ein echtes Rechnungs-PDF mit scanbarer Zahlseite — probieren Sie es mit Ihrer eigenen Banking-App.