Gravity Forms EN16931 (e)Invoices For Gravity PDF Wordpress Plugin - Rating, Reviews, Demo & Download
Plugin Description
EN16931 (e)Invoices for Gravity-PDF — Factur-X, XRechnung and PEPPOL From One Feed
From 2025 a German business must be able to receive structured electronic invoices, and from
2028 to issue them. France, Italy, Belgium and the Nordics are on the same path. An invoice
that is only a PDF stops counting.
This add-on takes the invoice Gravity PDF already produces and turns it into
Factur-X / ZUGFeRD (an EN 16931 XML embedded inside a
PDF/A-3 hybrid), XRechnung and/or PEPPOL BIS Billing 3.0
(each a standalone UBL XML file next to the PDF) — any combination, chosen per feed. Your
customer opens a PDF that looks exactly as it did before, and their bookkeeping software reads
whichever file it expects as data.
Nothing about your form, your PDF template or your workflow has to change.
What you get
-
A real hybrid, not a PDF with a file stapled to it. The XML is embedded as a PDF
attachment with the relationship and the XMP metadata the specification requires, and the document
is genuinely rewritten as PDF/A-3. -
Three formats, any combination, from one feed. Factur-X/ZUGFeRD, XRechnung and
PEPPOL BIS Billing 3.0 — all built from the same assembled invoice, so they can never
disagree with each other. Four Factur-X profiles: EN 16931 (Comfort), EXTENDED, BASIC and
XRechnung 3.0. -
Standalone XML gets its own download link and notification attachment. Any
XRechnung/PEPPOL file a feed produces appears on the entry detail screen and can be attached to
notification e-mails, alongside the PDF. -
XSD-validated on every single build. If the XML would not validate, your PDF is
left untouched. The add-on never ships a broken invoice and never replaces your document with an
error page. -
It survives a correction. Edit an entry in the backend and fetch the PDF again:
document and XML are rebuilt from the current entry. Approaches that build the XML at submission
time keep serving the values the entry had back then — for ever. -
One number, one place. Gravity PDF’s invoice template already carries an invoice
number, a due date and a VAT rate. The add-on reads them and removes its own fields from the
screen, so the printed invoice and the embedded XML cannot disagree. The
gfpdf_invoice_numberfilter is honoured, so a counter plugin that renumbers the
printed invoice renumbers the XML with it. -
The payment means follows the payment gateway. Paid through PayPal or Stripe? The
XML says “online payment service”. By card? “Bank card”. No gateway at all? Your chosen fallback.
One filter extends the map to any add-on. -
Arithmetic you can defend. Line totals, allowances, charges, the VAT breakdown and
the grand total are checked against the identities EN 16931 defines — including the
awkward case where an untaxed shipping fee needs a second, zero-rated VAT category of its own. -
Enter the seller once. Company name, address, VAT identifier, tax number and
contact details live on a shared settings page, not in every feed. -
German, English and French interface. The field names are taken verbatim from the
Factur-X specification rather than translated by hand, so an accountant recognises them. -
No external service. No API key, no account, no outbound connection, no per-invoice
fee. Everything happens on your own server.
Only what the standard demands is mandatory
The settings screens follow EN 16931’s actual cardinality instead of guessing. A seller name and a
country code are required; a street is not. A field whose value the add-on already knows — the
invoice number, the invoice date, the currency — is never demanded from you, because demanding a
value that is already known is just theatre.
And when something really is missing, the feed screen says so in a sentence before you
configure a single field: a lost library folder, an incomplete seller block, a form without a Gravity
PDF. At render time the same sentences go to the Gravity Forms log.
Requirements
- WordPress — 6.0 or newer
- PHP — 8.2 or newer
- Gravity Forms — 2.5 or newer, with a product or payment field on the form
- Gravity PDF — 6.0 or newer. The invoice template is recommended, not required
- Nothing else. The XML library ships with the plugin
What this version deliberately does not do
Honesty is cheaper than a refund, so here is the list:
-
One VAT category and one rate per invoice, plus a zero-rated line for untaxed
shipping. The invoice template also allows a different rate per field through CSS classes; those are
detected and written to the log rather than averaged into something wrong. -
No credit notes. UBL models a credit note as its own root element, not a type
code on an invoice; the builder only produces an Invoice. -
No document-level charges/allowances (BG-20/BG-21) beyond the single
shipping-as-charge case already covered above. Supporting-document (BG-24) attachment is offered
for the standalone XRechnung/PEPPOL files, not for Factur-X, which already carries the PDF as its
own container. -
PDF/A-3 level B is the default and the only level the add-on can honestly assert.
Level A additionally needs a tagged, structured document, which depends on your PDF template. -
Validated against the XSD, not against Schematron. The XSD catches structural
errors, not every business rule. Before you go live, run one generated invoice through a Schematron
validator — and through the viewer your recipient uses.
For developers
The arithmetic and validation layer (SP_EInvoice_Invoice) is framework-free and never
throws: every problem comes back as a string, because it runs while a PDF is being produced and often
while a notification is being sent. One assembled invoice array feeds all three output formats;
exactly one file (SP_EInvoice_Builder) touches the underlying library.
Three filters are provided: sp_zugferd_payment_means_map to extend the gateway mapping,
sp_zugferd_full_code_lists to offer a full code list instead of the curated subset, and
Gravity PDF’s own gfpdf_invoice_number, which the add-on respects for BT-1.
Changelog
2.1.2 (current)
- Fixed: the seller’s electronic address (BT-34) is now included in generated XRechnung and
PEPPOL BIS Billing XML — verified against a real KoSIT Validator run. Fill in the new
“Electronic address” fields under “(e)invoice Settings” if you send XRechnung or PEPPOL
invoices.
2.1.1
- Renamed from “Gravity Forms ZUGFeRD / Factur-X Extension” to reflect the scope below —
this is no longer a Factur-X-only add-on. - XRechnung and PEPPOL BIS Billing 3.0, each a standalone UBL file, selectable
per feed alongside or instead of Factur-X. PHP 8.2 now required. - Bank details (BT-84/85/86) joined the shared seller settings, shared with the EPC-QR add-on.
- The nine reference code lists can now come from a shared, centrally maintained package, with
an automatic fallback to the bundled copies. - The shared settings page gained a round of new optional fields (register details, GLN/DUNS, an
encrypted SEPA Creditor Identifier, and more) used by other add-ons of the family.
1.0.0
- Initial release.
- EN 16931 CII XML embedded into a PDF/A-3 document; four profiles.
- The invoice is assembled at render time, so a corrected entry produces a corrected invoice.
- Invoice number, due date, VAT rate and tax-on-shipping taken from the Gravity PDF invoice template
when it states them. - Payment means derived from the payment gateway, with a filterable map.
- An untaxed shipping fee produces a second, zero-rated VAT breakdown entry.
- German and French interface included.
