E-invoicing and its formats

An e-invoice is an invoice in a structured, machine-readable format — not a picture of an invoice. A PDF invoice is not an e-invoice: it carries text at coordinates, but no fields. A program cannot reliably read from it which amount is the VAT. That is exactly what an e-invoice delivers.

The standard underneath

European e-invoice formats go back to EN 16931. The standard defines a semantic data model: every field has an identifier — BT-2 is the invoice date, BT-31 the seller’s VAT ID. These identifiers are language-neutral and appear in every validation report.

Two refinements build on it:

Term	Meaning
CIUS	a narrowing of the standard — additional obligations, no new fields. XRechnung is the German CIUS
Extension	an extension with additional fields the standard itself does not know

The nine formats that are read and written

Format	Origin	Technical basis
XRechnung	Germany	UBL 2.1 (CIUS to EN 16931)
ZUGFeRD / Factur-X	Germany, France	CII — as XML or as a hybrid PDF
Peppol BIS 3.0	EU-wide network	UBL 2.1
FatturaPA	Italy	own schema, submission via the SdI
Finvoice	Finland	own schema
ebInterface	Austria	own schema
Austrofix	Austria	own schema (BRZ)
FA_VAT / KSeF	Poland	own schema, submission via KSeF
Facturae	Spain	own schema, B2G with a XAdES signature

How conversion works

Every conversion runs through one shared data model: source → model → target. There is deliberately no direct route between two formats — otherwise nine formats would require seventy-two translators instead of eighteen.

Whatever the target format cannot carry is lost

That is a limit of the format, not a fault. FA_VAT knows no due date, FatturaPA no alternative payee. Which field passes through losslessly for which format is set out field by field in the fidelity matrix of the product repository.

Beyond the nine: ERP formats

Read and converted, but not validated against EN 16931, are SAP INVOIC IDoc, UN/EDIFACT INVOIC, cXML, openTRANS, DATEV and Invoiceflair JSON. The reason is simple: there are no EN 16931 rules there to validate against. The validation tool detects the format, names it and points to conversion.

The XML rendering of UN/EDIFACT (as SAP PI produces it) is read but not written: it looks different in every middleware — a file written by us would only be valid for the one installation whose conventions we had guessed.

Beyond the nine: non-European formats

Here two groups must be kept apart, because they amount to opposite answers:

Group	What is possible
read but not written	Mexico (CFDI 4.0), Brazil (NF-e, NFS-e), Chile, Uruguay, Paraguay, Bolivia, Ecuador, Costa Rica, Guatemala, Dominican Republic, Korea, China — reading them in and converting to a European format works
recognised and named, but not read	Mexico in the legacy version CFDI 3.3, the municipal ABRASF legacy layout of the Brazilian NFS-e, and the Taiwanese eGUI (電子發票)

Why they are not written: the documents of these systems carry codes issued solely by the respective tax authority — a number we wrote ourselves would be invalid there.

For the second group there is no conversion at all. The message therefore points to Create, not to Convert: for a recipient in the EU, the invoice has to be entered afresh there.

Why a format is named even though nothing follows from it

“Unknown e-invoice format” sounds like a defect in your own document and invites another attempt with a different target format. Naming the format says instead that the file is sound and only this portal cannot convert it.

What is not built

The engine builds the format, not the connection to government platforms. For FA_VAT the KSeF submission is missing, likewise for the SdI (Italy), Chorus Pro (France) and FACe (Spain). Valid XML is produced; submission is explicitly not built.