XML-Rechnungsstruktur erklärt: UBL, CII und wichtige Felder

XML-Rechnungen wie XRechnung, UBL oder CII speichern Rechnungsdaten in klar getrennten Bereichen. Was im PDF als eine visuelle Seite erscheint, wird in XML als strukturierte Daten modelliert: Kopf, Verkäufer, Käufer, Positionen, Steuern, Summen und Zahlung.

Diese Struktur ist der Grund, warum Software Rechnungen automatisch verarbeiten kann. Sie ist aber auch der Grund, warum eine Datei scheitern kann, obwohl sie für Menschen in einem Viewer plausibel aussieht.

EN 16931 beschreibt, welche fachlichen Rechnungsinformationen benötigt werden. UBL und CII beschreiben, wie diese Informationen technisch als XML geschrieben werden. XRechnung nutzt diese Syntaxen und konkretisiert sie für deutsche Anforderungen.

Die gleiche fachliche Information kann in UBL und CII anders aussehen. Deshalb sollte man nicht nur nach Elementnamen suchen, sondern verstehen, welcher Business Term gemeint ist.

Fast jede strukturierte Rechnung folgt derselben fachlichen Logik. Die technische Benennung kann je nach Syntax variieren, aber die Geschäftsbereiche bleiben ähnlich.

Der Rechnungskopf enthält grundlegende Informationen: Rechnungsnummer, Rechnungsdatum, Dokumenttyp, Währung und Profilangaben. Diese Daten helfen Systemen, die Datei einzuordnen und den richtigen Validierungspfad zu wählen.

Häufige Fehler entstehen, wenn ein Profil nicht eindeutig angegeben ist, ein Dokumenttyp nicht zur Rechnung passt oder Pflichtinformationen zwar im PDF stehen, aber nicht strukturiert exportiert wurden.

In XML sind Verkäufer und Käufer nicht nur Textblöcke. Sie bestehen aus strukturierten Feldern: Name, Straße, Postleitzahl, Ort, Land, steuerliche Identifikatoren und elektronische Adressen.

Für automatische Verarbeitung ist das wichtig. Ein Mensch kann eine Adresse in einem PDF interpretieren. Software braucht die Adresse in eindeutig getrennten Feldern, inklusive Ländercode und gegebenenfalls Identifikatoren.

Referenzen verbinden die Rechnung mit dem zugrunde liegenden Geschäftsvorgang. Dazu gehören Käuferreferenz, Bestellnummer, Vertragsreferenz oder Lieferantennummer. Bei öffentlichen Auftraggebern ist die Leitweg-ID besonders wichtig.

Diese Angaben dürfen nicht beliebig in Freitextfeldern stehen. Der Empfängerprozess erwartet sie oft an einer bestimmten Stelle. Ein häufiger Fehler ist die Verwechslung von Bestellnummer und Käuferreferenz.

Rechnungspositionen enthalten, was geliefert oder geleistet wurde: Beschreibung, Menge, Einheit, Einzelpreis, Positionswert und Steuerzuordnung. Jede Position muss später zur Summe der Rechnung passen.

Fehler entstehen oft durch Rundung, Einheiten, negative Beträge, Rabatte oder abweichende Steuerkategorien. Wenn die Positionen nicht sauber strukturiert sind, scheitern Summen- und Steuerregeln.

Die Steuerlogik ist in XML-Rechnungen besonders streng. Es reicht nicht, irgendwo einen Steuerbetrag zu nennen. Steuerkategorie, Steuersatz, Steuerbasis und Steuerbetrag müssen zusammenpassen.

Bei Steuerbefreiung, Reverse Charge oder Nullsteuersatz müssen die strukturierten Angaben zur fachlichen Aussage der Rechnung passen. Sonst kann die Rechnung an EN-16931-Business-Rules scheitern.

Am Ende der Rechnung stehen Nettosumme, Steuerbetrag, Bruttosumme, eventuell Vorauszahlungen, Rundungen und der tatsächlich zu zahlende Betrag. Diese Summen müssen rechnerisch zu Positionen, Zuschlägen und Abschlägen passen.

Zahlungsdaten wie IBAN, Zahlungsart, Fälligkeit oder Verwendungszweck sind nicht nur Komfort. Sie können für automatische Buchung und Zahlungsfreigabe notwendig sein.

Wenn ein Validator einen Fehler meldet, hilft die Struktur bei der Ursachenanalyse. Ein Schemafehler betrifft meist den Aufbau. Eine Business Rule betrifft fachliche Zusammenhänge wie Summen, Steuerlogik oder Pflichtfelder.

Deshalb ist ein lesbarer Bericht so hilfreich: Er übersetzt technische XML-Strukturen in Rechnungsbereiche, die Buchhaltung, Lieferant oder ERP-Team verstehen und korrigieren können.