PEDIF converts recurring PDF invoices from ERP, billing and legacy systems into structured, validated XRechnung data. Keep your existing invoice process while PEDIF adds XRechnung output, validation and handoff to the required target workflow.
Not "upload a PDF and hope", but a defined workflow for recognition, structure, validation and controlled handoff.
Your ERP, billing or specialist application continues generating the familiar PDF invoice.
PEDIF processes recurring invoice layouts configured and tested for automation, including header, line-item, tax, total and reference data.
The identified invoice data is mapped into the structured fields required for the agreed XRechnung output.
The generated output is checked for format, mandatory fields, calculations and agreed recipient/process rules before release.
The validated XRechnung is passed to the agreed ERP, EDI, portal, interface or transmission workflow.
E-Invoice is the broader category for structured electronic invoices. XRechnung is a German structured invoice specification based on EN 16931. A recipient may specifically require XRechnung, while another workflow may use a suitable ZUGFeRD/Factur-X profile or another compliant structured format. PEDIF first clarifies the required format, recipient requirements, validation rules and transmission process before the PDF workflow is automated.
Missing mandatory data cannot be invented by conversion. It must come from the PDF, the source system or another reliable data source. Typical data includes:
OCR can read visible characters, but XRechnung needs their business meaning. A value such as 1,250.00 may be a unit price, net total, tax amount or gross total. A date may mean invoice date, delivery date, service date or due date.
PEDIF therefore combines document recognition with field logic, mapping rules, validation and exception handling instead of treating the PDF as plain text.
The Leitweg-ID is primarily used to identify and address invoice recipients in German public administration and route an e-invoice to the responsible downstream authority system. It is particularly relevant in workflows for the German federal administration.
Not every B2B XRechnung automatically requires a Leitweg-ID. The exact requirement depends on the recipient, transmission route and process rules. Before conversion, the target workflow therefore needs to define which recipient references are mandatory.
technical format and structure
required version/profile
mandatory invoice fields
mathematical consistency and totals
tax logic
buyer, seller, order and contract references
recipient-specific requirements
exception handling before release
For a single invoice, a manual online converter may be enough. If your systems generate tens, hundreds or thousands of recurring PDFs, the real question is different: how do you turn conversion into a repeatable, controlled workflow?
A typical flow is: upload PDF, review extracted fields, add missing information and download XML. For occasional invoices, this can be the simplest and most economical option.
Single or rare invoices
Manual review for each document
Download as the endpoint
Relevant when ERP, billing or specialist systems continuously generate PDFs and a defined structured target output is required.
Recurring approved layouts
Defined field and validation rules
Validation before handoff
Review path for exceptions
Handoff to ERP, EDI, portal, interface or other target process
If your ERP, billing or legacy application reliably creates PDF invoices but cannot generate the required XRechnung output, you do not necessarily need to replace the source system.
PEDIF can add a structured output layer to the existing process: the PDF remains the familiar source document, relevant invoice data is mapped into XRechnung, the result is validated and the structured output is passed to the agreed downstream process.
This is particularly relevant for legacy applications, subsidiaries, specialist billing systems and EDI exceptions that continue to produce recurring PDFs.
ERP reliably creates PDF, but not the required XRechnung output
Multiple invoice sources or subsidiaries
Existing EDI does not cover every partner or exception
Customers require different formats and references
Finance wants to avoid manual re-entry
IT wants to avoid an unnecessary migration project
The right choice depends on the recipient, B2B/B2G context, required profile/version, target systems, submission route and human-readability needs.
A structured XML-based invoice standard. It is especially relevant where the recipient explicitly requires XRechnung, public-sector rules apply, or the target process expects a pure structured dataset.
A hybrid format that combines a readable PDF/A-3 representation with embedded structured XML invoice data. It can be useful when people still need a familiar invoice view while systems also need structured data.
Generating an XRechnung file is only part of the job. The invoice also has to match the current specification, reach the right portal or recipient and pass validation there. The following sections explain what matters in day-to-day operation.
XRechnung is the German specification for electronic invoices based on the European standard EN 16931. It defines which fields are mandatory, which codes may be used and which additional German rules apply. The specification is maintained by the Coordination Office for IT Standards (KoSIT) and is updated in regular releases.
An XRechnung can be written in two XML syntaxes: UBL and UN/CEFACT CII. Both carry the same business content. Which syntax is used usually depends on the recipient's platform or on what the sender's processes already support.
Public-sector clients in Germany receive e-invoices through dedicated channels. At federal level these are the central invoice receipt platforms; many federal states and municipalities operate their own portals. Depending on the recipient, invoices are uploaded, sent via the Peppol network or, in some cases, transmitted by email.
For a supplier with several public-sector customers, this means different delivery routes for the same type of invoice. PEDIF prepares the validated XRechnung and hands it to the delivery route agreed for each recipient, so the billing system does not need a separate export for every portal.
The Leitweg-ID identifies the receiving public authority and is required by most public-sector recipients. It is issued by the authority itself and is usually communicated with the order or contract. In the XRechnung it is carried in the buyer reference field.
Many PDF invoices do not print the Leitweg-ID, because it was never needed on paper. In such cases PEDIF can add it from rules or master data, for example as a fixed value per customer or derived from a contract number on the invoice. If no valid Leitweg-ID can be determined, the invoice is routed for review instead of being sent without it.
XRechnung is best known from the public sector, but it is also a valid e-invoice format between companies under the German e-invoicing rules. Some business customers ask for XRechnung because their accounting systems already process it. Others prefer ZUGFeRD, because it keeps a readable PDF view. PEDIF can produce either format from the same recurring PDF invoice, depending on what each recipient requires.
An XRechnung is checked on two levels. The XML must match the schema of the chosen syntax, and the content must comply with the business rules of EN 16931 and the additional German rules of XRechnung. Public-sector portals typically run these checks on receipt and reject invoices that fail them.
PEDIF runs the validation before the invoice leaves your process. Invoices with findings are held back with a clear message, so they can be corrected before they reach the portal.
Credit notes and corrected invoices also have to be issued as XRechnung where the recipient requires it. A credit note is marked with its own document type, and a corrected invoice should refer to the invoice it replaces. Because these documents often come from the same billing system as regular invoices but with slightly different layouts, PEDIF handles them as separate cases with their own recognition, mapping and validation.
An XRechnung is a pure XML file without a visual layout. Accounting systems process it directly, but people who need to check or approve an invoice usually need a readable view. Many receiving systems generate one automatically. Where that is not the case, structured files can be turned into a readable PDF, for example with X to PDF, without changing the XRechnung itself.
E-invoices have to be stored in the format in which they were issued or received and must remain unchanged for the statutory retention period. For XRechnung this means archiving the XML file itself; a printout or a generated PDF view is not enough on its own. Because the invoice data is structured, archive systems can index XRechnungen by invoice number, date, recipient or amount, which makes later searches and audits easier.
Fit check, not a blanket promise
Show PEDIF representative PDF invoices and the intended target workflow. The important factors are recurring layout, available mandatory data, recipient requirements, validation and the desired downstream handoff.
Check your e-invoice gapQuestions, 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.
