E-Invoice Viewer

Why I built this

The first XRechnung I got by email was a single .xml file. No PDF, no letterhead, just a few hundred lines of tags. Double-clicking it opened Edge, which showed me a wall of angle brackets, and somewhere in there was the amount I owed. I could find it, but I wouldn't call that reading an invoice.

That's the reality for a lot of small businesses now. Germany has required businesses to be able to receive e-invoices since January 2025, and France started its rollout in September 2026. Most accounting software handles it fine. But freelancers, small shops and anyone checking an invoice outside their accounting tool keep hitting the same wall: they've got a valid e-invoice and no way to look at it.

The viewers I found before building this one were mostly sign-up pages for invoicing software. Some wanted an account, some had a monthly cap on free views, and nearly all of them uploaded the file to their server. That's a strange thing to ask for a document full of bank details, VAT numbers and prices you agreed with a supplier. So this one runs entirely in your browser.

What it opens

There are really only two XML syntaxes behind all the national names, and the viewer reads both:

• UN/CEFACT CII, used by ZUGFeRD 2.x, Factur-X and the CII flavour of XRechnung.
• UBL 2.1, used by Peppol BIS Billing 3.0 and the UBL flavour of XRechnung. Both invoices and credit notes work.

ZUGFeRD and Factur-X invoices usually arrive as a PDF that looks perfectly normal. The machine-readable part is a file called factur-x.xml or zugferd-invoice.xml embedded inside the PDF/A-3. When you drop one of those PDFs here, the viewer digs that XML out, shows it to you, and lets you download it on its own. That's handy when your bookkeeping software wants the XML and your supplier only sent the PDF.

The badge at the top tells you what you're looking at: the syntax, the profile (XRechnung 3.0, Factur-X EN 16931, BASIC, MINIMUM, Peppol and so on), and whether the XML came from a PDF.

How to use it

For long-term archiving, print the invoice to PDF here and then convert it to PDF/A so it stays readable for years.

1. Drop the file onto the box or click to pick it. .xml and .pdf both work.
2. Click View Invoice.
3. Read it. Seller and buyer sit side by side, then the invoice lines, the VAT breakdown, the totals and the payment details with IBAN and payment reference.
4. Print it or save it as a PDF if you need a paper copy for your records or for a colleague who doesn't want to deal with XML.

If you want to see the raw XML, there's a button for that too. Sometimes a field isn't shown in the layout, and it's quicker to search the source than to guess.

What the checks actually check

Above the invoice you'll see a green or amber box. It recalculates the numbers the invoice states about itself:

• Do the line amounts add up to the line total?
• Does line total minus discounts plus surcharges match the net total?
• Does every VAT row match its taxable amount times its rate, within a cent?
• Do the VAT rows add up to the VAT total and the net total?
• Is net plus VAT the gross total, and is gross minus anything prepaid the amount due?
• For each line, does quantity times price give the line amount?

When something's off, the box tells you which check failed and shows both numbers. In my experience the usual culprit is a rounding difference on the VAT, or a discount that was applied in the PDF but never made it into the XML.

I want to be clear about the limits, though. This is arithmetic, not a formal validation. The official XRechnung validator from KoSIT runs hundreds of schematron rules: mandatory fields, code lists, the format of the Leitweg-ID. If an invoice gets rejected by a public authority's portal, that's the tool you need. What this viewer answers is the more everyday question: what does this invoice say, and do the numbers make sense?

Where the odd fields end up

E-invoices carry a few fields that paper invoices rarely show. The Leitweg-ID, which German public bodies use to route incoming invoices, is stored as the buyer reference, so you'll find it in the header right under the dates. VAT categories come as one or two letter codes; S is the standard rate, AE is reverse charge, K is an intra-EU supply. The viewer spells those out for you. Units are codes too: HUR means hours, C62 means pieces, LS is a flat rate. Anything the layout doesn't cover is still in the raw XML view.

A few real situations

Want to pay faster? Copy the IBAN, amount and reference into the EPC QR code generator and scan the result with your banking app.

You're a freelancer and a supplier sent an XRechnung. Your bank app doesn't care about XML. You need the amount, the IBAN, the due date and the reference. Open it here, copy what you need, done.

You run a small business in France and your first Factur-X arrived. The PDF looks fine, but your accountant asks whether the XML inside matches it. Drop the PDF in and compare. If the totals in the XML differ from the printed ones, you've caught a problem before it reaches your books.

You're a developer generating e-invoices. You want a quick look at what your code produced, without spinning up a validator. The checks catch the classic mistakes like VAT rounded per line instead of per rate, or a missing allowance total.

You're archiving. Some bookkeepers like a human-readable PDF next to each XML. Print to PDF from the viewer and you've got one.

Privacy, because these are invoices

The file is read with your browser's own APIs. Nothing is uploaded to the server, and nothing is stored. Close the tab and it's gone. You can check this yourself: load the page, switch off your Wi-Fi and open an invoice. It still works.

The viewer also refuses XML files that contain DOCTYPE or entity declarations. Genuine e-invoices never use them, and refusing them shuts out a whole class of malicious XML tricks.

What it won't do

If you're on the other side and need to send a plain invoice of your own, the invoice generator builds one in a couple of minutes.

It doesn't validate against the full EN 16931 rule set, as mentioned. It doesn't open the old ZUGFeRD 1.0 format, which has been obsolete for years now. It won't read a PDF that only contains a scanned picture of an invoice, because there's no XML in it to read. And it won't create e-invoices, only display them.

If you need something it doesn't do yet, there's a feedback link on the page. I read those.