Gravity-PDF Add-on
Seit 2025 müssen deutsche Unternehmen strukturierte elektronische Rechnungen empfangen können, ab 2028 sie auch ausstellen. Eine Rechnung, die nur ein PDF ist, zählt dann nicht mehr. Dieses Add-on macht aus der Rechnung, die Gravity PDF ohnehin erzeugt, Factur-X / ZUGFeRD, XRechnung und PEPPOL BIS Billing 3.0 — in beliebiger Kombination, pro Feed gewählt.
Die drei Formate
| Format | Wie es ausgeliefert wird | Typischer Empfänger |
|---|---|---|
| Factur-X / ZUGFeRD | EN-16931-CII-XML im PDF eingebettet, das Dokument als PDF/A-3 neu geschrieben | Geschäftskunden |
| XRechnung | eigenständige UBL-Datei neben dem PDF | öffentliche Auftraggeber |
| PEPPOL BIS Billing 3.0 | eigenständige UBL-Datei neben dem PDF | PEPPOL-Netzwerke |
Jede Kombination ist wählbar. Alle drei entstehen aus derselben zusammengestellten Rechnung und können sich deshalb nie widersprechen. Weder XRechnung noch PEPPOL sind PDF-Hybride — sie werden als eigene Dateien geschrieben, erhalten je einen Download-Link in der Eintragsansicht und können einer Benachrichtigungs-E-Mail neben dem PDF angehängt werden.
Profile für Factur-X: EN 16931 (Comfort), EXTENDED, BASIC und XRechnung 3.0.
An Ihrem Formular, Ihrer Vorlage oder Ihrem Ablauf muss sich nichts ändern. Das PDF, das Ihr Kunde erhält, sieht genauso aus wie zuvor.
Woher die Zahlen kommen
Die Rechnungsvorlage von Gravity PDF führt bereits Rechnungsnummer, Fälligkeitsdatum und Steuersatz. Das Plugin liest sie und blendet seine eigenen Felder aus — es gibt also keine zweite Kopie, die synchron gehalten werden muss, und nichts, was auseinanderlaufen kann.
Ein Zähler-Add-on, das die gedruckte Rechnung neu nummeriert, nummeriert das XML gleich mit.
Eine über PayPal oder Stripe bezahlte Bestellung wird als Online-Zahlungsdienst gemeldet, eine Karte als Bankkarte; ein Eintrag ohne Gateway fällt auf den Code zurück, den Sie wählen. Über einen Filter erweiterbar.
Positionssummen, Nachlässe, Zuschläge, die Steueraufschlüsselung und der Gesamtbetrag werden gegen die Identitäten geprüft, die EN 16931 definiert — einschließlich des unbequemen Falls, in dem eine nicht besteuerte Versandkostenposition eine eigene, nullbesteuerte Steuerkategorie braucht.
Firmenname, Adresse, USt-IdNr., Steuernummer, Bank- und Kontaktdaten stehen auf der gemeinsamen Seite (e)invoice Settings, nicht in jedem Feed. Die anderen Add-ons der Familie lesen dieselben Werte.
Die Oberfläche folgt der Kardinalität von EN 16931: Name und Ländercode des Verkäufers sind Pflicht, eine Straße nicht, und ein Feld, dessen Wert das Plugin bereits kennt, wird nie von Ihnen verlangt. Die Länderliste kommt aus Gravity Forms selbst, beide können sich also nie darin widersprechen, was „DE“ bedeutet.
Gebaut, um nicht zu brechen
Validiert das XML nicht, lässt das Plugin Ihr PDF unberührt, statt eine kaputte Rechnung auszuliefern. Jeder Fehlerpfad endet in der normalen Ausgabe von Gravity PDF — eine abgelehnte Rechnung wird protokolliert, nicht verschluckt, und ersetzt Ihr Dokument nie durch eine Fehlerseite.
Ändern Sie einen Wert im Eintragseditor und rufen Sie das PDF erneut ab: Dokument und XML werden aus dem aktuellen Eintrag neu gebaut. Die meisten anhangbasierten Ansätze liefern weiter eine veraltete Datei aus.
Eine fehlende Bibliothek, ein unvollständiger Verkäuferblock, ein Formular ohne PDF — jedes wird als Satz auf der Feed-Seite gemeldet, bevor Sie etwas konfigurieren, und in das Gravity-Forms-Log geschrieben, wenn es zur Renderzeit auftritt.
Die Oberfläche liegt in Deutsch, Englisch und Französisch vor; die Feldnamen sind wörtlich aus der Factur-X-Spezifikation übernommen statt von Hand übersetzt. Kein externer Dienst, kein API-Key, keine ausgehende Verbindung — alles geschieht auf Ihrem Server.
Voraussetzungen
| WordPress | 6.0 oder neuer |
| PHP | 8.2 oder neuer |
| Gravity Forms | 2.5 oder neuer, mit Zahlungs- oder Produktfeld |
| Gravity PDF | 6.0 oder neuer |
Die Rechnungsvorlage von Gravity PDF wird empfohlen, ist aber nicht zwingend. Die Bibliothek, die CII und PDF/A-3 erzeugt, liegt dem Plugin bei — es gibt also keinen Composer-Schritt.
Einrichtung
Firmenname, Land und entweder USt-IdNr. oder Steuernummer sind das Minimum, das der Standard verlangt. Sie stehen auf der gemeinsamen Seite (e)invoice Settings zusammen mit dem Factur-X-Block — Zahlungsmittel, Zahlungsziel und PDF/A-3-Stufe.
Factur-X / ZUGFeRD bettet das XML in das PDF ein; XRechnung und PEPPOL BIS 3.0 werden als eigenständige UBL-Dateien daneben geschrieben. Jede Kombination, pro Feed gewählt — und alle entstehen aus denselben Rechnungsdaten, können sich also nie widersprechen.
Jedes Käuferfeld nimmt Merge-Tags, ein Wert lässt sich also aus mehreren Formularfeldern zusammensetzen — ein Name etwa aus Vor- und Nachnamensfeld. Name und Land sind die beiden, auf denen der Standard besteht.
Das XML wird gegen das XSD geprüft; das fängt strukturelle Fehler, aber nicht jede fachliche Regel. Schicken Sie eine erzeugte Rechnung einmal durch einen Schematron- oder KoSIT-Validator — und durch den Viewer, den Ihr Empfänger tatsächlich verwendet.
EN 16931 Seller — von jedem Add-on der Familie gelesen, einmal ausgefüllt.
Factur-X / ZUGFeRD: Zahlungsmittel, Zahlungsziel und PDF/A-3-Konformitätsstufe.
Zwei Feeds an einem Formular — einer für ZUGFeRD, einer für PEPPOL BIS Billing 3.0.
Der Feed wählt die Formate. Die Rechnungsnummer kommt aus der Gravity-PDF-Vorlage, gedruckte Nummer und BT-1 sind also identisch.
Die Käuferseite wird über Merge-Tags zugeordnet — zusammengesetzt aus beliebig vielen Formularfeldern.
Eine Steuerkategorie und ein Satz pro Rechnung, dazu die nullbesteuerte Versandposition.
Es sind meist weniger, als man zu Projektbeginn annimmt. Sagen Sie uns, wer Ihre Rechnungen empfängt, und es ist schnell klar, was ZUGFeRD ist, was XRechnung und was Sie gar nicht brauchen.