XRechnung CII implementieren: Schritt-für-Schritt mit ROI und Compliance

Kurz gesagt: CII ist eine der XML-Syntaxen, in denen eine E-Rechnung nach EN 16931 technisch dargestellt werden kann. Auch XRechnung unterstützt neben UBL die Syntax UN/CEFACT CII. Dieser Guide zeigt, wie Sie eine CII-basierte Umsetzung strukturiert vorbereiten: von Business Case und Datenmapping über technische Validierung bis zu Betrieb, Fehlerbehandlung und Aufbewahrung.

Der direkte Fahrplan:

1. Bewerten Sie Wirtschaftlichkeit und Projektumfang auf Basis Ihrer eigenen Prozesse
2. Definieren Sie Anforderungen an Aufbewahrung und Dokumentation
3. Legen Sie Rollen, Monitoring und Fehlerbehandlung fest
4. Verstehen Sie CII-Syntax und Business Terms
5. Erstellen Sie das Mapping vom Quellsystem zum CII-Datenmodell
6. Implementieren und testen Sie die technische Validierung
7. Führen Sie einen Pilot durch und gehen Sie kontrolliert produktiv

Nach diesem Guide können Sie:

• einen belastbaren Business Case auf Grundlage eigener Prozessdaten erstellen
• Rechnungsdaten strukturiert auf Business Terms und CII-Felder abbilden
• technische Validierungsprozesse aufbauen
• Aufbewahrungs- und Dokumentationsanforderungen angemessen berücksichtigen
• Betriebsverantwortlichkeiten, Monitoring und Fehlerprozesse definieren
• CII und UBL als unterschiedliche technische Syntaxen der XRechnung einordnen

Inhaltsverzeichnis

• Für wen ist dieser Guide?
• Grundlagen und Kontext
• Schritt-für-Schritt-Anleitung
• Praxisbeispiel und Anwendung
• Fortgeschrittene Varianten und Skalierung
• Kompakte Zusammenfassung
• Mini-Checkliste
• FAQ und Troubleshooting

Für wen ist dieser Guide?

Dieser Guide richtet sich an CFOs, Finance-Verantwortliche, IT-Projektleitungen und Fachverantwortliche, die XRechnung beziehungsweise CII in bestehende Rechnungsprozesse integrieren möchten. Grundkenntnisse über E-Rechnungen und Zugriff auf die relevanten ERP- oder Rechnungssysteme sind hilfreich.

Der Schwerpunkt liegt auf technischer und organisatorischer Umsetzung. Individuelle umsatzsteuerliche Fragestellungen, besondere Vorgaben einzelner öffentlicher Auftraggeber oder länderspezifische E-Invoicing-Regelungen müssen bei Bedarf gesondert geprüft werden.

Grundlagen und Kontext

Die europäische Norm EN 16931 definiert ein semantisches Datenmodell für elektronische Rechnungen. Dieses fachliche Modell kann in unterschiedlichen technischen Syntaxen abgebildet werden.

Für XRechnung werden insbesondere zwei Syntaxen unterstützt:

• UBL 2.1
• UN/CEFACT Cross Industry Invoice, kurz CII

CII und UBL bilden grundsätzlich dieselben fachlichen Anforderungen der EN 16931 beziehungsweise der darauf aufbauenden XRechnung ab, verwenden jedoch unterschiedliche XML-Strukturen, Elemente, Namespaces und technische Mappings. Sie unterscheiden sich daher nicht lediglich in einzelnen Details wie Namespace oder Datumsformat.

Aktuelle XRechnung-Implementierungen basieren auf der Versionslinie 3.0.x. Welche konkrete Validator-Konfiguration und welche zusätzlichen Regelwerke eingesetzt werden sollten, sollte anhand der jeweils aktuellen KoSIT-Unterlagen geprüft werden.

Der wirtschaftliche Nutzen einer CII-Implementierung hängt stark vom bestehenden Prozess ab. Automatisierung kann manuelle Arbeit reduzieren und Datenqualität verbessern, aber pauschale Zeitersparnisse, Fehlerquoten oder Amortisationszeiträume lassen sich ohne eigene Prozessdaten nicht belastbar angeben.

