PDF to E-Invoice: How PEDIF Complements EDI Processes Where PDF Invoices Remain

The EDI Lane Is Running — But What Happens at the Side Entrance?

In many companies, the main digital route has long been built. EDI is running. E-invoicing is strategically defined. Central systems are connected. For standard processes, there are clear formats, established partner routes and well-practiced workflows.

And yet, in day-to-day operations, a side entrance often remains open.

That is where invoices do not come from the central EDI process, but from side systems, specialist applications, manual special cases or invoice forms that are difficult to adapt. From a business perspective, these invoices are often correct. Technically, however, they are still created as PDFs.

This is exactly where the SEEBURGER–PEDIF use case comes in: SEEBURGER stands for established EDI and e-invoicing processes. PEDIF complements this setup where PDF invoices from outbound processes need to be transformed into structured, verifiable e-invoice outputs.

The message is deliberately not: replace EDI.
The message is: close the gap that EDI does not always reach in real corporate environments.

The Real Problem Is Not EDI — It Is the PDF Gap

Many decision-makers know the situation: the company is more digital than it appears from the outside — and at the same time more heterogeneous than project plans suggest.

Alongside the central ERP system, there are specialist systems, billing tools, portals, special processes or historically grown applications. Some of them reliably generate invoices, but only as PDFs. Others cannot natively output XRechnung or ZUGFeRD. Others only allow invoice forms to be adapted with considerable effort.

So the problem is not that EDI does not work. The problem is that not every invoice comes from an EDI-ready process.

For e-invoicing projects, this is precisely where things become critical. The last mile is rarely made up of one ideal system. It consists of many real invoice sources: core systems, side systems, special cases, manual exceptions and customer-specific requirements.

PEDIF addresses this PDF gap.

Why PDF Invoices Are Not Automatically E-Invoices

A PDF is digitally visible. But that alone is not enough for an e-invoice.

Since January 1, 2025, in the domestic German B2B context, an e-invoice generally exists only if it is issued, transmitted and received in a structured electronic format that enables electronic processing. According to the German Federal Ministry of Finance, a simple PDF document no longer falls under this definition; if it does not meet the requirements of an e-invoice, it is treated as another type of invoice.

Transition rules apply for companies: from January 1, 2025 to December 31, 2026, invoice issuers may, under certain conditions, continue to issue other types of invoices. According to the BMF FAQ, for invoice issuers with prior-year revenue of up to EUR 800,000, this period is extended until the end of 2027. Details, exceptions and individual cases should be reviewed from a tax or legal perspective.

Important for practice: XRechnung and suitable ZUGFeRD/Factur-X profiles are relevant formats, but their suitability in a concrete case depends on the structured data set, mandatory fields, the selected profile and validation. This article does not constitute legal advice.

Why Existing Systems Can Still Remain in Place

The obvious reaction to a PDF gap is often: then we need to rebuild the source system.

Sometimes that is true. But often, it is not the fastest or most economical path.

An ERP migration, a new invoice form development project or a deep redesign of a side system can be expensive, slow and organizationally difficult. In addition, these systems often work well enough in everyday operations. They generate invoices, cover special cases and are established in specialist departments.

That is why PEDIF does not primarily start by replacing the frontend. PEDIF starts at the document output.

The existing system can continue to generate its PDF invoice. PEDIF uses this invoice as the starting point, recognizes recurring layout and document patterns, extracts relevant data, structures it, checks it and generates a suitable e-invoice output.

Or, more simply:

PDF remains the starting point. Structured data is the result.

Where PEDIF Comes In Together with SEEBURGER

The interaction can be understood as two complementary lanes.

SEEBURGER covers established EDI and e-invoicing processes. PEDIF complements this world where invoices originate from PDF-based outbound processes.

A fitting analogy is the VIP lane and the side entrance:

EDI is the digital VIP lane. Everything is structured, prepared and runs through defined routes. PDF invoices from side systems and special processes, on the other hand, come through the side entrance. Humans can read them, but automated target processes cannot readily use them. PEDIF ensures that this side entrance also leads into the organized data flow.

PEDIF is not simply OCR. OCR reads characters. PEDIF recognizes recurring business documents, assigns content to the right business context and creates structured outputs for downstream systems.

For companies in a SEEBURGER environment, this creates a pragmatic complementary approach: the main EDI/e-invoicing route remains in place. PEDIF helps bring PDF-based residual and special cases into structured e-invoicing processes.

Practical Workflow: From PDF Invoice to E-Invoice Output

1. PDF Output from Main, Side or Special Systems

The starting point is a PDF invoice. It may come from a central system, but more often it comes from a side system, a specialist process or invoice form logic that is difficult to adapt.

The key point: the source system does not necessarily have to be able to generate XRechnung or ZUGFeRD itself.

2. PEDIF Recognizes the Layout and Relevant Invoice Data

PEDIF analyzes the PDF invoice and identifies relevant invoice information. This can include header data, footer data, line-item tables, totals, taxes, free-text information, references or attachments.

Recurring layouts create the strongest leverage: if a document pattern can be reliably recognized and assigned to the right business fields, processing can become repeatable.

