E-Rechnung und ihre Formate

Eine E-Rechnung ist eine Rechnung in einem strukturierten, maschinenlesbaren Format — nicht ein Bild einer Rechnung. Eine PDF-Rechnung ist keine E-Rechnung: Sie trägt Text an Koordinaten, aber keine Felder. Ein Programm kann aus ihr nicht zuverlässig ablesen, welcher Betrag die Umsatzsteuer ist. Genau das leistet eine E-Rechnung.

Die Norm darunter

Europäische E-Rechnungsformate gehen auf EN 16931 zurück. Die Norm legt ein semantisches Datenmodell fest: Jedes Feld hat eine Kennung — BT-2 ist das Rechnungsdatum, BT-31 die USt-IdNr. des Verkäufers. Diese Kennungen sind sprachneutral und tauchen in jedem Prüfbericht auf.

Darauf setzen zwei Ausprägungen auf:

Begriff	Bedeutung
CIUS	eine Verengung der Norm — zusätzliche Pflichten, keine neuen Felder. XRechnung ist die deutsche CIUS
Extension	eine Erweiterung mit zusätzlichen Feldern, die die Norm selbst nicht kennt

Die neun Formate, die gelesen und geschrieben werden

Format	Herkunft	Technische Grundlage
XRechnung	Deutschland	UBL 2.1 (CIUS zu EN 16931)
ZUGFeRD / Factur-X	Deutschland, Frankreich	CII — als XML oder als Hybrid-PDF
Peppol BIS 3.0	EU-weites Netz	UBL 2.1
FatturaPA	Italien	eigenes Schema, Einreichung über das SdI
Finvoice	Finnland	eigenes Schema
ebInterface	Österreich	eigenes Schema
Austrofix	Österreich	eigenes Schema (BRZ)
FA_VAT / KSeF	Polen	eigenes Schema, Einreichung über KSeF
Facturae	Spanien	eigenes Schema, B2G mit XAdES-Signatur

Wie umgewandelt wird

Jede Umwandlung läuft über ein gemeinsames Datenmodell: Quelle → Modell → Ziel. Einen direkten Weg zwischen zwei Formaten gibt es bewusst nicht — sonst bräuchte man für neun Formate zweiundsiebzig Übersetzer statt achtzehn.

Jenseits der neun: ERP-Formate

Gelesen und umgewandelt, aber nicht gegen EN 16931 geprüft werden SAP INVOIC IDoc, UN/EDIFACT INVOIC, cXML, openTRANS, DATEV und Invoiceflair JSON. Der Grund ist einfach: Es gibt dort keine EN-16931-Regeln, gegen die man prüfen könnte. Das Prüfwerkzeug erkennt das Format, benennt es und verweist aufs Umwandeln.

Die XML-Darstellung von UN/EDIFACT (wie SAP PI sie erzeugt) wird gelesen, aber nicht geschrieben: Sie sieht je Middleware anders aus — eine von uns geschriebene Datei wäre nur für die eine Installation gültig, deren Konventionen wir geraten hätten.

Jenseits der neun: außereuropäische Formate

Hier sind zwei Gruppen auseinanderzuhalten, weil sie gegensätzliche Auskünfte bedeuten:

Gruppe	Was möglich ist
gelesen, aber nicht geschrieben	Mexiko (CFDI 4.0), Brasilien (NF-e, NFS-e), Chile, Uruguay, Paraguay, Bolivien, Ecuador, Costa Rica, Guatemala, Dominikanische Republik, Korea, China — einlesen und nach Europa umwandeln geht
erkannt und benannt, aber nicht gelesen	Mexiko in der Altfassung CFDI 3.3, das kommunale ABRASF-Altlayout der brasilianischen NFS-e und die taiwanische eGUI (電子發票)

Warum nicht geschrieben wird: Die Belege dieser Systeme tragen Codes, die allein die jeweilige Finanzverwaltung vergibt — eine Nummer, die wir selbst hineinschreiben, wäre dort ungültig.

Für die zweite Gruppe gibt es keine Umwandlung. Die Meldung verweist deshalb aufs Erstellen, nicht aufs Konvertieren: Für einen Empfänger in der EU ist die Rechnung dort neu zu erfassen.

Was nicht gebaut ist

Die Engine baut das Format, nicht die Anbindung an staatliche Plattformen. Für FA_VAT fehlt die KSeF-Einreichung, ebenso für SdI (Italien), Chorus Pro (Frankreich) und FACe (Spanien). Erzeugt wird valides XML; die Einreichung ist ausdrücklich nicht gebaut.