For companies with PDF invoice processes
Your invoicing or ERP system still produces PDFs, while customers require XRechnung, ZUGFeRD or structured invoice data? PEDIF extends the existing process by transforming PDF invoices into structured data for the agreed e-invoicing workflow.
The generated target output is technically validated before handover. Ambiguous cases remain visible.
What happens next?
Briefly describe the invoice source, volume and target process. We assess whether a PDF-first approach is a suitable fit and then coordinate the secure exchange of representative sample documents.
No ERP replacement. No upload of sensitive invoices in this first step.
Check your e-invoice gapLayout, mandatory fields and data quality of your PDF invoice are assessed.
Invoice data is structured into the target format (e.g. XRechnung, ZUGFeRD) and checked against the applicable rules.
The validated e-invoice is handed off to your ERP, EDI or agreed target process.
A PDF invoice is readable for people. European e-invoice, ERP or EDI workflows need structured invoice data, target profiles and validation rules.
The existing system can continue to produce PDF invoices as input
PEDIF converts them to compliant e-invoices automatically
No Billing System changes, no manual mapping required
Incoming PDF invoices can be converted into structured invoice data for a defined scope
Suppliers can keep their existing PDF channel, while the recipient workflow receives structured data format
E-invoice workflows differ by country. Germany, France and Poland as country examples for assessing PDF-first invoice processes.
Many companies already generate their invoices digitally:
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.
Domestic companies must generally be able to receive e-invoices. An e-mail account may be sufficient for technical reception.
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.
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.
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.
Most companies do not start from a greenfield site.
In addition to the central ERP, there are often:
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.
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:
The advantage: the technical invoicing can be retained, while the output for structured target processes is expanded.
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.
A PDF-to-e-invoice process with PEDIF is particularly relevant if several of the following statements are true:
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.
At the beginning it is clarified:
The goal is not an isolated file conversion, but a resilient end-to-end process.
Representative sample documents are used to examine whether the required information is complete and unambiguous.
These include, for example:
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.
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.
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.
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:
Validation can make missing or illogical information visible. It is therefore an important control step before shipping or handover.
Depending on the agreed implementation, the structured output can be transferred to an existing process, for example to:
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.
Both formats make invoice data structured and machine-readable. However, they differ in presentation and use.
The XRechnung is a structured XML data set.
It is particularly suitable if:
An XRechnung does not look like a classic invoice. It contains the invoice as a structured data record.
ZUGFeRD combines a readable PDF/A-3 representation with embedded structured XML data.
The format is particularly suitable if:
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.
The selection should not be made solely on the basis of a general format preference. The decisive factors are:
PEDIF can check both target paths. The specific suitability is assessed in the PDF invoice check based on the actual process.
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.
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.
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.
The process should describe in a comprehensible way:
E-invoicing is therefore not just a format project. It concerns finance, accounting, tax, IT, ERP, EDI and operational process responsibility.
Functioning ERP, invoicing and specialist systems do not have to be replaced immediately simply because of a lack of e-invoice output.
Different recipient formats can be mapped in a defined target process instead of setting up a manual special path for each customer.
Invoice information is not only transmitted visually, but also provided in a structured manner for ERP, EDI, DMS and follow-up processes.
Incomplete or ambiguous invoices can be stopped and checked in a targeted manner.
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.
Not every PDF can be converted into a reliable e-invoice output without checking.
In the PDF invoice check, we check, among other things:
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.
Questions, need help choosing the right setup?
Prefer to talk directly? Pick a time that works for you.
The calendar is provided by Microsoft Bookings and loads when you click.
