E-Invoicing from PDF in Germany: How XRechnung and ZUGFeRD Fit into Existing Invoice Processes

Many companies feel they have already digitized their invoicing processes.

The invoice is created in the ERP or billing system, saved as a PDF, sent by email and archived in the DMS. For people, it looks clean: logo, invoice number, line items, tax amount, bank details. Everything is there.

For systems, the situation is less clear.

A PDF is like a photo of a shipping label. A person can read the address. A sorting system, however, does not need a nice-looking printout. It needs a machine-readable barcode. This is exactly the shift behind e-invoicing: the decisive question is no longer whether an invoice is digitally visible. The decisive question is whether its data is structured, verifiable and electronically processable.

Since 1 January 2025, under the new German definition, an e-invoice only exists if it is issued, transmitted and received in a structured electronic format and enables electronic processing. A simple PDF does not meet this definition because it does not contain a structured format. Such invoices generally fall under “other invoices” as long as transitional rules still allow their use.

For mid-sized companies with 50 to 1,000 employees, this creates a very practical question:

How can existing PDF-based invoice processes be moved toward XRechnung, ZUGFeRD or another structured e-invoice format without immediately rebuilding the entire ERP or billing system?

Why a PDF Has No Longer Automatically Been Enough as an E-Invoice Since 2025

The confusion often starts with the word “electronic”. In everyday business language, this used to mean many things: PDF, email, scan, download, customer portal, sometimes even a Word document.

For e-invoicing, however, electronic delivery is not enough. The decisive factor is the structured data format.

The German Federal Ministry of Finance describes an e-invoice as one that, in particular, complies with the requirements of the European EN 16931 standard series and uses a structured XML-based format so that invoice content can be processed electronically and automatically. In Germany, commonly used formats include XRechnung and ZUGFeRD in certain versions and profiles.

For outgoing invoices, this means:

A PDF can still look good, appear complete and be perfectly archived internally. Nevertheless, it is not automatically an e-invoice under the new definition. It is a visual document, not a structured invoice dataset.

So the problem is not the PDF itself. The problem is that ERP, DMS, EDI and customer systems cannot reliably work directly with a simple PDF.

What Makes XRechnung and ZUGFeRD Different

XRechnung and ZUGFeRD solve the same basic problem in different ways: they make invoice data machine-readable.

XRechnung: the Pure Dataset

XRechnung is a structured XML dataset. It is not designed to be opened and read like a traditional PDF. People usually need a viewer or some form of visualization to read it.

That is useful for automated processes, but unfamiliar for business departments. An XRechnung does not look like an invoice. It contains the invoice.

ZUGFeRD: Readable PDF plus Structured Data

ZUGFeRD is a hybrid format. It combines a human-readable PDF with structured invoice data in XML format. The Forum elektronische Rechnung Deutschland describes ZUGFeRD as a cross-industry data format for electronic invoice exchange. The format is based on the European EN 16931 standard and uses PDF/A-3 with embedded XML.

In practical terms:

● XRechnung is like the pure barcode for the sorting system.

● ZUGFeRD is like a shipping label that people can read and that also contains a machine-readable code.

For many mid-sized companies, ZUGFeRD is attractive because it makes the transition psychologically and organizationally easier: business departments still see a PDF. Systems can read the XML part.

However, one point is important: in hybrid formats, the structured part is decisive. If the XML data and the visible PDF section differ, the structured data part must be managed with particular care from a business-process perspective.

Why Mid-Sized Companies Are Particularly Affected

Large enterprises often have dedicated EDI teams, long-running e-invoicing projects and extensive ERP extensions. Very small companies often use standard tools, tax-advisor portals or simple cloud solutions.

Mid-sized companies sit in between.

Many companies with 50 to 1,000 employees have professional processes, but historically grown system landscapes:

The ERP reliably creates PDF invoices. The DMS archives them. Accounting checks them. Customer portals require uploads. Individual key accounts demand specific formats. Public-sector clients want XRechnung. Some customers accept ZUGFeRD. Others expect EDI. And somewhere there is still a list of special cases.

The result: the invoice process is digital, but not consistently data-capable.

This creates particular pressure for outgoing invoices. Here, the company itself must decide which format is generated, validated, sent and archived. In accounts payable, a company can react to incoming formats. In accounts receivable, the outgoing process has to be actively controlled.

