Does your ERP or billing system still create PDF invoices? PEDIF recognizes your layouts, structures the required invoice data, validates the agreed target output and automatic results to your defined Peppol workflow.
Peppol is not a file format. It is a network and interoperability framework for exchanging structured electronic business documents. A normal PDF invoice cannot simply be “sent through Peppol” and become a structured e-invoice. Its business data first needs to be structured, mapped to the required invoice specification and validated. Only then should the result be handed to the configured Peppol transport process.
Your existing ERP, billing or legacy system keeps creating the familiar invoice PDF.
PEDIF maps relevant fields into the agreed structured target profile, based on recipient, country and workflow.
The validated output is delivered directly via Peppol to the verified recipient defined for the transaction.
Not “upload a PDF and hope”, but a defined automation workflow with layout recognition, mapping, validation and a visible review path for exceptions.
The existing source system creates invoices as before.
PEDIF processes approved, recurring invoice layouts.
Header, line-item, tax, total and reference data is mapped by business meaning.
Data is mapped to the agreed Peppol/e-invoice target structure.
Format, mandatory fields, calculations and agreed business rules are checked.
Approved results move downstream; unclear cases enter review.
Peppol uses a four-corner model. Sender and receiver can use different service providers or Access Points. The business document and the network transport are separate layers. For a PDF-first process, that separation is important: PEDIF prepares structured invoice data; the configured Access Point handles transmission through the Peppol network.
The European standard provides the shared semantic core model for structured e-invoice data.
The Peppol invoice specification builds on EN 16931 and is used for invoice exchange in Peppol environments. The current technical documentation uses UBL syntax for invoices.
XRechnung is a German CIUS of EN 16931. In a Peppol context, recipient requirements, the current national ruleset and the actual document type determine the correct target.
For PEDIF, this means the target has to be clear before automation starts: which structured output the recipient accepts, which version and rules apply, and how the invoice will be transported afterward.
Conversion cannot invent missing mandatory information. Required data needs to be reliably available in the PDF, ERP, master data or another trusted source.
Organizations are addressed in the Peppol network through defined electronic identifier schemes. The exact scheme and identifier depend on the recipient and national requirements. For German public-sector recipients, Leitweg-ID-related requirements may be relevant.
The Access Point connects a sender or receiver to the Peppol network. In a PEDIF workflow, the target Access Point or technical interface for the validated invoice output should be defined before production automation begins.
If your ERP reliably creates PDF invoices but cannot provide the structured Peppol target output you need, you do not automatically need to replace the entire source system. PEDIF can act as an additional output layer between PDF generation and your e-invoicing/Peppol process.
Useful when existing applications create stable PDFs but do not provide the required structured invoice output.
Different sites or subsidiaries can activate recurring layouts in a controlled, testable scope.
An existing EDI, portal or email flow does not automatically have to disappear. The target channel can be defined by recipient group.
Peppol is used across Europe and increasingly internationally. For cross-border invoicing, a generic “Peppol-compatible” claim is not enough. Destination country, recipient, accepted document type, national rules, tax requirements and electronic addressing all need to be checked for the specific workflow.
Recurring PDF recognition, field mapping, structured target output, technical validation and controlled handoff can be standardized within a defined scope.
Invoice profile, mandatory fields, national rules, recipient ID, network onboarding, tax and archiving requirements, and the permitted transmission method.
These terms solve different parts of the problem. Peppol mainly describes network interoperability and transmission; XRechnung and ZUGFeRD describe structured invoice formats or profiles. The right path depends on the recipient.
| Term | Purpose | Typical question | PEDIF role |
|---|---|---|---|
| Peppol | Network / exchange route | How does the structured invoice reach the recipient? | Prepare and hand off the structured output for the defined target process. |
| XRechnung | Structured e-invoice / German CIUS | Which structured invoice dataset is required? | Automate PDF to XRechnung |
| ZUGFeRD | Hybrid PDF/XML e-invoice | Should a readable PDF view be combined with structured XML? | Automate PDF to ZUGFeRD |
Check layout, mandatory data, recipient requirements, target profile, Access Point and validation path before automating the workflow.
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.
