How do I open an XRechnung file?

An XRechnung is a pure XML e-invoice, so PDF viewers and Office programs cannot display it. The practical way to read one is to render it: upload the .xml file to a free browser tool such as the InvoiceXML XRechnung preview and you get a clean, readable invoice on screen in seconds, with a one-click PDF download. No installation and no account are required, and the file is processed in memory only.

How do I convert XRechnung to PDF?

POST the XML file to the InvoiceXML endpoint POST /v1/render/xrechnung/to/pdf. The API parses the invoice, maps every EN 16931 business term to a standard layout, and returns a formatted PDF as the response body. Both XRechnung syntaxes (UBL and CII) and all XRechnung versions are supported, and an optional language field switches the field labels between English, German, and French.

Is the rendered PDF legally valid?

No. Under the German e-invoicing rules the structured XML is the invoice; any PDF made from it is a readable copy with no legal standing. Archive the original XRechnung XML file and treat the PDF as a working copy for review, approval, and audit annotations.

Can I display an XRechnung inside my own application instead of as a PDF?

Yes. POST the same file to /v1/extract/json and you receive every invoice field as structured JSON: seller, buyer, line items, totals, VAT breakdown, payment details, and references. Render that data in your own approval screen, supplier portal, or archive UI in whatever layout you like; the PDF route and the JSON route read the file identically.

Does this work for both UBL and CII XRechnung files?

Yes. XRechnung allows two XML syntaxes, UBL and CII, and the renderer detects which one you uploaded from the root element. You never need to know or declare the syntax, and both produce the same PDF layout.

Is my invoice data stored when I render it?

No. Files are processed entirely in memory and discarded as soon as the PDF or JSON response is returned. Nothing is written to disk, logged, or retained.

How to Open an XRechnung File and Read It as a PDF

The email says "please find our invoice attached", and the attachment is a file called rechnung.xml. Double-clicking it opens a browser tab full of angle brackets, or a text editor showing several hundred lines of code. Nothing on an ordinary office PC turns it into something a human can approve, book, or file. If that is the situation that brought you here, the short version is: the file is an XRechnung, it is supposed to look like that, and you can have it on screen as a normal, readable invoice in under a minute. This guide covers the one-off case, the every-day case, and the case where you want the invoice displayed inside your own software.

What you actually received

XRechnung is Germany's official e-invoice standard for the public sector, and increasingly common in B2B exchanges too. It is a national profile of the European e-invoicing norm EN 16931, maintained by KoSIT, and it is deliberately data without a document: every invoice field (seller, buyer, line items, VAT breakdown, payment terms, the Leitweg-ID routing reference) is present in structured, machine-readable form, and there is no visual layer at all. No layout, no logo, no page. The XML file itself is the invoice.

You will typically receive one because a business relationship touches the German public sector: you supply an authority and get your own submissions echoed back, you sit in an accounts payable team whose suppliers have switched to e-invoicing, or your document management system archives whatever the invoice inbox receives. Since Germany's B2B e-invoicing rules began phasing in, plain-XML invoices also arrive between ordinary companies, and the same applies to them: the XML is the legal original.

Two sibling formats are worth telling apart. A ZUGFeRD or Factur-X invoice is a PDF with the XML embedded inside it, so it opens in any PDF viewer. An XRechnung has no PDF wrapper. If your file ends in .xml, this guide is for you; if it ends in .pdf and will not book automatically, you are probably holding a hybrid and want the extraction tools instead.

Why nothing on your PC opens it

Standard software fails on an XRechnung for a simple reason: there is nothing to display. A PDF viewer renders pages, and the file has none. Excel can technically import XML, but the deeply nested invoice structure does not map to rows and columns, so what comes out is unusable. Browsers show the raw markup. Even reading the XML by eye is harder than it sounds, because the fields carry standardized technical names (cbc:ID, ram:SellerTradeParty, BT-115-style business terms) rather than labels like "invoice number" or "amount due".

This is not an oversight. The format optimizes for machine processing: an ERP can book an XRechnung without OCR, without guessing, and without a human retyping numbers. The human-readable view was intentionally left to tooling, and that tooling is what the rest of this guide is about. Specialised desktop software exists, but it requires installation and technical setup; a browser tool or an API call gets you there faster.

Fastest: read it in the browser

For a single file, use the free XRechnung preview tool: drag the .xml file onto the page and the invoice appears as a clean, readable preview, with one click to download the same invoice as a PDF. No installation, no account, and the file is processed in memory only, nothing is retained after the response.

Open the XRechnung preview tool API documentation

The tool accepts every XRechnung version, current 3.x files as well as older 1.x and 2.x documents, in both of the format's XML syntaxes (UBL and CII). You do not need to know which one you have; the renderer detects it from the file.