Schritt-für-Schritt-Anleitung

Schritt 1: Business Case und Projektumfang bestimmen

Vor einer technischen Implementierung sollte geklärt werden, welches konkrete Problem gelöst werden soll und welche Kosten heute entstehen.

• Ermitteln Sie die Zahl der relevanten Rechnungen pro Monat.
• Dokumentieren Sie die heutige Bearbeitungszeit für Erstellung, Prüfung, Versand und Fehlerbearbeitung.
• Erfassen Sie typische Rückläufer und Nacharbeiten.
• Prüfen Sie, welche Arbeitsschritte durch strukturierte Rechnungsdaten tatsächlich entfallen oder automatisiert werden können.
• Berücksichtigen Sie interne Projektzeit, Schnittstellen, Software, Tests, Schulung und laufenden Betrieb.
• Vergleichen Sie erwartete Prozessverbesserungen anschließend mit den tatsächlichen Gesamtkosten.

Praxis-Tipp: Rechnen Sie nicht mit allgemeinen Branchenwerten. Wenn heute beispielsweise zehn Minuten pro Rechnung benötigt werden, messen Sie nach einem Pilotprojekt erneut und verwenden Sie diese realen Werte für Ihren Business Case.

Kontrolle: Können Sie nachvollziehbar erklären, welche heutigen Prozesskosten durch das Projekt beeinflusst werden sollen?

Schritt 2: Aufbewahrung und Dokumentation festlegen

Rechnungen unterliegen steuerlichen Aufbewahrungspflichten. Für E-Rechnungen ist insbesondere der strukturierte elektronische Teil in seiner ursprünglichen Form zu erhalten.

• Definieren Sie, wo die ursprüngliche CII-Datei aufbewahrt wird.
• Stellen Sie sicher, dass die Daten während der Aufbewahrungsfrist verfügbar bleiben.
• Legen Sie angemessene Zugriffs- und Berechtigungskonzepte fest.
• Dokumentieren Sie wesentliche Verarbeitungsschritte entsprechend Ihrem tatsächlichen Prozess.
• Entscheiden Sie, welche technischen Validierungsprotokolle für Betrieb und Fehleranalyse sinnvoll aufbewahrt werden.
• Berücksichtigen Sie Korrekturen, Stornos und erneut erzeugte Rechnungen in Ihrem Prozess.

Rechnungen sind grundsätzlich acht Jahre aufzubewahren. Für andere Geschäftsunterlagen können andere Fristen gelten.

Ein vollständiger Audit-Trail jedes technischen Verarbeitungsschritts oder die dauerhafte Speicherung jedes Validierungsreports ist nicht pauschal für jede E-Rechnung als eigenständige gesetzliche Pflicht vorgeschrieben. Solche Funktionen können jedoch die Nachvollziehbarkeit des eigenen Prozesses unterstützen.

Kontrolle: Können Sie die ursprüngliche strukturierte Rechnung innerhalb Ihrer Aufbewahrungsfrist zuverlässig wieder bereitstellen?

Schritt 3: Rollen, Monitoring und Fehlerbehandlung definieren

Ein stabiler Betrieb benötigt klare Zuständigkeiten. Wie umfangreich Monitoring und Incident Management ausgestaltet werden, sollte sich am Rechnungsvolumen und der Kritikalität des Prozesses orientieren.

• Legen Sie fest, wer fachlich für den Rechnungsprozess verantwortlich ist.
• Definieren Sie einen technischen Ansprechpartner für Integrations- oder Validierungsfehler.
• Überwachen Sie beispielsweise Zahl der erzeugten Rechnungen, technische Fehler und Übertragungsprobleme.
• Legen Sie fest, wann eine Eskalation notwendig ist.
• Definieren Sie einen Prozess für fehlgeschlagene oder zurückgewiesene Rechnungen.
• Dokumentieren Sie relevante Fehlerursachen und deren Behebung.

