Automate PDF invoices into validated ZUGFeRD e-invoices

PDF to ZUGFeRD in practice: profiles, data and rollout

Creating a ZUGFeRD file is a technical step. Making it work reliably for every invoice, every recipient and every month-end run is a process question. The following sections explain what matters when recurring PDF invoices become validated ZUGFeRD e-invoices.

ZUGFeRD profiles explained: which one do you need?

ZUGFeRD is not a single format but a family of profiles that differ in how much structured data they carry. ZUGFeRD 2.x and the French Factur-X standard are technically aligned, so the same profile names appear in both.

Which profile is right depends on the recipient and the invoice content. Many B2B workflows use the EN 16931 profile because it covers the European core invoice model. Invoices with more complex content may need EXTENDED, while some public-sector recipients expect the XRECHNUNG profile or a pure XRechnung file instead.

• MINIMUM and BASIC WL: contain header data only, without invoice lines. Under the German e-invoice rules they are not considered e-invoices and are mainly relevant as accounting aids.
• BASIC: adds invoice lines with a reduced set of fields for simple invoices.
• EN 16931 (formerly COMFORT): maps the European standard for electronic invoices and is the usual target for B2B invoices in Germany.
• EXTENDED: extends EN 16931 with additional fields for complex scenarios, for example more detailed delivery or allowance information.
• XRECHNUNG: embeds data that follows the German XRechnung specification, for recipients that require it.

Which invoice data a ZUGFeRD e-invoice needs

A ZUGFeRD e-invoice is only as good as the data behind it. Most of the required values are already printed on the PDF invoice, but some are not visible in a form that software can use directly.

• Seller and buyer: names, addresses and VAT identification numbers or tax numbers
• Invoice identification: invoice number, invoice date, invoice type (invoice or credit note) and currency
• Delivery or service date or period
• Invoice lines: description, quantity, unit, net price and line total
• Tax information: VAT category and rate per line, taxable amounts and tax totals per rate
• Totals, allowances and charges, prepaid amounts and the amount due
• Payment terms and payment details such as the IBAN
• References the recipient requires, for example a buyer reference or purchase order number

Where the PDF alone is not enough

A PDF invoice is designed to be read by people. Some values that are obvious to a reader have to be translated into defined codes for the structured part. Units written as "pcs" or "Stk." must be mapped to standard unit codes, VAT categories must be expressed as codes rather than text, and countries and currencies need their standard identifiers.

Other values are not on the PDF at all, such as a buyer reference that a particular customer requires. In these cases PEDIF can add information from rules or master data, for example a fixed reference per customer. Where a value cannot be determined reliably, the invoice is routed for review instead of being completed by guesswork.

Typical issues when switching from PDF to ZUGFeRD

Most problems in ZUGFeRD projects are not caused by the XML format itself, but by details that a PDF tolerates and a structured invoice does not.

• Rounding differences between line totals, tax amounts and the invoice total
• Discounts or surcharges written as free text instead of defined allowances and charges
• Several VAT rates on one invoice without a clean breakdown per rate
• Credit notes and corrections that must be marked with the correct invoice type
• Missing references that the recipient needs to assign the invoice automatically
• Differences between the visible PDF and the embedded XML after manual edits

Credit notes, corrections and cancellations

Not every document in the billing process is a regular invoice. Credit notes, corrected invoices and cancellations also have to be issued as e-invoices once the obligation applies, and they have their own rules in the structured data.

A credit note is marked with its own invoice type and usually refers to the original invoice. A corrected invoice must make clear which invoice it replaces. If these documents come from the same billing system as the invoices, their layouts are often similar but not identical. PEDIF treats them as separate cases with their own recognition, mapping and validation, so that a credit note is never delivered as if it were an invoice.

• Set the correct document type for invoices, credit notes and corrections
• Carry over the reference to the original invoice where the recipient needs it
• Check signs and totals, because credit amounts are easy to invert by mistake
• Include these document types in testing before go-live, not only standard invoices

What happens on the recipient's side

The recipient's accounting or ERP system reads the embedded XML and can process the invoice without typing it in. The PDF view stays available for people who want to look at the invoice in its familiar layout.

German tax guidance treats the structured XML data as the authoritative part of a hybrid invoice. That is why PEDIF checks that the visible invoice and the XML match before an invoice is released. A mismatch is treated as an exception, not as a detail.

Archiving ZUGFeRD invoices

E-invoices have to be stored in the format in which they were issued or received, including the structured data, and must remain unchanged for the statutory retention period. For ZUGFeRD this means keeping the complete hybrid file, not only a printout or an image of the PDF view.

Because the XML carries the invoice data, archive and document management systems can also index ZUGFeRD invoices by invoice number, date, supplier or amount, which makes later searches and audits easier.

From the first invoice to steady operation

A PDF-to-ZUGFeRD workflow is usually introduced in stages, starting with the invoice layouts that occur most often.

• Collect sample invoices for each recurring layout, including credit notes and special cases
• Define the target profile and required references for each group of recipients
• Configure the layout recognition, field mapping and business rules
• Validate test invoices technically and check them against the original PDFs
• Start with selected recipients and review exceptions closely
• Extend the workflow to further layouts, sites and recipients once results are stable

One billing system, different recipient requirements

In practice, one billing run rarely goes to recipients with identical requirements. Business customers may accept ZUGFeRD, public-sector clients may require XRechnung with a Leitweg-ID, some customers expect invoices over the Peppol network and others upload them to their own supplier portal.

Instead of building a separate export for every case in the source system, PEDIF can create the required format per recipient from the same recurring PDF invoice. The recipient-specific rules, such as the target format, profile, mandatory references and delivery channel, are maintained once and applied automatically to every invoice for that recipient.

How to check a ZUGFeRD invoice

A ZUGFeRD invoice looks like a normal PDF in any viewer, so the structured part is easy to overlook. A few checks show whether an invoice is really a valid e-invoice:

• The PDF contains an embedded XML attachment, which PDF viewers usually list under attachments
• The file is a PDF/A-3 document, the archive format that allows the embedded XML
• The XML declares a profile that the recipient accepts, and not MINIMUM or BASIC WL for German e-invoices
• The XML passes validation against the schema and the business rules of that profile
• Invoice number, dates, totals and tax amounts in the XML match the visible PDF