PDF to E-Invoice

Many companies already generate their invoices digitally:

• The invoice is created in the ERP or billing system.
• It is saved as a PDF.
• It is sent by e-mail or uploaded to a portal.
• A copy is stored in the DMS or archive.

For humans, this process is digital. However, a simple PDF is no longer sufficient for the legal definition of an e-invoice.

An e-invoice must be issued, transmitted and received in a structured electronic format and must allow electronic processing. A simple PDF without a structured data record is therefore considered a miscellaneous invoice – even if it is sent electronically.

What applies when?

Since 1 January 2025

Domestic companies must generally be able to receive e-invoices. An e-mail account may be sufficient for technical reception.

2025 and 2026

Invoice issuers can continue to use other invoices under the transitional arrangements. For a simple PDF invoice, the consent of the recipient is still required.

From 1 January 2027

The extended transitional regulation now only applies to invoice issuers whose previous year's turnover is no more than 800,000 euros. Invoice issuers above this limit must generally issue e-invoices for affected domestic B2B sales, unless an exception applies.

From 1 January 2028

After the expiry of the transitional regulations, e-invoicing will generally be mandatory for affected domestic B2B sales.

Exceptions may apply, among other things, to low-value invoices of up to 250 euros, travel tickets, services provided by small businesses and certain unaffected transactions. The specific legal and tax classification should be examined on a case-by-case basis.

The real challenge is the PDF gap

Most companies do not start from a greenfield site.

In addition to the central ERP, there are often:

• older invoicing and billing systems,
• specialized applications,
• service and project solutions,
• subsidiaries with their own processes,
• manually generated special invoices,
• custom forms,
• portals and historically grown applications.

These systems work professionally. They generate correct invoice content and are established in the specialist departments. However, they are often unable to generate an XRechnung or ZUGFeRD file in the required profile.

Companies with an existing EDI or e-invoicing infrastructure therefore often have PDF-based residual cases. Not every invoice comes from the structured main process.

PEDIF closes this PDF gap. The solution does not replace a functioning EDI process, but complements it where subordinate, legacy or special systems continue to generate PDF invoices.

Continue to use existing invoicing processes

A complete replacement of the ERP or billing system is not always the fastest or most economical way.

PEDIF therefore does not primarily start with the source system, but with the invoice output:

1. The existing system continues to generate the usual PDF invoice.
2. PEDIF recognizes the shared invoice and layout pattern.
3. Relevant header, item, tax and total data are assigned to the correct fields.
4. The data is transferred into a structured target structure.
5. A suitable e-invoice output is generated and validated.
6. The result is transferred to the intended sending, ERP, EDI, DMS or archiving process.

The advantage: the technical invoicing can be retained, while the output for structured target processes is expanded.

PEDIF is more than just OCR

OCR recognizes visible characters. However, for an e-invoice, it is not enough to read text from a document.

For example, a value such as "1,250.00" can be a unit price, an item total, the net amount, the tax amount, or the gross amount. A date can mean an invoice, service, delivery or due date.

For a resilient data process, therefore, not only characters must be recognized, but also their business meaning, table structure and assignment.

OCR reads characters. PEDIF recognizes recurring business documents.

The PDF does not result in a simple text export, but a defined data flow with field logic, validation rules and exception handling.

For which companies is a PDF-first bridge suitable?

A PDF-to-e-invoice process with PEDIF is particularly relevant if several of the following statements are true:

• Your ERP or billing system reliably generates PDF invoices, but not suitable structured e-invoices.
• Adapting or replacing the source system would be expensive or time-consuming.
• In addition to the main system, there are other invoice sources.
• You already have EDI, but not all invoices go through the structured process.
• Customers demand different formats or transfer methods.
• Invoice data should not be manually re-entered for each recipient.
• Finance and IT are looking for a pragmatic bridge instead of a comprehensive migration project.

For a few, infrequent individual invoices, a manual solution can be more economical. The biggest leverage comes from recurring invoice sources, layouts, and recipient requirements.

How the conversion from PDF to e-invoice works

1. Define the invoicing process and goal

At the beginning it is clarified:

• Where are the PDF invoices created?
• How many invoices and layout variants are there?
• What are the recipient groups?
• What target formats are needed?
• What shipping or handover methods are expected?
• Which systems are involved downstream?

The goal is not an isolated file conversion, but a resilient end-to-end process.

2. Check PDF layout and data quality

Representative sample documents are used to examine whether the required information is complete and unambiguous.

These include, for example:

• invoice number and invoice date,
• seller and buyer data,
• tax and VAT information,
• service or delivery time,
• payment terms,
• order and contract references,
• item numbers, quantities and prices,
• surcharges and discounts,
• net, tax and gross amounts,
• recipient or format-specific information.

Missing mandatory data cannot be replaced by a technical conversion alone. It must be supplemented from a reliable source or provided in the source process.

3. Recognize recurring document patterns

For approved invoice variants, it is defined where and in what technical significance the relevant information occurs.

This is not only about the position of a text, but also about the assignment to a technical business logic.

4. Structure invoice data

The recognized content is converted into clearly usable data fields.