3. Data Is Structured and Checked

The recognized information becomes a structured data set. This step marks the difference between “the PDF is readable” and “the data is processable.”

Mandatory fields and business plausibility are especially important. If information is missing, incorrect or cannot be clearly derived, the process needs clear rules: enrichment from a reliable source, clarification, exception handling or human-in-the-loop review.

4. E-Invoice Output Is Generated and Validated

In the next step, an e-invoice output is generated from the structured data, for example in the context of XRechnung or ZUGFeRD.

The wording is deliberately cautious: the target is a validatable or validated output in a suitable format. Whether a specific data set meets the requirements depends on the content, mandatory fields, format profile and validation.

5. Handover to the Target System or SEEBURGER Process

After generation, the structured output can be handed over to a target system or into an existing SEEBURGER/customer process. The exact technical handover must be reviewed in the specific project: format, interface, responsibilities, monitoring, error handling and approval process.

What Should Be Checked Before Go-Live

A PDF-to-e-invoice process should not only work technically; it should also remain controllable.

Before going live, at least the following points should be clarified:

Decision Support: When Is PDF to E-Invoice with PEDIF Worth Considering?

PEDIF is particularly relevant when several of the following statements apply:

●      EDI or e-invoicing infrastructure already exists, but not all invoices run through it.

●      Side systems generate PDF invoices but cannot output XRechnung or ZUGFeRD.

●      Special invoices still need to be processed.

●      Invoice forms cannot be adapted quickly enough.

●      Customers expect structured e-invoices.

●      The organization wants to respect existing systems while modernizing invoice output.

●      Layouts repeat and are suitable for structured processing.

●      Exceptions should remain visible and controllable.

If only a few rare special cases are affected, a manual solution may be more economical. But if recurring PDF invoice sources exist, PEDIF becomes interesting as an output layer.

Common Misunderstandings

“If We Have EDI, We Do Not Need PDF Processing.”

Not necessarily. EDI can cover the core process very well. Nevertheless, invoices from side systems, special cases or manual processes may remain. These residual cases often become critical in e-invoicing projects.

“But a PDF Is Electronic.”

Yes, but it is not automatically an e-invoice. A simple PDF is electronically visible, but not structured enough to meet the requirements for an e-invoice under the current B2B rules.

“Then We Have to Rebuild Every Side System Immediately.”

Not necessarily. If the system can still generate PDF invoices, PEDIF can start at the output and generate structured data or e-invoice outputs from it. Whether that is sufficient in a specific case depends on data quality, mandatory fields and the target process.

“PEDIF Replaces EDI.”

No. PEDIF does not replace EDI. PEDIF closes the gap where EDI does not reach: PDF-based long-tail, side and special cases.

“Every PDF Automatically Becomes a Valid E-Invoice.”

No. The decisive factors are content, mandatory fields, format profile, validation and process approval. PEDIF can support technical generation and checking, but it does not replace a legal case-by-case assessment.

FAQ

Is a PDF Invoice Automatically an E-Invoice?

No. A simple PDF is an electronic document, but not a structured e-invoice under the current B2B e-invoicing rules. An e-invoice must be available in a structured electronic format and enable electronic processing.

When Is PDF to E-Invoice Relevant for Companies?

Especially when invoices from side systems, legacy systems or special systems continue to be generated as PDFs while customers or target processes expect structured e-invoice formats.

Does PEDIF Replace EDI?

No. PEDIF complements EDI. EDI remains the structured main route. PEDIF helps where documents still originate as PDFs and need to be transformed into structured target processes.

What Happens If a Side System Cannot Output XRechnung or ZUGFeRD?

Then it can be assessed whether PEDIF can use the PDF output of that system as a starting point. The prerequisite is that the relevant invoice information is available, clearly recognizable or controllably enrichable.

Can Unusual Invoice Structures Also Be Processed?

Yes, such cases can be assessed. PEDIF is designed to structure recurring document patterns and complex invoice information. The concrete feasibility depends on the layout, data, mandatory fields and target requirements.

Which Information Must Be Checked Before Conversion?

In particular, mandatory fields, invoice line items, tax information, totals, references, recipient data, target format and validation rules should be checked. Which information is required in a concrete case depends on the individual scenario.

When Does a PDF Invoice Process Need Human-in-the-Loop?

Human-in-the-loop is useful when layouts are new, mandatory information is missing, data cannot be recognized clearly or business exceptions occur. No-touch does not mean no-control; it means that only exceptions require attention.

Conclusion

The e-invoicing obligation makes visible what has long existed in many companies: there are gaps between the central EDI process and the real document landscape.

SEEBURGER and PEDIF address this interface in a complementary way. SEEBURGER stands for established EDI and e-invoicing processes. PEDIF complements this by enabling PDF invoices from side and special processes to be transformed into structured, verifiable e-invoice outputs.

For decision-makers, this is a pragmatic path: respect existing systems, capture PDF residual cases, extend e-invoice readiness and reduce the need for deep system redesign where an output layer can act faster than a major system project.