ZUGFeRD, Factur-X, XRechnung und EN 16931 — wie alles zusammenpasst

Wer anfängt, elektronische Rechnungen zu versenden, steht binnen eines Tages vor derselben Wand aus Namen: EN 16931, CII, UBL, ZUGFeRD, Factur-X, XRechnung, Peppol. Sie klingen wie Konkurrenten. Sind sie aber nicht — sie sind Schichten eines Stapels. Sobald man die Schichtung sieht, hört das Feld auf, verwirrend zu sein.

Das Fundament: EN 16931 ist eine Bedeutung, keine Datei

EN 16931 ist die europäische Norm, die festlegt, was eine Rechnung bedeutet: ein semantisches Datenmodell plus ein Satz Geschäftsregeln (die berühmten BR-…-Regeln). Sie besagt, dass eine Rechnung einen Verkäufer, einen Käufer, Positionen und eine USt-Aufschlüsselung hat — und dass die Summen auf eine bestimmte Weise aufgehen müssen. Entscheidend: Sie schreibt kein einzelnes Dateiformat vor. Sie ist das gemeinsame Vokabular, auf das sich alles andere einigt.

Zwei Syntaxen: CII und UBL

Dasselbe EN 16931-Modell lässt sich in zwei XML-Dialekten aufschreiben: CII (UN/CEFACT Cross Industry Invoice) und UBL (OASIS Universal Business Language). Sie tragen identische Informationen in unterschiedlichen Tag-Strukturen. Man kann sie sich als zwei Schreibweisen desselben Wortes vorstellen — Empfänger bevorzugen vielleicht die eine, aber keine fügt Bedeutung hinzu oder nimmt sie weg.

ZUGFeRD und Factur-X: dasselbe hybride PDF

Hier das Detail, über das fast jeder stolpert: ZUGFeRD (Deutschland) und Factur-X (Frankreich) sind derselbe Standard, veröffentlicht von zwei nationalen Gremien unter zwei Namen. Beide legen ein menschenlesbares PDF/A-3 um eine eingebettete CII-XML-Datei. Ihr Sachbearbeiter in der Kreditorenbuchhaltung sieht ein ganz normales PDF; die empfangende Software liest die strukturierten Daten darin. Ein Dokument, beide Zielgruppen. Die Guideline-Kennungen teilen sich sogar den Namensraum urn:factur-x.eu…. Die Profile reichen von MINIMUM bis EXTENDED und bestimmen, wie viel strukturiertes Detail im XML mitreist.

XRechnung: EN 16931, verschärft für deutsche Behörden

XRechnung ist eine CIUS — eine Core Invoice Usage Specification. Das ist eine vornehme Art zu sagen: „EN 16931 mit festgezurrten Wahlmöglichkeiten und ein paar zusätzlichen Regeln“. Es ist das Format, das deutsche Behörden verlangen, es ist reines strukturiertes XML (ohne PDF-Schicht) und es ist strenger als ein einfaches ZUGFeRD-EN16931-Profil. Ein Dokument kann gültiges ZUGFeRD sein und trotzdem an XRechnung scheitern, weil XRechnung mehr verlangt.

Peppol: das Postnetz, nicht das Format

Schließlich ist Peppol gar kein Dateiformat — es ist das Austauschnetz und das Adressierungsschema, das diese XML-Dokumente zwischen Handelspartnern über Grenzen hinweg bewegt. Das Format ist das Was Sie senden; Peppol ist das Wie es ankommt.

Warum die Landkarte zählt: „sieht gut aus“ ist nicht „ist gültig“

Die Schichtung erklärt, warum eine Datei perfekt aussehen und trotzdem abgelehnt werden kann. Ein PDF kann sauber öffnen und dennoch kein gültiges PDF/A-3 sein. Ein XML kann wohlgeformt sein und trotzdem eine BR--Regel brechen — eine USt-Aufschlüsselung, die um einen Cent danebenliegt, eine Steuerbefreiung ohne Begründungscode, ein Korrekturdokument ohne Bezug. Der Validator des Empfängers wird es fangen; die Frage ist nur, ob Sie es zuerst fangen.

Genau dafür existiert ein Konformitäts-Gate. Die Bytes zu erzeugen ist der leichte Teil. Zu beweisen, dass das Ergebnis die PDF/A-3-Validierung und die EN 16931-Geschäftsregeln besteht — jedes Mal, bevor es Ihr System verlässt — macht aus „wahrscheinlich gültig“ ein „nachweislich gültig“. Dieses Gate lässt eunormia über jedes einzelne Dokument laufen, ob Sie das Web-Tool, die API oder das Offline-SDK nutzen.