A visual invoice document is thus transformed into a structured data set that can be processed for downstream systems.

5. Create and validate XRechnung or ZUGFeRD

Depending on the recipient, process and approved project scope, a target output such as XRechnung or ZUGFeRD can be generated.

Before passing them on, the following should be checked, among other things:

• technical format,
• version and profile used,
• required fields,
• mathematical consistency,
• tax logic,
• references,
• recipient requirements,
• consistency between visible and structured data.

Validation can make missing or illogical information visible. It is therefore an important control step before shipping or handover.

6. Organize handover and exceptions

Depending on the agreed implementation, the structured output can be transferred to an existing process, for example to:

• ERP or invoicing system,
• EDI or e-invoicing platform,
• DMS or archive,
• API or interface,
• customer portal,
• e-mail or shipping process.
• PEPPOL

Inconclusive or incomplete cases must not go unnoticed.

No-touch does not mean no-control. This means that standard cases are processed automatically, while exceptions receive targeted attention.

XRechnung or ZUGFeRD – which format fits?

Both formats make invoice data structured and machine-readable. However, they differ in presentation and use.

XRechnung

The XRechnung is a structured XML data set.

It is particularly suitable if:

• the recipient expressly requests an XRechnung,
• contracting authorities are involved,
• the process is strongly machine-oriented,
• pure XML processing is envisaged,
• a viewer can be used for the human view.

An XRechnung does not look like a classic invoice. It contains the invoice as a structured data record.

ZUGFeRD

ZUGFeRD combines a readable PDF/A-3 representation with embedded structured XML data.

The format is particularly suitable if:

• specialist departments still need a familiar invoice image,
• the recipient accepts a hybrid format,
• PDF-related workflows should be retained,
• structured data is required at the same time.

Important: in a hybrid e-invoice, the structured part of the data is decisive. If PDF representation and XML differ from each other, the structured data generally takes precedence.

Which format is the right one?

The selection should not be made solely on the basis of a general format preference. The decisive factors are:

• specifications of the invoice recipient,
• B2B or B2G context,
• technical target systems,
• desired human readability,
• profile and version,
• shipping route,
• archiving and testing process.

PEDIF can check both target paths. The specific suitability is assessed in the PDF invoice check based on the actual process.

Important: distinguish between outgoing and incoming invoices

Outgoing PDF invoices

For outgoing invoices, PEDIF can be used as an output layer between the existing billing or ERP system and the e-invoicing process.

The prerequisite is that all required invoice information is available in the PDF or in another reliable data source and can be clearly assigned.

Incoming PDF invoices

For incoming invoices, PEDIF can structure information from PDF documents and make it available for ERP, finance, EDI or verification processes.

However, subsequent structuring by the invoice recipient does not automatically turn a simple PDF issued by the supplier into a proper e-invoice from the supplier.

If there is an obligation to e-invoice for the turnover, the invoice issuer must provide the correct invoice form. PEDIF can support the internal data process, but does not replace the responsibility of the invoice issuer.

Checklist for a resilient e-invoicing process

Archiving

Incoming and outgoing invoices must generally be kept for eight years for VAT purposes. In the case of e-invoices, at least the structured part must be preserved intact in its original form.

In the case of ZUGFeRD, the embedded XML data set is therefore particularly relevant. If the PDF part contains additional tax-relevant information, this may also be subject to retention.

Procedural documentation

The process should describe in a comprehensible way:

• how e-invoices are generated or received,
• which systems and interfaces are involved,
• how it is checked and approved,
• how exceptions are handled,
• how shipping and handover are carried out,
• how storage is ensured.

E-invoicing is therefore not just a format project. It concerns finance, accounting, tax, IT, ERP, EDI and operational process responsibility.

What companies gain from a PDF-first approach

Respect existing systems

Functioning ERP, invoicing and specialist systems do not have to be replaced immediately simply because of a lack of e-invoice output.

Serving customer requirements in a controlled manner

Different recipient formats can be mapped in a defined target process instead of setting up a manual special path for each customer.

Structured data instead of additional manual work

Invoice information is not only transmitted visually, but also provided in a structured manner for ERP, EDI, DMS and follow-up processes.

Exceptions remain visible

Incomplete or ambiguous invoices can be stopped and checked in a targeted manner.

Step by step instead of big bang

Companies can start with selected invoice sources and layouts and expand the scope in a controlled manner.

PEDIF does not replace the ERP, accounting, archive, EDI or a tax audit. PEDIF complements existing system landscapes with a bridge between PDF-based invoice sources and structured data processes.

Is your PDF invoice suitable for XRechnung or ZUGFeRD?

Not every PDF can be converted into a reliable e-invoice output without checking.

In the PDF invoice check, we check, among other things:

• invoice source and shipping process,
• recurring layout variants,
• existing billing and mandatory data,
• data quality and possible ambiguities,
• desired target format,
• recipient requirements,
• need for validation,
• destination system and transfer route,
• expected exceptional cases.

You will receive a technical assessment of whether a PDF-first process is fundamentally suitable and which next step makes sense.

Note: the document check is not legal or tax advice and is not an automatic promise that every document can be converted into an e-invoice without additional process adjustments.