Feste Grenzwerte wie eine Eskalation ab fünf Prozent Fehlerquote oder eine tägliche Kontrolle sind keine allgemeingültigen Anforderungen. Solche Werte sollten aus dem eigenen Betriebskonzept abgeleitet werden.

Auch ein Fallback muss zum Rechnungsempfänger passen. Eine PDF kann nicht pauschal als Ersatz verwendet werden, wenn für den konkreten Rechnungsvorgang eine strukturierte E-Rechnung oder aufgrund von B2G-Vorgaben ein bestimmtes Format erforderlich ist.

Schritt 4: CII-Syntax und Business Terms verstehen

Die EN 16931 beschreibt fachliche Rechnungsinformationen über sogenannte Business Terms, kurz BT. XRechnung ergänzt und konkretisiert dieses Modell durch die deutsche CIUS.

Bei einer CII-Implementierung werden diese fachlichen Informationen auf Elemente der UN/CEFACT-CII-Struktur abgebildet.

• Verwenden Sie die aktuelle XRechnung-Spezifikation und die zugehörigen Mapping-Unterlagen.
• Arbeiten Sie mit den dort dokumentierten Business Terms und Kardinalitäten.
• Berücksichtigen Sie die verwendeten Codelisten für Länder, Währungen, Steuerkategorien und Mengeneinheiten.
• Verwenden Sie aktuelle Beispielrechnungen und Testsuiten von KoSIT für die technische Umsetzung.
• Leiten Sie XML-Pfade nicht aus vereinfachten Blogbeispielen ab, sondern aus den aktuellen offiziellen Mapping-Unterlagen.

Bei CII werden unter anderem Elemente aus der UN/CEFACT-Cross-Industry-Invoice-Struktur verwendet. Datum, Beträge und andere Werte müssen entsprechend den für die jeweilige Syntax geltenden Regeln formatiert werden.

Kontrolle: Können Sie die wichtigsten Rechnungsdaten von Ihrem fachlichen ERP-Feld über den Business Term bis zum entsprechenden CII-Element nachvollziehen?

Schritt 5: ERP-zu-CII-Mapping erstellen

Das Mapping legt fest, wie Daten aus ERP, Fakturierung oder Vorsystemen auf das semantische Modell der E-Rechnung und anschließend auf die CII-Syntax abgebildet werden.

Eine sinnvolle Mapping-Tabelle kann enthalten:

• Quellsystem
• Quellfeld
• fachliche Bedeutung
• Business Term
• CII-Zielstruktur
• Datentyp
• Kardinalität
• Transformation
• verwendete Codeliste
• Fehlerbehandlung bei fehlenden Daten

Prüfen Sie insbesondere:

• Länderkennzeichen
• Währungscodes
• Steuerkategorien
• Mengeneinheiten
• Rechnungs- und Referenznummern
• Datumsangaben
• Rechnungsbeträge und Steuerberechnung
• Abschläge, Zuschläge und Rabatte
• Gutschriften und besondere Rechnungstypen

Die konkreten XML-Pfade sollten immer aus der aktuell eingesetzten XRechnung- beziehungsweise CII-Spezifikation übernommen werden. Die ursprüngliche Implementierungstabelle mit SAP-Feldnamen und festen XML-Pfaden wurde deshalb bewusst nicht beibehalten.

Kontrolle: Ist jedes für Ihren konkreten Rechnungstyp relevante Pflichtfeld eindeutig einer Datenquelle zugeordnet?

Schritt 6: Validierung implementieren und Fehler behandeln

Technische Validierung kann helfen, fehlerhafte strukturierte Rechnungen vor der Übermittlung zu erkennen. Für XRechnung stellt KoSIT eine Validator-Konfiguration bereit, die sowohl UBL- als auch CII-Dokumente gegen die relevanten Regeln prüfen kann.

Typische technische Prüfebenen umfassen:

