Read, with the country's own format
These countries have a national format that is not EN 16931. Each one is recognised by what is inside the file, not by its extension or its name.
- Argentina — AFIP invoice QR (RG 4892). The structured file goes to AFIP, not to you; the printed QR carries the total but never the net or the VAT, and the number only means something together with the point of sale.
- Austria — ebInterface 4.x–6.x. Its root element is also called
Invoice, so a reader that goes by name produces a blank row and no error. - Brazil — NF-e / NFC-e 4.00 (SEFAZ). ICMS is inside the price, so a European reading marks every Brazilian invoice as out of balance; and a cancelled NF-e is byte-for-byte as plausible as a valid one until you read cStat.
- Chile — DTE 33/34/56/61 (SII). Folios run per document type, so invoice 1842 and credit note 1842 both exist; and the exempt amount is part of the net, or every mixed document looks out of balance.
- Colombia — DIAN 2.1 (UBL). Fields sit where EN 16931 puts them, so it reads — except the CUFE, which lives in cbc:UUID and is the only identifier DIAN answers to.
- Czechia — ISDOC 6.x (.isdoc / .isdocx). A Czech bank statement matches on the variabilní symbol, not the invoice number.
- Egypt — ETA e-invoice (JSON). The currency is only on the lines, never on the document; netAmount is after the discount and totalSalesAmount before it; and T1 is VAT while T4 is withholding.
- Finland — Finvoice 3.0. Dates are CCYYMMDD, and the standard rate has been 25.5% since 2024.
- Greece — myDATA (AADE). The VAT rate is a code — 24% is written
1— and the EU prefix is EL while the file says GR. - Hungary — NAV Online Számla 3.0. 27% is written
0.27. - India — GST e-Invoice INV-1.1 (JSON). The only structured invoice here that is not XML; the date is dd/mm/yyyy, and CGST plus SGST or IGST is an either/or, never both.
- Italy — FatturaPA (.p7m). One signed file can carry several invoices.
- Malaysia — MyInvois (UBL 2.1). Standard UBL again, with the TIN in PartyIdentification and the line name in Item/Description — read by the letter of EN 16931, both tax-number columns and the whole item column come out empty.
- Mexico — CFDI 4.0 / 3.3 (SAT). Almost every figure sits in an attribute, so a UBL reader opens the file, does not fail, and returns a blank row; TasaOCuota is a rate only when TipoFactor says Tasa.
- Peru — SUNAT CPE (UBL 2.1). The RUC sits in PartyIdentification behind the numeric scheme 6 — taking any numeric scheme would write a GLN into the tax column instead.
- Poland — KSeF FA(2) / FA(3). Fields named P_1, P_13_1 — unreadable by eye.
- Portugal — Invoice QR (Despacho 8632/2022). Between businesses there is no e-invoice XML, but the mandatory QR carries the whole invoice — and the rate is computed from it, not copied from a table.
- Romania — RO e-Factura (UBL, RO_CIUS). The ZIP from SPV also holds ANAF's signature file, which is not an invoice.
- Saudi Arabia — ZATCA invoice QR (TLV). The XML goes to ZATCA, not to you — the QR printed on the page is the only machine-readable part of what arrives, and it holds no invoice number at all.
- Spain — Facturae 3.2 (.xsig) · Veri*factu QR. IRPF withholding makes the total legitimately differ from net plus VAT; the QR on a PDF carries four fields, so the VAT columns stay empty rather than zero.
- Switzerland — QR-bill payment data. The code is read off the PDF page, which is how a Swiss bill almost always arrives.
- Türkiye — e-Fatura / e-Arşiv (UBL-TR 1.2). Standard UBL, but the VKN sits in PartyIdentification and the KDV rate hangs on TaxSubtotal — a reader built for EN 16931 leaves both tax-number columns empty and prints ?% for the rate, without a single error.
- Vietnam — Hóa đơn điện tử (TT78). Tag names are Vietnamese abbreviations, the number only means something with its ký hiệu, and TSuat can be a status code like KCT rather than a rate.
- China — 数电票 XML, OFD and PDF. That is a separate tool: 发票管家.
Read, because the invoice is a European one
Most of Europe sends EN 16931 documents over Peppol — UBL or CII, or a PDF with the XML inside (Factur-X / ZUGFeRD). Those are read everywhere, so the country matters less than it looks:
Australia, Belgium, Bulgaria, Croatia, Cyprus, Denmark, Estonia, France, Germany, Iceland, Ireland, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, New Zealand, Norway, Singapore, Slovakia, Slovenia, Sweden.
If your country is not named anywhere on this page but sends Peppol, it is almost certainly read: the format is recognised from the file's contents, and a CIUS is a narrowing of the norm rather than a new syntax. If you drop one in and it is not recognised, that is worth an email — it takes a day or two to add a format, and knowing which one is wanted is the hard part.
Not read — and it is better to say so here
- Scans and photographs — a paper invoice photographed with a phone has no text layer. If it carries a readable QR code it is used; otherwise the row comes out empty and marked, never guessed. There is no OCR here, deliberately: a digit read wrongly still looks like a number.
- SAF-T (PT) and similar ledger exports — a month of accounting, not a document. Different problem, different tool.
- Indonesia, Thailand, the Philippines and others — real invoice volumes, but local tools already cover them at local prices. Pretending otherwise would waste your time, not ours.
Trying it
Drop files on the main page — up to 10 invoices per export and 20 a day, free, no account. Pro lifts both limits for 29 € once, with no renewal.