Outgoing Invoices: When the ERP Can Only Create PDFs

Many ERP and billing systems can create invoices. However, not all of them can readily generate the right e-invoice formats in the required profile, validate them and hand them over through the right recipient channels.

A typical scenario looks like this:

1. The invoice is created in the ERP.

2. The ERP generates a PDF.

3. The PDF is sent by email, uploaded to a portal or handled manually.

4. The customer will require XRechnung, ZUGFeRD or a specific e-invoicing procedure in the future.

5. Finance and IT must clarify whether the ERP can deliver the data in structured form.

At this point, there are three paths.

Path 1: ERP-Native E-Invoicing

If the ERP can cleanly generate the required formats, this is usually the most direct route. The key questions then concern master-data quality, mandatory fields, validation, delivery route and archiving.

Path 2: EDI or Platform Connection

For large customers or group structures, EDI can make sense. PEDIF does not replace EDI — PEDIF closes the gap where EDI does not reach.

Path 3: PDF-First Bridge

If the existing system reliably creates PDF invoices but does not provide suitable structured outputs, a PDF-first bridge process can make sense.

This does not mean that every PDF automatically becomes a finished e-invoice. The decisive step is a fit check:

● Is the PDF layout stable?

● Are all mandatory details present?

● Can invoice data be extracted unambiguously?

● Can the structured dataset be validated against the selected rules?

● Which target format is required: XRechnung, ZUGFeRD or another format?

● How is the handover to customer, portal, ERP, DMS or archive handled?

● Who checks the format profile, mandatory fields and tax requirements?

For PEDIF, this is the relevant way to think about the problem: OCR reads characters. PEDIF recognizes recurring business documents. Visual documents become structured data flows — but always within a defined scope, with approved layouts, validation and clear process boundaries.

Incoming Invoices: Receiving Is Not the Same as Processing

The e-invoicing obligation is not only about sending invoices. Since 1 January 2025, companies must be able to receive e-invoices. According to the German Federal Ministry of Finance, an email inbox can generally be sufficient for this purpose.

But that is only the minimum threshold.

An inbox receives files. It does not check invoice data, match it against a purchase order, detect duplicates, post anything to the ERP or route exceptions.

In accounts payable, several worlds will increasingly meet:

● XRechnung as XML

● ZUGFeRD as hybrid PDF/XML

● simple PDFs during transitional phases or for cases not covered by the rules

● portal documents

● attachments, supporting documents or corrections

● special cases from purchasing, logistics or project business

Receiving an e-invoice therefore does not automatically mean that invoice processing is automated. Companies can use the opportunities of digitalization, but they must consciously design their processing steps.

From a business perspective, it would be a missed opportunity to merely receive e-invoices and then process them manually again.

The PDF-First Bridge: Turning Visual Documents into Structured Data

Imagine a mid-sized mechanical-engineering company.

The company sends many outgoing invoices every month to distributors, service partners, industrial customers and public-sector clients. The ERP is stable, the processes are established and the PDF invoices look clean. But recipient requirements are becoming more fragmented:

A public-sector client wants XRechnung.
An industrial customer prefers ZUGFeRD.
A corporate customer works with a portal.
A long-standing trading partner still accepts PDF, but only during the transition phase.

The temptation is to build a special process for every customer. That is exactly how manual loops, format errors and coordination effort arise.

A better approach is a bridge process:

1. PDF invoice as the starting point
The existing system continues to generate the familiar invoice document.

2. Layout and data check
The recurring invoice format is checked to determine whether all required data is reliably present and extractable.

3. Structuring
Invoice number, date, recipient, line items, taxes, totals and other mandatory fields are provided as structured data.

4. Format mapping
Depending on recipient requirements, a suitable structured output is created, for example XRechnung or ZUGFeRD, provided that profile, mandatory fields and validation have been approved in the project.

5. Validation and exception handling
No-touch does not mean no-control. It means: only exceptions need attention.

6. Handover
The data is passed to the intended target process: ERP, DMS, archive, interface, portal or delivery route — depending on the specific implementation scope.

