Eine XRechnung Schritt für Schritt lesen

Lesen Sie eine XRechnung nicht Zeile für Zeile im Roh-XML. Lesen Sie sie wie eine strukturierte Rechnung: zuerst Kontext und Format, dann Verkäufer und Käufer, danach Rechnungsdaten, Positionen, Steuern, Summen, Zahlungsdaten und Referenzen.

Der technische XML-Datensatz ist die eigentliche Rechnung. Für Menschen wird er aber erst verständlich, wenn die Daten in fachliche Bereiche übersetzt werden. Genau diese Lesereihenfolge hilft Buchhaltung, Einkauf und ERP-Teams, Fehler schneller einzuordnen.

XRechnung ist der deutsche Standard für strukturierte elektronische Rechnungen an öffentliche Auftraggeber und baut auf EN 16931 auf. Der Standard beschreibt nicht nur ein Dateiformat, sondern welche Rechnungsinformationen in einem XML-Datensatz vorhanden sein dürfen oder müssen und wie sie weiterverarbeitet werden können.

Eine XRechnung kann technisch in UBL oder UN/CEFACT CII umgesetzt sein. Beide Syntaxen können dieselben fachlichen Rechnungsinformationen abbilden, verwenden aber unterschiedliche XML-Strukturen. Für die fachliche Prüfung ist deshalb wichtiger, welche Business Information enthalten ist, nicht wie elegant der XML-Code aussieht.

Bevor Sie Beträge oder Steuerdaten lesen, sollten Sie wissen, welche Art von Datei vorliegt. Eine XRechnung ist nicht dasselbe wie eine normale PDF-Rechnung und auch nicht dasselbe wie ein ZUGFeRD-PDF mit eingebetteter XML. Außerdem kann die verwendete XRechnung-Version für Validierung und Empfängerakzeptanz relevant sein.

1. Dateityp prüfen: reine XML-Datei, ZUGFeRD/Factur-X-PDF oder normales PDF.
2. Syntax erkennen: UBL oder CII.
3. Profil und Version notieren: zum Beispiel XRechnung und verwendete Spezifikationsversion.
4. Empfängerkontext klären: öffentlicher Auftraggeber, B2B-Kunde, Portal, Peppol oder eigener Rechnungseingang.
5. Erst danach fachliche Rechnungsdaten lesen.

1. Kopfbereich lesen: Rechnungsnummer, Rechnungsdatum, Rechnungsart, Währung und Leistungszeitraum.
2. Verkäufer und Käufer prüfen: Name, Adresse, Umsatzsteuer-ID, Kontaktdaten und Empfängerbezug.
3. Referenzen prüfen: Buyer Reference, Leitweg-ID, Bestellnummer, Vertragsnummer, Projektreferenz oder Kostenstelle.
4. Positionen lesen: Beschreibung, Menge, Einheit, Einzelpreis, Nachlass, Zuschlag, Steuerkategorie und Positionsbetrag.
5. Steuergruppen prüfen: Steuersatz, Steuerkategorie, steuerpflichtige Basis und Steuerbetrag.
6. Summen abgleichen: Positionssummen, Dokumentennachlässe, Zuschläge, Nettobetrag, Steuerbetrag und Gesamtbetrag.
7. Zahlungsdaten lesen: IBAN, Zahlungsart, Fälligkeit, Skonto und Zahlungsbedingungen.
8. Validierungsbericht lesen: erst blockierende Fehler, dann Warnungen und Hinweise.

Der Kopfbereich beantwortet die Frage, welche Rechnung vorliegt. Hier sollten Rechnungsnummer, Rechnungsdatum, Dokumenttyp, Währung und Leistungsbezug eindeutig sein. Wenn diese Basisdaten fehlen oder widersprüchlich sind, ist die weitere Prüfung unsicher.

Bei XRechnung sind Verkäufer, Käufer und Empfängerbezug nicht nur Adressblöcke. Sie steuern, ob eine Rechnung zugeordnet, geprüft und verarbeitet werden kann. Besonders bei öffentlichen Auftraggebern sind Referenzen wie Leitweg-ID oder Buyer Reference oft entscheidend.

Für Buchhaltung und Einkauf ist wichtig, ob die Referenz im strukturierten Feld steht. Eine Bestellnummer oder Leitweg-ID im freien Text hilft maschineller Verarbeitung häufig nicht. Wenn der Bericht eine fehlende Käuferreferenz meldet, ist daher zuerst zu prüfen, ob die Information wirklich strukturiert fehlt oder nur an der falschen Stelle steht.