• XML-Wohlgeformtheit
• Schema-Prüfung
• Prüfung der EN-16931-Geschäftsregeln
• Prüfung der zusätzlichen XRechnung-Regeln
• Prüfung relevanter Codelisten

Im Betrieb empfiehlt sich:

• Fehlermeldungen verständlich an das zuständige Team weiterzugeben
• Fehler möglichst an der Datenquelle zu korrigieren
• wiederkehrende Ursachen in den Stammdaten oder im Mapping zu beheben
• unterschiedliche Fehlerarten nachvollziehbar zu klassifizieren
• nach Änderungen erneut zu validieren

Eine technische Validierung ist sinnvoll und unterstützt die Fehlervermeidung. Sie ist jedoch nicht gleichbedeutend mit einer vollständigen steuerlichen oder sachlichen Prüfung der Rechnung.

Auch die Aussage „Nur validierte Rechnungen dürfen versendet werden“ ist als allgemeine gesetzliche Vorgabe zu absolut. Unternehmen sollten ihren Prozess jedoch so gestalten, dass bekannte technische Fehler möglichst vor der Übermittlung erkannt werden.

Kontrolle: Kann Ihr System typische Schema- oder Geschäftsregelfehler erkennen und an die zuständige Stelle weitergeben?

Schritt 7: Pilot durchführen und kontrolliert produktiv gehen

Vor einer vollständigen Umstellung empfiehlt sich ein Test mit repräsentativen Rechnungstypen.

• Wählen Sie typische Standard- und Sonderfälle aus.
• Erzeugen Sie die Rechnungen über das finale Mapping.
• Validieren Sie die Dateien mit der für Ihren Prozess vorgesehenen Validator-Konfiguration.
• Testen Sie den vorgesehenen Übertragungsweg.
• Prüfen Sie Rückmeldungen des Empfängers.
• Dokumentieren Sie Fehler und passen Sie Mapping oder Stammdaten an.
• Überwachen Sie den Produktivstart intensiver als den späteren Regelbetrieb.

Eine feste Zahl von zehn bis 30 Pilotrechnungen oder eine vorgeschriebene zweiwöchige Beobachtungsphase gibt es nicht. Umfang und Dauer sollten zur Komplexität der Implementierung passen.

Praxisbeispiel und Anwendung

Ein deutsches Ingenieurbüro stellt regelmäßig Rechnungen an verschiedene öffentliche Auftraggeber. Bislang werden Rechnungsdaten im ERP erzeugt und über unterschiedliche Verfahren an die Empfänger übermittelt.

Das Unternehmen möchte den Prozess stärker standardisieren und prüft, ob die bestehende Systemlandschaft XRechnung in CII erzeugen kann. Finance und IT dokumentieren zunächst die benötigten Rechnungstypen, Empfängeranforderungen und vorhandenen Stammdaten.

Anschließend wird ein Mapping vom ERP auf die relevanten Business Terms erstellt. Mehrere repräsentative Rechnungen werden erzeugt und mit der aktuellen XRechnung-Validator-Konfiguration geprüft. Fehlerhafte Ländercodes und fehlende Referenzdaten werden direkt in den Stammdaten korrigiert.

Nach einem Pilot mit ausgewählten öffentlichen Auftraggebern wird der Prozess schrittweise ausgerollt. Im Anschluss vergleicht das Unternehmen Bearbeitungszeiten, Fehlerfälle und manuellen Nachbearbeitungsaufwand mit dem Ausgangsprozess.

Erst anhand dieser realen Daten lässt sich beurteilen, welche wirtschaftlichen Effekte die Implementierung tatsächlich erzielt hat.

Fortgeschrittene Varianten und Skalierung

ZUGFeRD und XRechnung mit CII gemeinsam betrachten

ZUGFeRD verwendet in geeigneten Profilen ebenfalls strukturierte Rechnungsdaten auf Basis von CII. Dadurch können Teile einer bestehenden CII-Datenaufbereitung gegebenenfalls für unterschiedliche Ausgabeformate genutzt werden.