That may sound technical. For Finance, however, it is above all organizationally valuable: the department does not have to manually rebuild every customer format. IT does not have to replace every legacy system immediately. And the company gains a controlled path from PDF-first to data-capable.

Where PEDIF/Supedio Can Help — and Where a Fit Check Is Needed

PEDIF is not a generic “PDF in, everything done” black box.

PEDIF is strongest where recurring business documents need to be structurally recognized, checked and converted into usable data. This is especially relevant for document-intensive supply-chain processes in which business partners continue to send PDFs or not fully structured documents.

For incoming invoices, this logic applies very directly: suppliers send PDFs, ZUGFeRD files or other documents. PEDIF can help, within defined and approved layouts, to identify relevant information, structure it and make it available for downstream processes.

For outgoing invoices, the question is somewhat different. Here, it is not only about extraction, but about generating a correct structured e-invoice output. That is why a project should begin with a fit check:

● Which PDF invoices does the existing system generate?

● Which recipient groups need which formats?

● Which mandatory fields may be missing from the PDF?

● Which data exists only in the ERP, but not in the PDF?

● Should XRechnung, ZUGFeRD or both be supported?

● Which profiles, versions and validation rules are relevant?

● Which delivery routes are actually required?

● Who is responsible for tax and business approval?

This keeps the statement clean: PEDIF can be a bridge between PDF-first processes and structured data flows. Whether a robust XRechnung or ZUGFeRD process can be created in a specific case must be assessed based on layout, data quality, target profile and integration.

Decision Aid: XRechnung, ZUGFeRD or PDF-First Bridge?

There is no one-size-fits-all answer. The right format depends on the recipient, the existing system and the process objective.

Check XRechnung if …

● the recipient explicitly requires XRechnung,

● public-sector clients are involved,

● the process is strongly machine-oriented,

● pure XML processing is accepted,

● human readability is solved through a viewer or visualization.

Check ZUGFeRD if …

● people still need a readable invoice image,

● the recipient accepts hybrid formats,

● PDF-like processes remain organizationally important,

● structured XML data is needed at the same time,

● archive and review processes can handle the hybrid format.

Check a PDF-First Bridge if …

● your existing ERP or billing system reliably creates PDFs,

● structured exports are missing or expensive to rebuild,

● many recurring invoice layouts exist,

● several recipient formats need to be served,

● Finance and IT are looking for a transitional solution with clear validation.

Check an ERP-Native Solution if …

● your ERP already generates e-invoices cleanly,

● all required mandatory fields are maintained in the system,

● validation, delivery and archiving have been clarified,

● there are no relevant PDF-only special processes.

Checklist for Finance, IT and ERP Owners

Before starting an e-invoicing project, do not start with the tool. Start with the invoice process.

1. Inventory Outgoing Invoices

Which invoice types exist? Standard invoice, credit note, cancellation, partial invoice, final invoice, collective invoice, project invoice?

2. Collect Recipient Requirements

Which customers require XRechnung? Which accept ZUGFeRD? Which use portals? Which are still in transitional processes?

3. Clarify Data Sources

Which data is in the ERP? Which data is only in the PDF? Which data is missing? Which master data needs maintenance?

4. Decide on Formats

Not every company needs everything immediately. The decisive question is which formats your customers and processes actually require.

5. Plan Validation

Check how e-invoices should be validated before sending and receiving. No single validation application is generally prescribed, but validation is central to robust processes.

6. Review Archiving and Governance

Clarify with tax advisory, compliance and IT how structured invoice data, visual components, attachments and logs must be retained.

7. Define the Exception Process

What happens if mandatory fields are missing, customer data is incomplete, or XML and PDF do not match?

8. Do Not Look Only at Outgoing Invoices

E-invoicing is not a one-way street. Anyone who sends structured invoices should also be able to process structured invoices.

Common Misunderstandings

“We send PDFs by email. So we are digital.”

Digitally visible is not the same as structurally processable. A PDF can look perfect to people and still be unusable for systems.

“ZUGFeRD is just a normal PDF.”

Not quite. In addition to the visual component, ZUGFeRD contains structured XML invoice data in the PDF/A-3 document. These embedded data elements make the difference.

“XRechnung is impractical because you cannot read it.”

XRechnung is not built for the eye, but for systems. People need a viewer or visualization. That is unfamiliar, but not a flaw of the format.

