Gravity Forms EN16931 (e)Invoices for Gravity PDF

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_number filter 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.