Convert a PDF to an E-Invoice: What Works and What Doesn't

You cannot truly convert a PDF to an e-invoice. Under Section 14(1) of the German VAT Act (§ 14 UStG), an e-invoice is a structured data set that follows EN 16931, such as XRechnung or ZUGFeRD 2.0.1 or later. The invoice data has to be captured as fields: in a generator, by exporting from invoicing software, or through a service whose output you check.

This guide is for freelancers, founders and small teams in Germany who write invoices in Word, Excel or Google Docs and now get asked for "an XRechnung" or "a ZUGFeRD file". It shows, with a worked example, which data a typical PDF lacks, which of the three routes fits you, and how to tell a real ZUGFeRD file from a PDF with an XML attachment.

The symptom: the PDF looks right but is not an e-invoice

The trigger is usually a short message from a customer, an authority or your tax adviser:

Your invoice RE-2026-0042 was received as a PDF only.
Please send an e-invoice in XRechnung or ZUGFeRD format.

The natural reaction is to search for a converter: upload the PDF, download XML, done. For that to work, the converter would need to find every piece of data the target format requires. That is where it often fails, and the reason is the content of the PDF rather than the technology.

The legal position is clear. In the Federal Ministry of Finance (BMF) letter of 15 October 2025, section 14.1(2) of the VAT Application Decree (UStAE) classifies "PDF files without integrated data sets, image files or details in e-mails" as other invoices (sonstige Rechnungen), not e-invoices. For the definition and a five-question test, see What is an e-invoice?.

Why can't a PDF simply be converted?

Three causes, roughly in order of how often they appear:

1. Data is missing. A PDF shows what a human wants to read. XRechnung requires extra data that hardly any traditional invoice contains, such as a buyer reference, and codes instead of plain text.
2. Text is not a data field. A converter uses optical character recognition (OCR) and has to guess whether "19%" is a VAT rate or a discount and which number is the net amount. Every wrong guess ends up in the XML, and the XML is the invoice.
3. The issuer stays responsible. All mandatory invoice details under §§ 14 and 14a UStG must be in the structured part; a reference to an attached PDF is not enough (BMF letter of 15 October 2025, para. 35). If the converter gets something wrong, you have issued an incorrect invoice.

Worked example: what the PDF has and what XRechnung adds

Muster GmbH wrote an invoice in Word for 12 consulting hours at EUR 95 each to Beispiel AG: invoice number RE-2026-0042, EUR 1,140 net plus 19% VAT, saved as a PDF. The table compares it with the requirements of XRechnung 3.0.2 (rules from the KoSIT configuration of 31 August 2026):

A converter may manage to translate "hrs" into HUR. It cannot invent a buyer reference that appears nowhere in the PDF. Without it, validation reports BR-DE-15, and a German authority rejects the invoice. For a complete file with every field in place, see the XRechnung example.

Three routes from a PDF invoice to an e-invoice

Route 1: re-enter the invoice data

For a freelancer with a handful of invoices a month, this is the most direct route. Keep the PDF open on one screen and type the data into a form that builds an XML file or a ZUGFeRD PDF from it. Ask the customer once for the missing details, such as the buyer reference, and reuse them from then on. The step-by-step XRechnung guide walks through every field.

Route 2: export the invoice from your software

If you use invoicing or accounting software, first check whether it exports XRechnung or ZUGFeRD. Then the PDF never exists as an intermediate step. To pass validation, the buyer reference, contact details and units belong in the master data. If you work with DATEV, the DATEV e-invoice guide covers that route.

Route 3: a converter or a service provider

OCR converters read the PDF and build an XML file, which saves typing for large volumes. Legally you remain the issuer: check every generated file for amounts, VAT rate and mandatory fields before sending it. Also clarify where the provider processes your invoice data.

Is a PDF with an attached XML file already ZUGFeRD?

Not automatically. Some programs attach an XML file to any PDF. For a ZUGFeRD invoice that counts as an e-invoice, several conditions have to be met together:

The last point is often underestimated. Under section 14.4(3) UStAE the structured part leads, and if the two parts differ, the XML data prevails. If the PDF shows different invoice details, for example a different VAT amount, section 14.5(4a) UStAE says it may be a further other invoice, which has to be checked against § 14c UStG (VAT shown without being owed). Input VAT can only be deducted on the basis of the structured part.

On PDF/A errors, the FeRD FAQ says that technical errors relating to the PDF/A standard are only to be treated as warnings, although the recipient may ask for a corrected version. For profiles and versions, see What is ZUGFeRD?.

One more trap: tools that copy PDF pages lose the XML attachment. Our tool to merge PDF files copies pages only, so merging or splitting a ZUGFeRD file drops the embedded XML and the PDF/A status. Do not append delivery notes to a finished ZUGFeRD PDF this way.

How to prevent the problem for good

• Issue invoices directly in a structured format instead of creating a PDF first.
• Ask each customer once for their buyer reference; for German public bodies this is the Leitweg-ID.
• Store the seller's contact name, phone number and e-mail as fixed data.
• Validate the first invoice for every new customer before sending a series.
• Watch the deadlines: until 31 December 2026, PDF invoices remain allowed between German businesses if the recipient agrees (§ 27(38) UStG). Who may still send PDFs in 2027 is covered in Germany e-invoicing 2027.

Foreign suppliers are outside the German B2B mandate, because it applies only when both parties are established in Germany. Invoices to German public authorities follow separate public-procurement rules; check the requirements of the authority you invoice.

How to turn a PDF invoice into an e-invoice with docutools.pro

1. Open the e-invoice generator. In the "Company" step, enter the invoice number, date and due date from the PDF, plus seller and buyer. Under "Buyer reference / Leitweg-ID", enter the buyer reference (BT-10) that the PDF was missing. The country is fixed to Germany in the wizard.
2. Click "Next: line items". Enter each line with description, quantity and unit price, and choose the VAT treatment, 19% in the example. The generator supports one VAT rate per invoice and has no small-business (Kleinunternehmer, § 19 UStG) option.
3. "Review & export" takes you to "Generate & download". Choose "XRechnung XML" for public authorities or "ZUGFeRD PDF" (PDF/A-3 with an embedded factur-x.xml in the XRECHNUNG profile) for business customers. Single invoices are free and need no account; the data is sent to our server to build the file. CSV batch generation for many invoices is part of the Pro plan.
4. For a ZUGFeRD PDF, check the XML part: use the tool to extract XML from a PDF, pick the file with "Choose PDF" and save the embedded XML with "Download XML". This runs in your browser.
5. Upload the XML file to the XRechnung validator. Its "KoSIT validation" checks the way the KoSIT validator does (configuration 2026-08-31). The expected result is "KoSIT-conformant / Valid XRechnung". The free plan includes 2 uploads per day of up to 500 KB.

"Save PDF" in the generator only creates an image of the preview, not an e-invoice. Which rules the check applies is explained in the KoSIT validator guide. More practical guides are in the invoicing in Germany section.

Sources

• Section 14 UStG, issuing invoices (gesetze-im-internet.de, German) (opens in a new tab)
• Section 27 UStG, transitional provisions (gesetze-im-internet.de, German) (opens in a new tab)
• BMF letter of 15 October 2025 on mandatory e-invoicing (German) (opens in a new tab), para. 35 and sections 14.1, 14.4 and 14.5 UStAE
• FeRD: frequently asked questions on ZUGFeRD/Factur-X (opens in a new tab)
• KoSIT: XRechnung validator configuration (GitHub) (opens in a new tab)

Last reviewed: October 2026

This article is general information, not tax or legal advice.