Kurz gesagt: E-Rechnung CII ist die XML-Darstellung der EN-16931-Norm für elektronische Rechnungen an öffentliche Auftraggeber. Seit Februar 2024 gilt Version 3.0. Dieser Guide zeigt dir die konkrete Implementierung: ROI-Kalkulation, Mapping und Validierung, GoBD-konforme Archivierung, Audit-Trails und operative Betriebsprozesse – damit dein Team sicher live gehen kann.
Der direkte Fahrplan:
Nach diesem Guide kannst du:
Dieser Guide richtet sich an CFOs, Finance-Leiter, IT-Projektmanager und Entscheidungsträger in Unternehmen, die Rechnungen an öffentliche Auftraggeber versenden. Du solltest Grundkenntnisse über E-Rechnung-Beratung haben und Zugang zu ERP-System und Rechnungsmodul besitzen. Idealerweise hast du ein oder zwei Personen aus Finance und IT zur Umsetzung verfügbar. Der Guide behandelt bewusst Wirtschaftlichkeit und operative Stabilität – nicht nur Technik. Was dieser Guide nicht abdeckt: umsatzsteuerliche Detailfragen, länderspezifische CIUS-Profile im Detail oder hundertprozentige Audit-Normierung nach Branchenstandards – GoBD ist der Fokus, spezialisierte Anforderungen müssen zusätzlich geklärt werden.
XRechnung ist der nationale Standard für Rechnungen an deutsche Behörden seit Juni 2017. CII ist die XML-Syntax der EN-16931-Norm – seit Februar 2024 gilt Version 3.0. CII unterscheidet sich von UBL (der zweiten erlaubten Syntax) nur in Namespace und Datumsformat, nicht im Geschäftsinhalt. Ein typischer ROI entsteht durch Automatisierung (45–60 Minuten Zeitersparnis pro Werktag), Fehlerreduktion (von 8 % auf unter 1 %) und reduzierte manuelle Nachverfolgung. Die Implementierung dauert je nach Komplexität 4–16 Wochen. Merke: XRechnung ist der Standard, CII ist die technische Darstellungsform.
Bevor du Geld in die Implementierung investierst, muss der wirtschaftliche Nutzen beziffert werden. Diese Analyse ermöglicht belastbare Entscheidungen und hält sich langfristig, wenn Kostenpositionen regelmäßig überprüft werden. Ohne Business Case fehlt oft das Mandat für Ressourcen und Zeit.
Praxis-Tipp: 150 Rechnungen/Monat × 20 Min. = 50 Stunden aktuell. Nach Automatisierung: 150 × 8 Min. = 20 Stunden. Einsparung: 30 Stunden × 45 EUR = 1.350 EUR/Monat. Fehlerreduktion: von 10 % (15 Fehler) auf 1 % (1,5 Fehler) = 13,5 Fehler × 40 EUR = 540 EUR/Monat. Gesamteinsparung: ca. 1.890 EUR/Monat. Bei 25.000 EUR Implementierungskosten amortisiert sich die Investition in ca. 13 Monaten.
Kontrolle: Kannst du dem CFO eine einseitige ROI-Rechnung zeigen, die Kosten, Einsparungen und Amortisationszeitraum klar macht?
GoBD verlangt revisionssichere Speicherung von Rechnungen, vollständige Audit-Trails und Nachvollziehbarkeit jeder Transaktion. Unvollständige Audit-Trails sind die Hauptursache für Compliance-Risiken. Dieser Schritt muss vor der Programmierung stehen, nicht danach.
Aus Erfahrung: Die größten Compliance-Risiken entstehen, wenn Validierungsprotokolle gelöscht oder Rechnungen nachträglich geändert werden, ohne dass die Änderung dokumentiert ist. Nutze eine unveränderliche Log-Struktur, auch wenn das mehr Speicherplatz kostet. Das zahlt sich im Audit aus.
Kontrolle: Kannst du für eine beliebige Rechnung die komplette Verarbeitungskette (Erzeugung → Validierung → Versand → Feedback) dem Auditor zeigen?
Operative Stabilität entsteht durch klare Verantwortlichkeiten, proaktives Monitoring und etablierte Eskalationsprozesse. Viele Implementierungen scheitern nicht an der Technik, sondern weil unklar ist, wer bei Problemen handelt und wie schnell reagiert wird.
Merke: Ein einfaches tägliches Excel-Dashboard mit 5–10 Kennzahlen wird tatsächlich genutzt. Überkomplexe Monitoring-Tools werden oft ignoriert. Halte es praktisch und fokussiert.
Kontrolle: Sind die Rollen klar verteilt und weiß jeder, wer bei welchem Fehler reagiert?
CII ist XML mit eigenem Namespace und Datumsformat. Business Terms (BT) sind standardisierte Feld-Codes der EN 16931. Jeder BT mappt auf einen festen XML-Pfad. Verständnis hier ist Voraussetzung für fehlerfreies Mapping und verhindert später teure Fehler in der Produktion.
Achtung: CII-Datumsformat ist YYYYMMDD mit format="102". Fehlerhafte Datumsformate sind einer der häufigsten Validierungsfehler. Stelle sicher, dass dein ERP oder deine Schnittstelle dieses Format exakt erzeugt. Ein falscher Bindestrich oder Slash bricht die Validierung.
Kontrolle: Kannst du in einer CII-Beispieldatei drei verschiedene Beträge (Netto, Steuer, Brutto) auf ihren XML-Pfaden lokalisieren?
Das Mapping beschreibt, wie Daten aus dem ERP zu CII-XML-Feldern transformiert werden. Fehler beim Mapping sind Hauptgrund für fehlerhafte Rechnungen. Dieser Schritt ist der zentrale Engineering-Workstream und bestimmt, wie sauber die Implementierung wird.
| ERP-Feld | BT-Code | CII-XML-Pfad | Transformation | Pflichtfeld |
|---|---|---|---|---|
| VBAK-BSTNK | BT-1 | ram:ID | Text, max. 20 Zeichen | Ja |
| VBAK-ERDAT | BT-2 | ram:IssueDateTime | YYYY-MM-DD zu YYYYMMDD, format="102" | Ja |
| VBRK-NETWR | BT-106 | ram:DuePayableAmount | Dezimal, 2 Stellen, Punkt-Separator | Ja |
| ADRC-LAND1 | BT-40 | ram:CountryID | ISO 3166-1-alpha-2 (z. B. DE, FR) | Ja |
Die Tabelle zeigt beispielhafte Zuordnungen. Dein Mapping wird individuell größer, folgt aber diesem Schema. Jeder Eintrag muss vor Go-Live getestet werden. Das Mapping ist ein lebendes Dokument und muss bei jedem ERP-Update überprüft werden.
Kontrolle: Hast du für alle relevanten Rechnungsfelder (mindestens 20 BT-Codes) ein dokumentiertes Mapping mit Test-Validierung?
Validierung prüft, ob eine CII-Datei wohlgeformt ist, dem Schema (XSD) entspricht und alle Geschäftsregeln (Schematron/BR-Codes) erfüllt. Nur validierte Rechnungen dürfen versendet werden. Dieser Schritt ist technisch kritisch und operativ essentiell – hier werden Fehler früh erkannt, bevor sie zu Behörden gehen.
Aus Erfahrung: Die meisten Fehler entstehen durch Stammdaten-Probleme (Adresse leer, Länderkode deprecated, Steuernummer falsch formatiert). Behebe diese Fehler in der ERP-Stammdatenpflege, nicht durch Workarounds in der CII-Erzeugung. Das zahlt sich langfristig aus.
Kontrolle: Validiert eine Test-Rechnung ohne Fehler durch alle drei Validierungsstufen?
Ein Pilot mit wenigen echten Rechnungen reduziert Implementierungsrisiko drastisch. Damit vermeidest du, dass bei Go-Live mit voller Last Fehler auftauchen, die du nicht vorhergesehen hast. Der Pilot ist der letzte Kontrollpunkt vor Production.
Praxis-Tipp: Der Pilot ist nicht nur ein Technik-Test, sondern auch ein Prozess-Test. Prüfe, ob deine Betriebsprozesse (Monitoring, Fehlerbehandlung, Eskalation) tatsächlich funktionieren, bevor es kritisch wird. Nutze den Pilot, um dein Team zu trainieren.
Kontrolle: Sind nach dem Pilot alle Fehler dokumentiert und behoben?
Ein deutsches Ingenieurbüro stellt 80 Rechnungen monatlich an öffentliche Auftraggeber (Kommunen, Bezirksregierungen, Hochschulen). Bisheriges Vorgehen: PDF-Rechnungen mit manueller Nachverfolgung, durchschnittlich 18 Minuten pro Rechnung, Fehlerquote 9 %. ROI-Kalkulation zeigt: Einsparung von ca. 900 EUR/Monat, Implementierungskosten 20k EUR, Amortisationszeitraum 22 Monate. Das Büro entscheidet sich für CII-Implementierung. Nach 8 Wochen (Design 2W, Mapping 2W, Integration 2W, Test 2W) geht der erste Pilot mit 10 Rechnungen live. Alle validieren fehlerfrei. Nach 4 Wochen Pilot wird die volle Rechnungsmenge auf CII umgestellt. Im ersten Produktionsmonat: 3 Fehler (alte ERP-Ländercodes, später in Stammdaten korrigiert). Im zweiten Monat: 0 Fehler. Fehlerquote fällt auf unter 1 %. Zeitaufwand sinkt auf 7 Minuten pro Rechnung. Monatliche Einsparung stabilisiert sich bei 880 EUR. Nach ca. 2 Jahren amortisiert sich die Investition. Zusätzlich: Keine Compliance-Beanstandungen bei der nächsten Betriebsprüfung, weil alle Rechnungen revisionssicher archiviert sind.
ZUGFeRD ist eine hybride PDF mit eingebettetem CII-XML. Wenn du ZUGFeRD einführst, nutzt du intern CII. Erzeugst du die CII-Komponente sauber, kannst du diese nicht nur als ZUGFeRD-PDF verteilen, sondern gleichzeitig als reine XRechnung-CII-Datei versenden. Das spart doppelte Entwicklung und erlaubt dir, je nach Empfänger die passende Variante zu wählen.
Wenn du Rechnungen an Behörden in mehreren Ländern versendest, brauchst du potenziell unterschiedliche CIUS-Profile. Deutschland nutzt XRechnung-CIUS, Frankreich Factur-X, Italien FatturaPA. Der semantische Inhalt ist ähnlich, aber Pflichtfelder und Codelisten unterscheiden sich teilweise erheblich. Setze für jeden Zielmarkt einen eigenen Validator auf und dokumentiere Feldabweichungen.
Bei mehreren hundert Rechnungen pro Monat lohnt sich automatisierte Batch-Erzeugung mit zentraler Validierung. Nutze Job-Scheduling (z. B. Windows Task Scheduler oder Kubernetes CronJob), das nachts läuft, Rechnungsdaten aus dem ERP holt, CII-XML erzeugt, validiert, archiviert und Berichte erzeugt. Lagere Validierungsprotokolle in eine Datenbank aus, um später Fehlertrends schnell zu analysieren.
Das hängt von deiner Systemlandschaft ab. Wenn dein ERP CII besser unterstützt oder wenn du ZUGFeRD intern nutzen möchtest, wähle CII. Der fachliche Inhalt ist identisch. Die Syntaxwahl wirkt sich nur auf Mapping, Tooling und Test aus.
Speichere nicht nur die Rechnung, sondern auch Validierungsprotokoll, Versanddatum, Empfänger und Rückläufer. Alle Daten mit Zeitstempel. Führe eine unveränderliche Log-Datei. Prüfe regelmäßig (mindestens halbjährlich), dass die Archivierungskette nicht gebrochen ist.
Fehlerhafte Rechnungen werden NICHT versendet. Stattdessen wird die Fehlerursache dokumentiert und dem Rechnungswesen per E-Mail mit Fehler-Details mitgeteilt. Das Team korrigiert die Ursache (meist Stammdaten im ERP) und versendet erneut. Das Protokoll zeigt das Abweisen und die Nachbesserung.
Bei einfachen Szenarien (ein Rechnungstyp, bekannte ERP-Schnittstelle): 4–8 Wochen. Bei komplexen Szenarien (mehrere Rechnungstypen, internationale Fehler): 8–16 Wochen. Der Löwenanteil ist Mapping-Design, Stammdaten-Bereinigung und Test, nicht die Programmierung.
Nein. Seit Februar 2024 ist Version 3.0 aktuell. Version 2.3 ist außer Kraft gesetzt. Nutze nur Version 3.0 für Neuimplementierungen. Falls du noch alte Versionen nutzen solltest, plane eine Migration ein.
Die Leitweg-ID ist eine eindeutige ID des öffentlichen Auftraggebers. Erfasse sie als Stammdatum zu jedem Rechnungsempfänger im ERP. Beim Rechnungserzeugen wird sie automatisch eingefügt. Wenn Behörden unterschiedliche Abteilungen haben, können unterschiedliche Leitweg-IDs erforderlich sein – pflege dies in der Organisationshierarchie im ERP.
Zeitersparnis und Fehlerreduktion sind im zweiten Produktionsmonat stabil messbar. ROI-Amortisationszeitraum ist typisch 13–24 Monate je nach Rechnungsvolumen und Fehlerquoten. Der Break-Even-Point wird oft früher erreicht als prognostiziert, weil indirekte Einsparungen (weniger Nachbearbeitung, weniger Compliance-Risiken) hinzukommen.
Nächster Schritt: Beginne mit Schritt 1 und erstelle deinen konkreten ROI-Business-Case. Wenn dein Finance-Team das signiert, hast du ein Mandat für die Implementierung. Danach arbeite parallel an zwei Workstreams: (1) Technisches Mapping und CII-Setup mit IT, (2) Prozess- und Compliance-Design mit Finance und Compliance-Team. Pilot nach 4–6 Wochen. Der Erfolg entsteht durch Klarheit auf beiden Ebenen – wirtschaftlich und operativ.