• Verkäuferdaten: Name, Adresse, Umsatzsteuer-ID, Steuernummer und Kontakt.
• Käuferdaten: Rechnungsempfänger, Adresse, interne Zuordnung und Kommunikationsdaten.
• Buyer Reference: häufige Zuordnungsinformation für öffentliche oder interne Empfängerprozesse.
• Leitweg-ID: wichtig bei vielen B2G-Rechnungen an öffentliche Auftraggeber.
• Bestell- und Vertragsreferenzen: wichtig für Einkauf, Freigabe und Wareneingangsabgleich.

Rechnungspositionen sind der Bereich, in dem fachliche Prüfung und Validierung eng zusammenkommen. Eine Position sollte verständlich beschreiben, was geliefert oder geleistet wurde, welche Menge und Einheit gilt, welcher Preis verwendet wird und welcher Steuerlogik die Position folgt.

Viele XRechnung-Fehler entstehen nicht, weil ein einzelner Betrag offensichtlich falsch ist, sondern weil mehrere strukturierte Werte rechnerisch nicht zusammenpassen. Deshalb sollten Steuergruppen und Summen immer nach einer festen Reihenfolge gelesen werden.

1. Positionsbeträge je Steuerkategorie zusammenfassen.
2. Dokumentennachlässe und Zuschläge prüfen.
3. Steuerbasis je Steuergruppe nachvollziehen.
4. Steuerbetrag je Steuersatz prüfen.
5. Nettosumme, Steuerbetrag und Bruttosumme vergleichen.
6. Rundungsdifferenzen nicht isoliert betrachten, sondern bis zur Position zurückverfolgen.

Wenn ein Summenfehler im Validierungsbericht erscheint, ist die Ursache oft nicht die gemeldete Gesamtsumme allein. Häufig liegt der Fehler in einer Position, einem Nachlass, einem Zuschlag, einer Steuerkategorie oder einer Rundungsregel.

Zahlungsinformationen sind fachlich wichtig, werden aber in der ersten Sichtprüfung oft übersehen. Bei einer XRechnung sollten Zahlungsempfänger, IBAN, Zahlungsart, Fälligkeit und Zahlungsbedingungen strukturiert lesbar sein. Skonto oder komplexe Zahlungsbedingungen können zusätzliche Prüfungen erfordern.

• IBAN und Kontoinhaber passen zum Lieferanten oder vereinbarten Zahlungsempfänger.
• Zahlungsart ist als erlaubter Code abgebildet.
• Fälligkeitsdatum passt zu Rechnungsdatum und Zahlungsziel.
• Skonto ist nicht nur als Freitext vorhanden, wenn strukturierte Verarbeitung benötigt wird.
• Abweichende Zahlungsempfänger werden intern geprüft, bevor eine Zahlung freigegeben wird.

XML-Pfade helfen Entwicklern, die technische Stelle eines Fehlers zu finden. Für Buchhaltung und Freigabe sind sie aber nur ein Hilfsmittel. Ein Pfad sagt nicht automatisch, welche geschäftliche Angabe fehlt oder welcher Prozess geändert werden muss.

Die bessere Arbeitsweise ist eine Übersetzung: XML-Pfad und Regel-ID bleiben im technischen Ticket erhalten, aber die fachliche Beschreibung lautet zum Beispiel fehlende Käuferreferenz, ungültiger Einheitencode, widersprüchliche Steuerbasis oder unplausible Zahlungsempfängerangabe.

• Im Roh-XML starten und dadurch den fachlichen Zusammenhang verlieren.
• Nur die sichtbare Darstellung prüfen und den Validierungsbericht ignorieren.
• Referenzen im Freitext akzeptieren, obwohl der Empfänger strukturierte Felder benötigt.
• Summenfehler nur am Gesamtbetrag suchen, statt Positionen, Nachlässe, Zuschläge und Steuergruppen mitzulesen.
• UBL und CII verwechseln und technische Pfade falsch interpretieren.
• Eine alte XRechnung-Version oder veraltete Prüfkonfiguration mit einem aktuellen Empfängerprozess vergleichen.

Eine gute XRechnung-Lesepraxis verbindet fachliche Prüfung und technische Diagnose. Buchhaltung erkennt meist, ob die Rechnung kaufmännisch plausibel ist. ERP-Teams finden, warum die strukturierte Datei so exportiert wurde.

1. Buchhaltung liest die fachlichen Bereiche und markiert Unklarheiten.
2. Validierungsbericht wird nach Schweregrad sortiert.
3. ERP-Team prüft nur die Meldungen, die mit Mapping, Codes, Syntax oder Exportprofil zusammenhängen.
4. Lieferant erhält fachliche Korrekturhinweise, nicht nur XML-Pfade.
5. Die korrigierte Datei wird erneut vollständig gelesen und validiert.