XRechnung: strukturierte Rechnungsdaten
XRechnung beschreibt einen XML-Datensatz mit strukturierten Rechnungsinformationen. Der Standard wird von der Koordinierungsstelle für IT-Standards (KoSIT) betrieben und insbesondere im Umfeld öffentlicher Auftraggeber verwendet. Für die technische Konformität sind die jeweils aktuelle Spezifikation und die zugehörigen technischen Komponenten entscheidend.
Eine XML-Datei ist nicht automatisch gültig, nur weil sie als XRechnung bezeichnet wird. Für einen belastbaren Prozess gehören deshalb mindestens die Prüfung des Formats, der Pflichtangaben, der Codelisten und der geltenden Geschäftsregeln in das Prüfraster.
ZUGFeRD: PDF/A-3 mit eingebettetem XML
ZUGFeRD/Factur-X ist ein hybrides Format. Es verbindet eine PDF/A-3-Datei als sichtbare Darstellung mit eingebetteten strukturierten XML-Rechnungsdaten. Dadurch kann ein Mensch die Rechnung ansehen, während ein Zielsystem die XML-Daten verarbeiten kann.
Bei Widersprüchen zwischen PDF-Darstellung und eingebettetem XML ist der strukturierte Teil für die elektronische Verarbeitung maßgeblich. Ein Vergleich sollte deshalb nicht nur fragen, ob ein Tool „PDF unterstützt“, sondern ob es das eingebettete XML erkennt, validiert und kontrolliert an das Zielsystem übergibt.
OCR, Dokumenten-Chat und E-Rechnung getrennt bewerten
Diese drei Anwendungsfälle werden in Produktbeschreibungen häufig vermischt:
Ein Anbieter kann in einem dieser Bereiche stark sein, ohne die anderen Anforderungen abzudecken. Atlas führt diese Aufgaben deshalb getrennt und kennzeichnet ungeklärte Eigenschaften als „Zu prüfen“.
- OCR macht Text aus einem Scan oder Bild maschinenlesbar. Danach müssen Felder wie Rechnungsnummer, Betrag und Steuer noch zugeordnet und geprüft werden.
- Dokumenten-Chat beantwortet Fragen zu einem Dokument oder erstellt eine Zusammenfassung. Das ist nicht automatisch eine wiederholbare Extraktion mit festen Feldern und Exportformat.
- XRechnung/ZUGFeRD-Verarbeitung arbeitet mit strukturierten Rechnungsdaten und braucht zusätzlich Regeln für Validierung, Korrekturen, Freigaben und Übergabe.
Wo KI sinnvoll unterstützen kann
KI kann in einem Rechnungseingang zum Beispiel bei der Dokumentklassifikation, der Zuordnung eines Lieferanten, der Vorbelegung von Feldern oder der Erkennung ungewöhnlicher Werte unterstützen. Bei Scans kann sie die Nachbearbeitung der OCR-Ausgabe erleichtern.
Das ist eine redaktionelle Einordnung und keine Aussage über eine bestimmte Produktqualität. Ob ein konkreter Anbieter diese Funktionen tatsächlich, in welchem Tarif und mit welchen Grenzen anbietet, muss anhand seiner aktuellen Produkt- und Hilfedokumentation geprüft werden.
Die formale Validierung von XML-Struktur, Pflichtangaben und Geschäftsregeln sollte nicht durch eine pauschale KI-Aussage ersetzt werden. Das Bundesfinanzministerium beschreibt Validierung als sinnvolle Möglichkeit, Fehler zu erkennen, empfiehlt aber keine bestimmte Validierungsanwendung.
Business Terms einem ERP-System zuordnen
Der praktische Mehrwert entsteht meist nicht durch die Erkennung eines einzelnen Feldes, sondern durch die kontrollierte Zuordnung eines Geschäftsbegriffs zum Datenmodell des Zielsystems. Ein Unternehmen sollte dafür vorab ein kleines Mapping-Verzeichnis anlegen. Die Feldnamen unterscheiden sich je nach ERP; die Logik bleibt aber ähnlich:
Für jedes Mapping sollten Geschäftsbegriff, ERP-Feld, Datentyp, Quelle im Dokument, zulässige Werte, Validierungsregel, Verantwortliche und manueller Fallback dokumentiert werden. KI kann einen Zuordnungsvorschlag machen. Die Übernahme sollte aber erst nach Regelprüfung und – bei Unsicherheit oder hohem Risiko – nach menschlicher Freigabe erfolgen.
- Rechnungsnummer → Beleg- oder Rechnungsnummer im ERP; Textfeld, Pflichtfeld, Prüfung auf Duplikate.
- Lieferant → Kreditor, Vendor Account oder Lieferanten-ID; Abgleich mit dem ERP-Stammdatensatz statt freier KI-Zuordnung.
- Bestellnummer → Purchase Order; Abgleich mit Bestellung und gegebenenfalls Wareneingang.
- Netto, Steuer und Brutto → Betragsfelder mit Währung, Steuerkennzeichen und Rechenprüfung.
- Kostenstelle, Projekt oder Sachkonto → finanzielle Dimension beziehungsweise Kontierung; nur zulässige Werte aus den ERP-Auswahllisten übernehmen.
- Zahlungsziel und Skonto → Fälligkeits- und Skontofelder; Datums- und Währungslogik vor der Übergabe prüfen.
Technische XML-Zuordnung: UBL und CII
Ein Business Term ist zunächst eine fachliche Bedeutung und noch kein XML-Element. Erst das Syntax-Binding ordnet ihn einem konkreten Pfad zu. XRechnung kann die Syntaxen UBL 2.1 und UN/CEFACT Cross Industry Invoice (CII) verwenden. Die Präfixe `cbc` und `cac` gehören zur UBL-Syntax; `rsm`, `ram` und `udt` werden in CII verwendet. Entscheidend ist nicht nur der sichtbare Präfix, sondern die vollständige Namespace-URI und der gesamte Pfad.
Die folgende Tabelle zeigt ausgewählte Kernzuordnungen. Sie ist eine redaktionelle Kurzfassung des Syntax-Bindings und keine vollständige Kopie der Spezifikation:
| Business Term | Inhalt | UBL-2.1-Pfad | CII-Pfad | Typische Prüfung | |---|---|---|---|---| | BT-1 | Rechnungsnummer | `/Invoice/cbc:ID` | `/rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:ID` | nicht leer, im Geschäftskontext eindeutig | | BT-2 | Rechnungsdatum | `/Invoice/cbc:IssueDate` | `/rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:IssueDateTime/udt:DateTimeString` | gültiges Datum; CII verwendet die passende Formatangabe | | BT-3 | Rechnungstyp | `/Invoice/cbc:InvoiceTypeCode` | `/rsm:CrossIndustryInvoice/rsm:ExchangedDocument/ram:TypeCode` | zulässiger Code aus der geltenden Codeliste | | BT-5 | Rechnungswährung | `/Invoice/cbc:DocumentCurrencyCode` | Header-Trade-Agreement-Währung in CII | einheitliche Betragswährung prüfen | | BT-10 | Käuferreferenz | `/Invoice/cbc:BuyerReference` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerReference` | Routing- oder Referenzvorgabe des Empfängers | | BT-13 | Bestellreferenz | `/Invoice/cac:OrderReference/cbc:ID` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerOrderReferencedDocument/ram:IssuerAssignedID` | gegen Bestellung und gegebenenfalls Wareneingang abgleichen | | BT-27 | Verkäufername | `/Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:SellerTradeParty/ram:Name` | gegen Lieferantenstammsatz prüfen | | BT-44 | Käufername | `/Invoice/cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:Name` | gegen Kundenstammsatz prüfen | | BT-106 | Nettosumme der Positionen | `/Invoice/cac:LegalMonetaryTotal/cbc:LineExtensionAmount` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:LineTotalAmount` | Positionssummen und Rundung prüfen | | BT-109 | Rechnungsbetrag ohne Umsatzsteuer | `/Invoice/cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:TaxBasisTotalAmount` | Netto- und Steuerlogik prüfen | | BT-112 | Rechnungsbetrag mit Umsatzsteuer | `/Invoice/cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:GrandTotalAmount` | Bruttosumme und Währung prüfen | | BT-115 | Zahlbetrag | `/Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount` | `/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementHeaderMonetarySummation/ram:DuePayableAmount` | offene Beträge, Vorauszahlungen und Rundung prüfen |
Die Pfade sind in der Tabelle vollständig angegeben und dienen der Orientierung am jeweiligen Kern-Syntax-Binding. Für eine Implementierung müssen zusätzlich die Namespace-URI, die Kardinalität, die Codelisten und die Geschäftsregeln der verwendeten Version übernommen werden. UBL und CII dürfen dabei nicht vermischt werden.
XRechnung und ZUGFeRD unterscheiden
Bei XRechnung wird das XML als UBL- oder CII-Dokument übertragen und anhand des geltenden XRechnung-Bundles sowie der zugehörigen Geschäftsregeln validiert. Die KoSIT stellt dafür neben der Spezifikation auch technische Artefakte und Beispielnachrichten bereit.
Bei ZUGFeRD/Factur-X wird das CII-XML in eine PDF/A-3-Datei eingebettet. Das konkrete Profil ist entscheidend: Profile können unterschiedliche Felder, Kardinalitäten und Regeln enthalten. ZUGFeRD 2.5.2 basiert auf CII D22B, ist zu D16B abwärtskompatibel und stellt eigene XSD- und Schematron-Artefakte je Profil bereit.
Die Tabelle verwendet eigene Kurzbeschreibungen und verlinkt auf die maßgeblichen Primärquellen. Vollständige Normtexte, geschützte Tabellen oder Logos werden nicht kopiert. Die Angaben sind eine technische Orientierung und keine Zusage, dass ein XML-Dokument steuerlich, rechtlich oder beim konkreten Rechnungsempfänger akzeptiert wird.
Microsoft dokumentiert für Dynamics 365 Finance genau diese Trennung: Mapping-Regeln können unter anderem Rechtseinheit, Lieferantenkonto, Artikel und Aufwandstyp ableiten; der Kreditorenbuchhalter prüft den Status weiterhin. Benutzerdefinierte Felder lassen sich außerdem gezielt auf ERP-Felder abbilden. Das ist ein konkretes Beispiel für ERP-nahe Automatisierung, aber kein allgemeiner Beleg dafür, dass jedes Dokumententool jedes ERP automatisch unterstützt.
UiPath beschreibt mit seiner Taxonomy einen ähnlichen Grundbaustein auf Dokumentebene: Dokumenttypen und ihre Felder bilden ein gemeinsames Metadatenmodell. Ob daraus eine fertige ERP-Integration entsteht, hängt jedoch von Konnektor, Workflow, Datenmodell und Zielsystem ab.
Kleine Vorlage für ein ERP-Mapping
Diese Vorlage hilft, eine Anbieterwerbung von einer tatsächlich nutzbaren Prozessbeschreibung zu unterscheiden. Ein Tool sollte nicht nur „KI-Extraktion“ anbieten, sondern zeigen können, wie Ergebnisse validiert, freigegeben, protokolliert und in das konkrete ERP übertragen werden.
- Geschäftsbegriff: „Lieferant“
- Dokumentquelle: Kopfbereich, Lieferantenname und Steuernummer
- Zielsystem: ERP-Lieferantenkonto
- Erkennung: OCR, XML-Feld oder Stammdatenabgleich
- Zulässige Werte: aktive Lieferanten des Zielsystems
- Validierung: eindeutige Übereinstimmung, sonst manuelle Prüfung
- Aktion: als Vorschlag übernehmen, nicht automatisch buchen
- Protokoll: Quelldatei, erkannter Wert, Zielwert, Benutzer und Zeitpunkt
Prüfraster für eine Auswahl
- Werden XRechnung und ZUGFeRD ausdrücklich unterstützt oder nur allgemeine PDF-Dateien?
- Wird eingebettetes XML bei ZUGFeRD ausgelesen und getrennt von der PDF-Ansicht verarbeitet?
- Welche Versionen, Profile und Geschäftsregeln werden geprüft?
- Gibt es einen nachvollziehbaren Hinweis auf Validierungsfehler und eine manuelle Korrekturmöglichkeit?
- Werden Rechnungsfelder strukturiert an CSV, API, Buchhaltung oder ERP übergeben?
- Gibt es ein Mapping von Geschäftsbegriffen zu ERP-Feldern, Stammdaten und finanziellen Dimensionen?
- Sind Freigaben, Rollen, Protokollierung und ein manueller Fallback vorhanden?
- Wo werden Rechnung, XML, OCR-Ergebnis, Protokolle und Supportdaten verarbeitet?
- Welche Aufbewahrungs- und Löschfristen sowie DPA-/AVV-Unterlagen gelten im konkreten Tarif?
Was offen bleiben muss
Eine E-Rechnung ist nicht allein deshalb korrekt oder rechtlich passend, weil ein Anbieter „KI“, „OCR“, „E-Rechnung“ oder „ZUGFeRD“ in seiner Produktbeschreibung nennt. Tarif, Version, Profil, Zielsystem, Datenverarbeitung und Validierung müssen für den konkreten Prozess geprüft werden. Die offiziellen Anforderungen und Übergangsregelungen können sich ändern; vor einer verbindlichen Umstellung sollten die aktuellen Informationen des Bundesfinanzministeriums, der KoSIT und des FeRD erneut herangezogen werden.