Eine identische Datei lässt sich jedoch nicht automatisch ohne weitere Prüfung für jeden Anwendungsfall verwenden. XRechnung und ZUGFeRD haben unterschiedliche Profile, Kennzeichnungen und Anforderungen. Deshalb sollten die jeweiligen Ausgaben separat validiert werden.

Mehrländer-Szenarien

Internationale E-Invoicing-Projekte können weitere nationale oder branchenspezifische Anforderungen enthalten. Andere Staaten verwenden teilweise eigene Plattformen, CIUS-Ausprägungen oder Datenformate.

Für jedes Zielland sollten deshalb die aktuell geltenden rechtlichen und technischen Anforderungen separat geprüft werden.

Automatisierte Massenerzeugung

Bei höheren Rechnungsvolumina kann die automatisierte Erzeugung, Validierung und Übertragung von Rechnungen sinnvoll sein. Die technische Umsetzung hängt von der vorhandenen Architektur ab und kann beispielsweise über ERP-Jobs, Middleware oder spezialisierte E-Invoicing-Plattformen erfolgen.

Monitoring sollte dabei insbesondere fehlgeschlagene Erzeugungen, Validierungsfehler und Übertragungsprobleme sichtbar machen.

Kompakte Zusammenfassung

• CII ist eine der von XRechnung unterstützten XML-Syntaxen.
• UBL und CII bilden dasselbe semantische Rechnungsmodell über unterschiedliche XML-Strukturen ab.
• Die aktuelle XRechnung-Versionslinie ist 3.0.x; konkrete Validator-Releases und Regelwerke sollten aktuell geprüft werden.
• Ein Business Case sollte auf eigenen Prozessdaten statt pauschalen Einsparquoten beruhen.
• Rechnungen sind grundsätzlich acht Jahre aufzubewahren.
• Bei E-Rechnungen ist insbesondere der strukturierte Teil in ursprünglicher Form zu erhalten.
• Validierung unterstützt die technische Fehlererkennung, ersetzt aber keine vollständige fachliche Prüfung.
• Rollen, Monitoring und Fehlerbehandlung sollten zum tatsächlichen Betriebsrisiko passen.
• Ein Pilot mit repräsentativen Rechnungen kann Implementierungsprobleme vor dem breiten Rollout sichtbar machen.

Mini-Checkliste

• Geschäftliche Zielsetzung und heutige Prozesskosten dokumentiert
• Relevante Rechnungstypen und Empfänger identifiziert
• Aktuelle XRechnung-Unterlagen und Validator-Konfiguration geprüft
• Entscheidung für CII beziehungsweise UBL anhand der Systemlandschaft getroffen
• ERP- beziehungsweise Quellsystemfelder den relevanten Business Terms zugeordnet
• Codelisten und Stammdaten geprüft
• Aufbewahrung des strukturierten Originals geklärt
• Validierungsprozess eingerichtet
• Fehler- und Eskalationsprozess definiert
• Rollen und Verantwortlichkeiten festgelegt
• Testfälle und Pilot durchgeführt
• Produktivprozess überwacht und anhand realer Daten bewertet

FAQ und Troubleshooting

Sollten wir CII oder UBL wählen?

Das hängt von Ihrer Systemlandschaft und den Anforderungen der jeweiligen Schnittstellen ab. XRechnung unterstützt sowohl UBL als auch CII. Beide Syntaxen bilden das fachliche Modell der EN 16931 beziehungsweise der XRechnung ab, verwenden dafür jedoch unterschiedliche XML-Strukturen.

Wenn Ihr ERP oder Ihre bestehende E-Invoicing-Lösung eine Syntax bereits zuverlässig unterstützt, ist dies ein wichtiges Auswahlkriterium.

Wie stellen wir eine angemessene Aufbewahrung sicher?

Bei E-Rechnungen muss insbesondere der strukturierte Rechnungsteil in seiner ursprünglichen Form erhalten bleiben. Rechnungen sind grundsätzlich acht Jahre aufzubewahren.

