Automate PDF invoices into validated ZUGFeRD e-invoices
Your ERP can keep producing the PDF invoices your team already uses. PEDIF turns the required invoice data into the appropriate ZUGFeRD structure, creates the hybrid e-invoice and validates the result before it moves downstream.
What does "PDF to ZUGFeRD" actually mean?
A standard PDF invoice is designed mainly for people to read. A ZUGFeRD invoice keeps a readable PDF view and adds structured XML data that accounting and ERP systems can process automatically.
Normal PDF invoice
The PDF shows invoice numbers, line items, taxes, totals and payment details in a layout people can read. Automated ERP, EDI and e-invoice workflows need those values in a predictable data structure.
ZUGFeRD hybrid e-invoice
A ZUGFeRD invoice uses a PDF/A-3 document with embedded structured XML. People can read the PDF while software processes the XML. Select the ZUGFeRD / Factur-X version and profile required for the recipient and workflow.
Why companies convert PDF invoices to ZUGFeRD
Many ERP, billing and industry systems already produce reliable PDF invoices. The gap appears when a customer or downstream process requires ZUGFeRD and the source system cannot generate it.
Keep a stable ERP
If the source system already works, you should not need a major ERP upgrade just to add a ZUGFeRD output path.
Meet different recipient requirements
One billing process may need to support ZUGFeRD, XRechnung, EDI or customer portals, depending on the recipient.
Keep the familiar invoice view
Finance teams and customers are used to the existing invoice design. ZUGFeRD can combine that human-readable view with machine-readable invoice data.
Support multiple billing systems
Subsidiaries, sites and specialist tools can keep their recurring PDF layouts while the required invoice data is structured centrally.
Avoid rebuilding every source system
Instead of modifying each invoice-generating application, use the recurring PDF as the starting point for a controlled ZUGFeRD process.
Build validation into the workflow
Generating XML is only one step. The workflow should also check required data, business rules and the selected ZUGFeRD profile before delivery.
How PDF to ZUGFeRD works with PEDIF
PEDIF is built for repeatable invoice workflows, not mainly for one-off manual conversion. We first check the recurring layout, required fields, target profile, recipient requirements and downstream system.
Keep creating the PDF
Your ERP or billing system continues producing the invoice as it does today.
Map the recurring layout
PEDIF identifies the approved invoice layout and maps the fields needed for the e-invoice.
Structure the invoice data
Invoice number, seller and buyer data, line items, taxes, totals and other required values are prepared in a consistent structure.
Map to the required profile
The structured data is mapped to the ZUGFeRD / Factur-X profile required for the workflow.
Create the ZUGFeRD file
The PDF/A-3 document and structured XML are combined into the required hybrid e-invoice.
Validate and deliver
PEDIF checks the output before approved invoices continue to the downstream process. Exceptions are routed for review.
No-touch does not mean no-control. Reliable automation requires defined rules, validation and a clear exception path for missing or contradictory data.
Can you keep your existing PDF invoice design?
In many cases, the familiar invoice view can remain part of the ZUGFeRD file. That makes the format well suited to PDF-first invoice workflows.
What can remain
The existing invoice appearance – including branding, line items, totals and customer-specific presentation – can potentially remain the visual component if it is technically suitable.
What must be checked
PDF/A-3 requirements, the selected ZUGFeRD profile, mandatory data, data quality and consistency between the visible PDF and structured XML. Under Germany's current e-invoice rules, the structured part is especially important in hybrid invoices.
ZUGFeRD vs. a standard PDF invoice
| Criterion | Normal PDF | ZUGFeRD |
|---|---|---|
| Readable by people | Yes | Yes, through the PDF visual component |
| Structured invoice data | Not automatically | Yes, as embedded XML |
| Machine processing | Needs an additional recognition/structuring step | Designed for software processing through the structured part |
| German e-invoice requirements | A simple PDF alone does not meet the new definition | Suitable ZUGFeRD versions/profiles can meet the requirements |
| Validation | No EN 16931 format validation | XML and business rules can be validated against the target profile |
| Existing invoice design | Yes | Can remain as the PDF/A-3 visual component |
PDF to ZUGFeRD or PDF to XRechnung?
Both formats make invoice data machine-readable. The main difference is whether the invoice includes a readable PDF view and which format the recipient requires.
ZUGFeRD: readable PDF + structured XML
Use ZUGFeRD when a readable invoice view should remain available and the recipient accepts the required profile.
XRechnung: structured XML
XRechnung is an XML-based e-invoice format without an integrated PDF invoice view. Use it when the recipient or process explicitly requires XRechnung.
The right format depends on the recipient, required profile, downstream system and delivery channel.
When does PEDIF make more sense than an ERP rebuild?
If your ERP already creates the right ZUGFeRD output cleanly and validates it, the native route is often the logical first choice. PEDIF is relevant where the operational reality remains PDF-first across multiple source systems or recurring special cases.
Existing PDF generation can remain in scope.
Recurring invoice layouts can be structured in a controlled way.
ERP, DMS, EDI and accounting systems do not need to be replaced wholesale.
Target profile and mandatory fields are clarified before implementation.
Validation becomes part of technical handoff.
Missing or contradictory values do not silently pass into the target system.
A focused rollout can start with a limited set of recurring layouts.
Additional structured target paths can be assessed separately by workflow.
PDF remains the starting point. Structured data is the target. That reflects PEDIF's current positioning for document-based e-invoice, ERP and EDI workflows.
Is PEDIF a good fit for your PDF-to-ZUGFeRD workflow?
Good fit
Companies with recurring B2B invoices
Finance, Accounting, ERP, IT and EDI teams
Multiple billing or legacy systems
Stable PDF layouts but missing structured exports
Recipients with different invoice requirements
Processes where validation and exception handling matter
Validation: creating the XML is not enough
A reliable ZUGFeRD workflow must validate both the technical format and the business data before the invoice is delivered downstream.
Profile and version
Which ZUGFeRD / Factur-X version and profile does the recipient or workflow require?
Required data
Are all mandatory invoice values available in the PDF, or must some come from ERP master data or customer records?
Calculation checks
Do line items, net totals, taxes, charges, discounts and invoice totals reconcile?
PDF and XML consistency
Does the visible invoice match the structured XML? Any differences must be detected and resolved.
Recipient requirements
Does the recipient require a buyer reference, purchase order reference, payment details or other process-specific data?
Exception handling
If required data is missing or a value fails a validation rule, route the invoice for review instead of passing it downstream silently.
PDF, ZUGFeRD and Germany's e-invoice rules
Under Germany’s e-invoice rules, a simple PDF alone does not meet the structured e-invoice definition. Transitional rules still apply to invoice issuance.
What matters in 2026
According to the German Federal Ministry of Finance FAQ, invoice issuers can generally continue using "other invoices" through 31 December 2026. Where the previous year's turnover does not exceed €800,000, the transition can extend through the end of 2027 under the stated conditions. German businesses have needed to be able to receive e-invoices since 1 January 2025.
ZUGFeRD as a possible target path
The Ministry lists ZUGFeRD from version 2.0.1 – excluding the MINIMUM and BASIC-WL profiles – among the common German formats that can meet the VAT requirements for an e-invoice. The correct version and profile still need to be assessed for the specific workflow.
FAQ
Next step
Check a PDF invoice
We review the recurring layout, mandatory data, intended ZUGFeRD target path and downstream workflow. The first step is a technical process and document check – not legal advice and not a blanket promise that every invoice can be automated.
Check a PDF invoiceContact Us
Questions, need help choosing the right setup?
Book a Meeting
Prefer to talk directly? Pick a time that works for you.