“If we can receive e-invoices, our invoice processing is automated.”

No. Receiving is infrastructure. Processing is process design.

“A converter solves everything.”

Only if data quality, mandatory fields, format profile, validation, handover and responsibilities are right. Otherwise the converter becomes a new exception inbox.

Practical Example: Outgoing Invoices in Wholesale

A technical wholesaler with several locations creates outgoing invoices in its ERP. The PDF invoice has been accepted for years. But the customer structure is changing:

Some public-sector clients expect XRechnung.
A large industrial customer wants ZUGFeRD.
Other customers work with portals.
The company’s own ERP can reliably generate PDFs, but structured e-invoices only to a limited extent.

A sensible project logic would be:

First, the most important invoice types and recipient groups are identified. Then the company checks which invoice data is available in the ERP and which data is reliably present in the PDF. For recurring layouts, a structured data flow can be established. Missing mandatory fields are not “automated away”; they become visible as a master-data or process issue.

This does not create a magic shortcut. It creates a controlled transition: from the PDF as a visual document to the invoice as a data object.

Conclusion: E-Invoicing Is Not a PDF Problem, but a Data Problem

E-invoicing does not only force companies into new file formats. It changes how they think about invoice processes.

In the past, the question was often: Can a person read the invoice?
Today, the better question is: Can the system check, process, route and retain the invoice?

XRechnung and ZUGFeRD are two ways to create this structure. XRechnung consistently relies on XML. ZUGFeRD combines a readable PDF with structured XML data. For many mid-sized companies, however, the real challenge will not be format selection alone, but the bridge between existing ERP, PDF and customer processes.

PEDIF replaces neither ERP nor EDI nor DMS. PEDIF closes the gap where business documents are digitally visible, but not yet structurally usable.

PDF remains the input. Structured data is the result.

Are your PDF invoices ready for XRechnung or ZUGFeRD?

Many companies do not have to replace their ERP immediately in order to work in a more structured way. The first step is a clean fit check: Which outgoing invoices do you generate today? Which formats do your customers require? Which data is missing? And where could a PDF-first bridge process make sense?

Request an e-invoicing fit check with Supedio
Check whether your existing PDF invoice processes can be extended toward XRechnung, ZUGFeRD or structured invoice data — in a defined scope, with clear validation and without blanket automation promises.

FAQ

Is a PDF invoice an e-invoice?

Since 2025, a simple PDF is not an e-invoice under the new German definition because it is not a structured electronic format. During certain transitional phases, it may still be permitted as an “other invoice”, but it is not automatically an e-invoice.

What is the difference between XRechnung and ZUGFeRD?

XRechnung is a structured XML dataset without an additional PDF invoice image. ZUGFeRD is a hybrid format: a readable PDF with embedded structured XML invoice data.

Can a PDF invoice be converted into XRechnung?

Technically, a PDF-first process can serve as the starting point for structured invoice data in defined cases. Whether a valid XRechnung can be created from it depends on layout, mandatory fields, data quality, target format, validation and business approval. A blanket “every PDF works” statement would be misleading.

Can a PDF invoice be converted into ZUGFeRD?

A ZUGFeRD process requires not only a visible PDF, but also structured XML invoice data. If the relevant invoice data is complete and correct, a PDF-first bridge process can be assessed. Format profile, version, validation and archiving must be clarified project by project.

From when do companies have to send e-invoices?

For domestic B2B transactions, new rules with transitional periods have applied since 2025. The specific obligation depends on the period, transitional rules and use case. Statements about deadlines and exceptions should be legally reviewed before publication.

Do companies have to be able to receive e-invoices?

Yes. Since 1 January 2025, domestic companies must be able to receive an e-invoice. However, this does not mean that processing is automatically automated.

Is ZUGFeRD better than XRechnung?

Not generally. ZUGFeRD is often practical when people still need to see a PDF. XRechnung makes sense when a pure XML process is required or preferred. The right choice depends on the recipient, the process and the existing system.

Does PEDIF replace an ERP system?

No. PEDIF does not replace an ERP, DMS or EDI system. In defined scenarios, PEDIF can help turn recurring business documents into structured data flows and close gaps between PDF-first processes and target systems.