Free E-Invoice Viewer (XRechnung, ZUGFeRD, Factur-X)

Worked example

Press "Try a sample XRechnung" to open a made-up XRechnung 3.0 invoice. The page shows "Invoice RE-2026-0417", issued Oct 28, 2026 and due Nov 27, 2026, with an amount due of €2,215.26. The three lines add up to €1,866.50. The VAT breakdown has €345.33 on €1,817.50 at 19 % and €3.43 on €49.00 at 7 %, so €348.76 in all, and 1,866.50 + 348.76 = 2,215.26. The banner says "The amounts add up.", the IBAN DE89 3704 0044 0532 0130 00 is marked "valid", and a payment QR code appears next to it.

Which settings to use, and the limits

• Drop the XML, or the whole ZUGFeRD or Factur-X PDF. The page opens one file at a time: an .xml e-invoice or a .pdf. It reads invoices in UBL (XRechnung, Peppol BIS Billing 3.0, Turkish e-Fatura and e-Arşiv in UBL-TR) and in UN/CEFACT CII (XRechnung CII, ZUGFeRD 2.x, Factur-X), including credit notes. The badge beside the title names the standard it recognised, such as "XRechnung 3.0". Files over 50 MB are refused with "This file is larger than 50 MB, which is far more than an e-invoice. Check that it is the right file."
• A PDF is read for the XML attached inside it. A ZUGFeRD or Factur-X PDF carries the invoice data as an attached XML file. The page lists the files attached to the PDF and prefers an attachment named factur-x.xml, then zugferd-invoice.xml, xrechnung.xml or order-x.xml, and otherwise takes the first file ending in .xml. The chip then reads "XML from the PDF: factur-x.xml", and "Download XML" saves that file. What you see is the data in the XML, not the picture printed on the PDF page.
• Read the banner that says whether the amounts add up. Above the parties the page checks the invoice's own arithmetic: the lines against "Sum of lines", "Total without VAT" (lines minus allowances plus charges), the VAT breakdown against the VAT total, "Total with VAT", and "Amount due" (total minus "Already paid" plus rounding), plus the IBAN's check digits. A difference of one cent is accepted, and on long invoices one cent per ten lines for the line sum. A check is skipped when the file leaves out a figure it needs. This is not the official EN 16931 or XRechnung rule check, and an invoice that passes can still be rejected by a public portal.
• Use the QR code only for a bill you owe. For an invoice in euros with a valid IBAN and an amount above zero, the page draws an EPC QR code (GiroCode) that banking apps can scan to fill in payee, IBAN, amount and reference. The reference is a structured creditor reference (RF...) when it passes its check, otherwise the payment reference or the invoice number. No code is drawn for a credit note, other currencies, direct debit (payment method 49 or 59, or a debited account), a missing or invalid IBAN, or an amount of zero or less. Always check the details in your banking app before you confirm.
• Print, save or export what you need. "Print / save as PDF" opens your print dialog; choose "Save as PDF" as the printer. If nothing happens, the page shows a "Printing did not start" message and suggests "Download as HTML", which you can open and print from there. "Download as HTML" saves a self-contained page named after the invoice number, and "Lines as CSV" saves the line items separated by semicolons with a UTF-8 byte-order mark. The CSV columns are line, item_id, name, description, quantity, unit, unit_price, net_amount, vat_rate and vat_category, with amounts written as in the XML (a dot as decimal separator).
• Dates and amounts follow the page language. Dates, amounts and country names are shown in the language of the page and in the invoice's own currency, so the same file reads "Oct 28, 2026" and "€2,215.26" here. Units and VAT categories use plain words when the code is a common one (C62 shows as "pcs", S as "standard rate") and the raw code otherwise. Fields the file leaves empty are simply not shown. Embedded attachments get a "Download" button, linked ones show only the address, and the "XML source" panel shows the first 400,000 characters of the file.

Common problems and how to fix them

It says "This XML is not an invoice in UBL or CII format. Open an XRechnung, ZUGFeRD, Factur-X, Peppol or e-Fatura file."

The file is well-formed XML but its main element is not an Invoice, a CreditNote or a CrossIndustryInvoice. That is the case for other XML such as an order, a despatch advice, a portal receipt or response, or an Italian FatturaPA or other national format. The page also finds an invoice wrapped inside an envelope, but only a few levels deep. Open the invoice file itself, not a message about it.

It says "This file is not well-formed XML, so it cannot be read. It may be damaged or cut off."

The file does not parse as XML. Typical causes are a download that stopped early, a file edited by hand with a missing closing tag, or an HTML page (such as a portal login or error page) saved with an .xml name. Open it in a text editor: a real e-invoice starts with <?xml or with an Invoice or CrossIndustryInvoice tag. Download it again from the sender's portal or email.

It says "This PDF has no invoice XML attached, so it is an ordinary PDF rather than a ZUGFeRD or Factur-X invoice. Open it in a PDF reader instead."

Most invoice PDFs are only a picture of an invoice, with no data inside. Only ZUGFeRD and Factur-X PDFs carry an attached XML file. Look in the email or portal for a separate .xml file from the supplier and drop that instead, or ask the supplier for a ZUGFeRD or Factur-X version. The same message appears when the PDF has attachments but none of them ends in .xml.

It says "This PDF could not be opened. It may be damaged or password-protected."

The PDF reader inside the page could not open the file, which happens with damaged files and with PDFs that need a password. Remove the password in the program that created the PDF, or download the file again, then drop it again. If the supplier also sent the XML as a separate file, you can open that directly.

It says "Some amounts do not add up:" or "The IBAN is not valid: its check digits do not match."

The page lists each figure that does not match, with what it worked out and what the invoice states, for example "Amount due should be €2,215.26 (total minus prepaid plus rounding), but the invoice states €2,215.62." The page only reads and adds up what the file contains, so the mismatch is in the invoice itself. Contact the sender before paying, and for a wrong IBAN confirm the account number with them by another route. No QR code is drawn while the IBAN is flagged.

How it compares

A full e-invoice validator checks every EN 16931 and XRechnung business rule and tells you if a portal will accept the file. This page does not: it reads the fields, shows them as a normal invoice and adds up the amounts, so it is for reading and checking an invoice you received, not for proving one you send is compliant. Your accounting software can import the data directly, which is better for booking it, but this page needs no account or setup and reads the file in the browser. It does not verify signatures, send or receive invoices, or edit them. The XML file remains the legal invoice, and the printed copy says so.