Converting a PDF to XRechnung: what actually works
Pick a PDF: the tool shows whether it already carries invoice XML and lets you download it. If not, the way forward is the invoice creator.
This PDF is
Not an e-invoice
Without embedded XML the PDF is just a picture of the invoice, an ordinary invoice under section 14(1) UStG.
| Embedded files | none |
| PDF/A | – |
| Profile | – |
Example with made-up data
Prepared by Radif Partners · Method · VAT Act, ministry letters and XRechnung 3.0.2 checked on 25 October 2026
An ordinary PDF cannot be converted into an XRechnung reliably, because it only holds a picture of an invoice and no data fields. Under section 14(1) of the German VAT Act an e-invoice must come in a structured format under the standard EN 16931, and every value in it must be correct and complete: invoice number, date, addresses, VAT rates, net and tax amounts. Text recognition reads those values from the image but mixes up columns, decimal separators and VAT rates, and you as the issuer are liable for the mistake. ZUGFeRD is different: this PDF/A-3 already carries the XML as an embedded file, and from version 2.0.1 and the BASIC profile upwards it is an e-invoice. The tool above opens your PDF in the browser, looks for factur-x.xml or xrechnung.xml and offers the file for download. If it finds no XML, recreate the invoice with the creator; for an invoice with a few lines that takes about five minutes and gives you a checked file. Until 31 December 2026 a PDF stays allowed with the customer's consent.
Two kinds of PDF
For invoices, the .pdf extension hides two very different things. The first kind is produced when a word processor or accounting program prints the invoice to a page: letters and lines at fixed positions, easy for people to read, but for software just a graphic with text. The second kind is a hybrid invoice under ZUGFeRD: a PDF/A-3 that also holds an XML file with all the invoice data. The page shows the invoice, the XML supplies the values for accounting.
Only the second kind is an e-invoice under section 14(1) UStG, and only if the XML meets EN 16931. According to the German e-invoicing forum FeRD, that holds from ZUGFeRD 2.0.1 for the BASIC, EN 16931, EXTENDED and XRECHNUNG profiles. The current version is 2.5.2.
| Kind of PDF | Holds XML | E-invoice | What to do |
|---|---|---|---|
| Printed from Word or accounting software | no | no | create the invoice again |
| Scan or photo | no | no | create the invoice again |
| ZUGFeRD MINIMUM or BASIC WL | yes, incomplete | no | regenerate with BASIC or higher |
| ZUGFeRD BASIC, EN 16931, EXTENDED | yes | yes | extract the XML if needed |
| ZUGFeRD XRECHNUNG | yes | yes | XML matches an XRechnung (CII) |
Why text recognition is no answer
Services that turn any PDF into an XRechnung rely on text recognition and mapping rules. With neatly laid-out invoices that often works, but not always. Typical errors are swapped columns for quantity and unit price, a decimal point read as a thousands separator, a VAT rate attached to the wrong line, or an address whose postcode ends up in the city field. The resulting XML is formally valid and wrong in substance.
That is more than a cosmetic flaw. The XML is the original of the e-invoice, and what it says is what counts. If the VAT amount is wrong, the VAT Act still makes you owe the amount shown, and your customer can deduct input VAT only from a correct invoice. The Finance Ministry letter of 15 October 2025 states that where the picture and the data of a hybrid invoice differ, the XML prevails. Anyone converting must therefore check every figure, at which point recreating the invoice is hardly slower.
How the tool works
You pick a PDF or drop it on the field. The browser reads the file, searches the PDF catalogue for embedded files and reports what it finds: no file, a factur-x.xml, an xrechnung.xml or other attachments. If invoice XML is present, the tool identifies the standard, profile and version, shows the invoice in readable form and offers the XML for download. If none is present, it says so plainly and points to the invoice creator.
Check first how your file is classified in law:
E-invoice under section 14 UStG?
E-invoice under section 14 UStG?
No
| Usable for domestic B2B from 2027/2028 | No |
| Receipt since 2025 | Only with your consent |
| To read it | Ordinary software |
Recreate rather than convert
For an invoice that exists only as an ordinary PDF, the cleanest route is to create it again from the same data. The creator asks for seller, buyer, invoice details, line items and bank details, works out net, VAT and gross itself and blocks the download while mandatory details are missing. The result is either a ZUGFeRD PDF that looks like your old invoice and carries the XML, or an XRechnung as pure XML. Reuse the same invoice number only if the old PDF was never sent; otherwise the rules on invoice corrections apply.
If you need the opposite, turning an XRechnung into a readable PDF, see XRechnung to PDF. What makes ZUGFeRD a format of its own is explained on ZUGFeRD, and you check the actual file before sending with the XRechnung validator.