Funktionen wie Zugriffskontrollen, Änderungsnachvollziehbarkeit, Backups oder Validierungsprotokolle können den Prozess unterstützen. Welche davon konkret erforderlich sind, muss jedoch im Zusammenhang mit dem gesamten Verfahren betrachtet werden.

Müssen Validierungsprotokolle zwingend mit jeder Rechnung archiviert werden?

Eine pauschale gesetzliche Pflicht, zu jeder E-Rechnung dauerhaft ein vollständiges technisches Validierungsprotokoll zu archivieren, besteht nicht allein aufgrund der E-Rechnung. Solche Protokolle können jedoch für Fehleranalyse, Betriebsnachweis und interne Kontrollen sinnvoll sein.

Was passiert, wenn die Validierung fehlschlägt?

Die Ursache sollte zunächst analysiert werden. Technische Fehler können beispielsweise aus ungültigen XML-Strukturen, fehlenden Pflichtinformationen oder nicht zulässigen Codes entstehen.

In einem gut gestalteten Prozess wird der Fehler an die zuständige Stelle weitergegeben, an der Datenquelle korrigiert und die Rechnung anschließend erneut erzeugt beziehungsweise validiert.

Wie lange dauert eine Implementierung?

Das hängt von Systemlandschaft, Zahl der Rechnungstypen, vorhandenen Schnittstellen und Datenqualität ab. Eine einfache Konfiguration eines bereits geeigneten ERP-Moduls kann erheblich weniger Aufwand verursachen als eine neue Integration mit mehreren Vorsystemen.

Feste Zeiträume wie vier bis acht oder acht bis 16 Wochen sind deshalb keine allgemeingültige Aussage.

Welche XRechnung-Version sollten wir verwenden?

Aktuell wird die Versionslinie XRechnung 3.0.x verwendet. KoSIT veröffentlicht dazu regelmäßig aktualisierte Validator-Konfigurationen und Testsuiten. Für eine Neuimplementierung sollte deshalb nicht nur eine Versionsnummer aus einem älteren Beitrag übernommen, sondern die zum Implementierungszeitpunkt aktuelle Spezifikation und Validator-Konfiguration geprüft werden.

Können alte XRechnung-Dateien weiterhin relevant sein?

Ältere Rechnungen müssen nicht allein deshalb nachträglich in eine neuere XRechnung-Version umgewandelt werden, weil sich der Standard weiterentwickelt. Für neu erzeugte Rechnungen sollten dagegen die aktuell für den jeweiligen Rechnungsempfänger und Übertragungsweg geltenden Vorgaben verwendet werden.

Wie wird die Leitweg-ID gepflegt?

Die Leitweg-ID dient bei bestimmten Rechnungen an öffentliche Auftraggeber der elektronischen Adressierung beziehungsweise Identifikation des Rechnungsempfängers. Ob sie benötigt wird und welchen Wert sie haben muss, sollte anhand der Vorgaben des konkreten öffentlichen Auftraggebers geprüft werden.

Wenn sie regelmäßig benötigt wird, kann es sinnvoll sein, die Leitweg-ID im Kunden- oder Empfängerstamm des ERP zu hinterlegen.

Wie schnell sehen wir wirtschaftliche Ergebnisse?

Das lässt sich nicht seriös mit einem allgemeinen Zeitraum beantworten. Messen Sie vor der Einführung Bearbeitungszeiten, Nacharbeiten und Fehlerfälle und vergleichen Sie diese nach dem Produktivstart mit denselben Kennzahlen.

So entsteht ein belastbarer ROI auf Basis der eigenen Organisation statt einer pauschalen Annahme von beispielsweise zwölf oder 24 Monaten.

Nächster Schritt: Beginnen Sie mit einer Bestandsaufnahme: Welche Rechnungstypen, öffentlichen Auftraggeber und Quellsysteme müssen unterstützt werden? Prüfen Sie anschließend die aktuelle XRechnung-Spezifikation und die passende KoSIT-Validator-Konfiguration. Darauf aufbauend können Finance und IT gemeinsam Mapping, Tests und Betriebsprozess entwickeln.