Recurring files: render to PDF via API

If XRechnung files arrive every week, dragging each one into a browser stops being a workflow. The same rendering engine is available as a REST endpoint, so your invoice inbox, DMS, or AP system can attach a readable PDF to every incoming XML automatically:

curl -X POST https://api.invoicexml.com/v1/render/xrechnung/to/pdf \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]" \
  --output rechnung-preview.pdf

The response body is the finished PDF. An optional language form field (en, de, fr) sets the field labels and date formatting of the layout; the invoice content itself is rendered exactly as the XML carries it and is never translated. A common pattern in AP teams: store the PDF next to the XML in the document archive the moment the invoice arrives, so approvers and auditors always have a readable copy one click away while the XML remains the document of record.

Credit notes get the same treatment. A UBL CreditNote document, or an invoice with the credit note type code, renders with credit note labelling so nobody books a credit as a payable.

What the rendered PDF shows

The preview is built from the structured data, not from any existing layout, and its job is completeness: everything the XML carries appears on the page. That includes the standard invoice body (parties, line items with quantities and unit prices, VAT breakdown per rate, totals, payment terms and bank details) and a dedicated "Electronic invoice details" section for the fields unique to e-invoicing: the specification identifier, buyer reference / Leitweg-ID, party identifiers and electronic addresses, line-level references, and listed attachments. For an accounts payable reviewer, that last section is often the point: it shows exactly what the machine-readable layer claims, which is what your ERP will actually book.

Attachments inside the XML

An XRechnung can carry supporting documents embedded inside the XML itself: timesheets, delivery notes, or the supplier's own PDF rendering, base64-encoded in the invoice (BG-24 in the standard). The rendered preview lists them by file name so you can see they exist, and the attachment extraction endpoint (POST /v1/extract/attachments) unpacks them: upload the same XML and you get the embedded files back as a ZIP, exactly as the sender encoded them. Documents that are only referenced by an external link are deliberately not fetched.

Show it in your own software instead

A PDF is the right answer when a person needs a document. When you are building the screen the person looks at (a supplier portal, an approval workflow, an archive viewer) you usually want the invoice data itself, laid out your way. That is one call to POST /v1/extract/json: upload the same XRechnung file and every field comes back as structured JSON.

Try extraction online API documentation

{
  "invoice": {
    "invoiceNumber": "RE-2026-00815",
    "issueDate": "2026-09-12",
    "dueDate": "2026-10-12",
    "currency": "EUR",
    "buyerReference": "04011000-12345-67",
    "seller": { "name": "Musterlieferant GmbH", "vatIdentifier": "DE123456789" },
    "buyer": { "name": "Stadt Beispielhausen" },
    "totals": {
      "taxBasisTotalAmount": 4250.00,
      "taxTotalAmount": 807.50,
      "duePayableAmount": 5057.50
    },
    "lines": [ { "lineId": "1", "quantity": 10, "lineNetAmount": 4250.00 } ]
  }
}

The response mirrors the EN 16931 business terms with readable property names, so an approval screen, a dashboard tile, or a search index over your invoice archive is a rendering exercise in your own stack, not an XML parsing project. Extraction is deterministic: the JSON is read from the structured XML, no AI involved, so the numbers are the numbers. Rendering to PDF and extracting to JSON read the file identically; many integrations use both, the JSON for the workflow and the PDF for the humans.

Keep the XML: the PDF is a copy

One rule keeps you out of trouble: the XML file is the invoice, everything derived from it is a copy. The rendered PDF has no legal standing; German requirements attach to the structured data. Archive the original XML for the statutory retention period, and treat the PDF as a convenience for review, approval, and audit annotations. Storing both side by side, with the PDF clearly derived, is the pattern auditors respond well to. Rendering is also not validation: a file that renders beautifully may still violate the KoSIT business rules, and a compliance verdict comes from the XRechnung validation endpoint, not the preview.

Senders: check before you submit

The same tooling closes the loop on the sending side. If you generate XRechnung files for a public sector client, previewing the file before submission is the fastest way to catch a wrong total, a missing bank account, or a service period that did not make it into the XML; humans spot these in a rendered invoice far quicker than in raw markup. Pair the preview with a validation call against the official KoSIT rules and you know the file is both correct and compliant before the buyer's portal sees it. If you need to produce the files in the first place, the XRechnung API toolkit guide covers the full lifecycle.

Get started

For a single file, the browser preview needs nothing but the file. For automation, create a free InvoiceXML account → and get 100 credits for free, no credit card required; the curl call above is the whole integration.

Related resources:

InvoiceXML is a REST API for European e-invoice compliance covering XRechnung, ZUGFeRD, Factur-X, Peppol UBL, and CII. Stateless processing, GDPR compliant by architecture, and callable from any stack in minutes.