Which e-invoice format do you actually have?

Start with the extension

.xml    could be any of five formats — the root element decides
.pdf    might be a plain PDF, or a hybrid with the XML inside
.p7m    Italian: a signed CAdES envelope wrapping FatturaPA XML
.xsig   Spanish: Facturae XML with the XAdES signature inside it
.zip    Romanian SPV, Polish KSeF, monthly downloads — often nested
.eml    an email; the invoice is an attachment inside it
.msg    the same, in Outlook's own format

Two of these routinely defeat a double-click. A .p7m is a cryptographic container, not a document — the operating system has nothing to open it with. A .xsig is a normal XML that some viewers refuse because of the signature branch inside.

If it is XML, the first tag tells you everything

Open it in any text editor and look for the root element:

<Invoice> / <CreditNote>      UBL 2.1 — Peppol BIS, XRechnung, e-Factura, eRačun
<CrossIndustryInvoice>        UN/CEFACT CII — Factur-X, ZUGFeRD, XRechnung (CII)
<FatturaElettronica…>         Italy, FatturaPA
<Facturae>                    Spain, Facturae 3.2.x
<Faktura>                     Poland, KSeF FA(2) or FA(3)

The first two are the European norm EN 16931 in its two permitted syntaxes, and this is where most confusion comes from: XRechnung, Peppol BIS, Romanian e-Factura and Croatian eRačun are not different formats. They are the same norm with national restrictions layered on top — which is why one reader can handle all of them, and why a validator written for one country will still complain about another country's perfectly valid file.

FatturaPA, Facturae and KSeF are genuinely different. They have their own field names, their own totals arithmetic, and no EN 16931 semantics at all — a UBL reader gets literally nothing out of them.

The PDF that is secretly two documents

Factur-X (France) and ZUGFeRD (Germany) are the same thing under two names: an ordinary PDF/A with an XML file attached inside it. What you see is a page; what your accounting system reads is the attachment.

They can disagree. German tax guidance settled this in 2025: the structured part is the leading one, and if the image part shows something materially different, that difference is not a cosmetic problem — it can make the visible part a separate invoice with its own VAT consequences. So a reader that only shows you the picture is showing you the part that does not govern.

To check by hand: open the PDF in a reader that lists attachments and look for factur-x.xml, zugferd-invoice.xml or xrechnung.xml. If it is there, you have a hybrid.

Why Excel cannot just open it

Excel does have an XML import, and it looks like it works. Then the repeated structures — invoice lines, VAT subtotals, allowances — get flattened into one sheet, and a two-line invoice with two VAT rates comes out as four rows. The totals are still in there somewhere, multiplied.

There is a second trap that is quieter. Invoice XML carries both the stated totals and the pieces they are made of, and those are allowed to differ slightly: rounding is applied per line in some formats and per document in others. A converter that recomputes from unit prices produces numbers that are almost right — which is worse than obviously wrong, because nobody checks them.

What a correct conversion has to get right, and what is done here:

Amounts read from the document's own totals, never recomputed
Credit notes negative, with a reference to the invoice they correct
VAT split by rate and category, not lumped into one number
National arithmetic honoured — Italian withholding and stamp duty, Spanish IRPF — so correct invoices are not flagged as broken
Self-billed and buyer-issued document types marked, so they are not booked twice

Drag the whole folder

Mixed folders are the normal case: a Factur-X PDF from a French supplier, a .p7m from an Italian one, a Peppol UBL from a Dutch one, and a ZIP from the Romanian tax portal. All of it goes in at once, and out comes one table with one row per invoice and the same columns throughout.

ZIP archives unpack themselves, including archives inside archives, which is how monthly downloads usually arrive. Emails are opened and their attachments taken out. Tax-authority receipts — Italian SdI notifications, Polish KSeF UPO — are recognised as receipts and attached to the invoice they belong to, rather than counted as extra documents.

Nothing is uploaded

The files are read in your browser. Not "transmitted securely" — not transmitted at all, and you can check: open the Network tab and drop an invoice. No request leaves. After the first load the page works offline too.

For an accounting firm that means client data never reaches a third party — not because we promise it, but because there is nowhere for it to go.

Try it

Drop files on the main page — up to 10 invoices per export and 20 a day, free, no account. To inspect a single file against EN 16931 there is the check page, and if you are building software that reads these files, the developers page.