E-Rechnung: Rechnungseingang sicher automatisieren.

Rechtsstand 2026: Empfangspflicht und Übergangsfristen unterscheiden

Stand 9. September 2026 gilt die E-Rechnung im inländischen B2B-Bereich grundsätzlich für Umsätze nach dem 31. Dezember 2024. Seit 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können; nach den FAQ des Bundesfinanzministeriums reicht dafür rechtlich bereits ein E-Mail-Postfach. Sonderfälle und Ausnahmen des konkreten Umsatzes müssen getrennt geprüft werden.

Für die Ausstellung gelten Übergänge: Bis Ende 2026 kann grundsätzlich noch eine sonstige Rechnung verwendet werden. Für Rechnungsaussteller mit höchstens 800.000 Euro Gesamtumsatz im vorangegangenen Kalenderjahr verlängert sich diese Möglichkeit bis Ende 2027; für bestimmte EDI-Verfahren gilt ebenfalls eine Übergangsfrist bis Ende 2027. Diese Fristen betreffen den Rechnungsausgang und heben die seit 2025 bestehende Empfangsfähigkeit nicht auf.

Der Beitrag ordnet betriebliche und technische Anforderungen ein und ersetzt keine steuerliche oder rechtliche Prüfung des Einzelfalls. Unternehmen sollten insbesondere Leistungsart, Beteiligte, Übergangsregel und Aufbewahrung mit ihrer Steuerberatung beziehungsweise zuständigen Fachstelle klären.

Die E-Rechnung als strukturiertes Original behandeln

Eine E-Rechnung enthält Rechnungsangaben in einem strukturierten elektronischen Format, das elektronische Verarbeitung ermöglicht. Eine reine PDF-Datei gilt deshalb als sonstige Rechnung. Bei einem hybriden Format wie einer zulässigen ZUGFeRD-Ausprägung sind strukturierter Datenteil und Sichtdarstellung miteinander verbunden; bei Abweichungen ist nach der BMF-Einordnung der strukturierte Teil maßgeblich.

Der Eingang sollte die Originaldatei daher unverändert übernehmen und ihr sofort eine eindeutige Vorgangs-ID, einen Eingangszeitpunkt sowie einen technischen Fingerabdruck zuordnen. Eine Visualisierung für Mitarbeitende ist eine abgeleitete Ansicht, nicht das führende Original. Korrekturen werden als neuer, nachvollziehbar verknüpfter Beleg verarbeitet, statt die empfangene Datei zu überschreiben.

• Originaldatei unverändert und zugriffsgeschützt übernehmen
• Eingangskanal, Zeitpunkt, Absenderbezug und Vorgangs-ID protokollieren
• strukturierte Daten und erzeugte Sichtansicht eindeutig derselben Version zuordnen
• Korrektur, Storno und Ersatzrechnung als eigene Belege verknüpfen

Eingangskanäle in eine kontrollierte Annahmezone führen

E-Mail, Portal, API oder ein vereinbarter Übertragungsweg können E-Rechnungen in denselben fachlichen Prozess einspeisen. Entscheidend ist nicht ein einzelner Kanal, sondern eine zentrale Annahmezone: Sie begrenzt Dateitypen und Größen, prüft technische Risiken, ordnet den Eingang einem Unternehmensteil zu und verhindert, dass Anhänge ungeprüft direkt in ERP oder DMS geschrieben werden.

Der Kanal darf noch keine Lieferantenidentität beweisen. Absenderadresse, Routingdaten und Angaben in der Rechnung sind Hinweise, die mit verlässlichen Stammdaten abgeglichen werden. Unbekannte Absender, unerwartete Bankverbindungen oder widersprüchliche Unternehmenskennungen benötigen einen eigenen Klärungsgrund, ohne das Original zu verlieren.

Technische Validierung und fachliche Rechnungsprüfung trennen

Die technische Prüfung klärt zunächst, ob Syntax, Pflichtinformationen und definierte Geschäftsregeln des verwendeten Formats eingehalten werden. XRechnung basiert auf dem semantischen Datenmodell und den Geschäftsregeln der EN 16931; die KoSIT stellt dafür unter anderem eine Validator-Konfiguration, Testfälle und Beispiele bereit. Prüfkomponenten und Regelstände verändern sich, deshalb gehören Version und Ergebnis in den Nachweis.

Das BMF empfiehlt eine Validierung, stellt aber zugleich klar, dass ein positives technisches Ergebnis nicht die materiell-rechtliche Richtigkeit aller Angaben bestätigt. Der kaufmännische Prozess muss zusätzlich Lieferant, Bestell- oder Vertragsbezug, Leistung beziehungsweise Wareneingang, Beträge, Steuern, Zahlungsdaten und Freigaberegeln prüfen. Ein technisch valider Datensatz kann fachlich falsch sein; eine fachlich plausible Rechnung kann wegen eines Formatfehlers dennoch keine E-Rechnung im gesetzlichen Sinn sein.

• Stufe 1: Dateiintegrität, zulässige Syntax und lesbarer strukturierter Inhalt
• Stufe 2: EN-16931- beziehungsweise formatspezifische Pflicht- und Geschäftsregeln
• Stufe 3: Lieferant, Dublette, Bestellung, Vertrag und Leistungsbezug
• Stufe 4: Beträge, Steuerlogik, Kontierung, Freigabe und Zahlungsziel

Sieben Stationen vom Eingang bis zum abgeschlossenen Vorgang

Ein durchgängiger Prozess braucht mehr als einen Importknopf. Jede Station erhält einen fachlichen Zustand, ein eindeutiges Ergebnis und eine zulässige Folgeaktion. So bleibt sichtbar, ob eine Rechnung nur angenommen, technisch valide, fachlich geprüft, freigegeben, gebucht oder archiviert ist.

Die Übergabe an das Zielsystem erfolgt idempotent: Vor einer Wiederholung prüft die Prozessschicht, ob derselbe Beleg bereits angelegt oder gebucht wurde. Nach der Buchung wird nicht nur eine technische Antwort, sondern die fachliche Belegnummer oder ein gleichwertiger Zielstatus zurückgeführt. Erst die Abstimmung zwischen Eingang, ERP und Archiv schließt den Vorgang ab.

• 1. annehmen, isolieren und Eingang mit Vorgangs-ID protokollieren
• 2. strukturiertes Original unverändert sichern und visualisierbar machen
• 3. Format, Syntax und Geschäftsregeln mit dokumentierter Version validieren
• 4. Lieferant, Dublette, Bestellung, Leistung und Beträge abgleichen
• 5. Standardfall automatisch freigeben oder begründete Aufgabe zuweisen
• 6. idempotent an ERP beziehungsweise Finanzsystem übergeben und Ergebnis bestätigen
• 7. Original, Prüfstatus, Freigabe und Buchungsbezug im DMS oder Archiv verbinden

ERP, Workflow und DMS mit eindeutigen Systemrollen verbinden

Das ERP oder Finanzsystem führt typischerweise Lieferantenstamm, Bestellung, Wareneingang, Kontierung und Buchungszustand. Eine Workflow-Schicht koordiniert Regeln, Aufgaben, Fristen und Wiederanlauf. Das DMS beziehungsweise Archiv bewahrt Originaldatei, Dokumentversion, fachlichen Bezug und Nachweis. Die konkrete Verteilung kann anders aussehen, muss aber pro Objekt und Status ausdrücklich festgelegt werden.

Gemeinsame Schlüssel verbinden die Stationen: interne Vorgangs-ID, externe Rechnungsnummer, Lieferantenkennung, Bestell- oder Vertragsnummer sowie die Zielsystem-ID. Eine E-Mail-ID allein ist dafür ungeeignet. Schreibrechte werden je Station begrenzt; ein Validator benötigt keine Berechtigung, Stammdaten oder Buchungen zu ändern.

Ausnahmen mit Grundcode, Besitzer und sicherem Wiederanlauf bearbeiten

Ungültige XML-Dateien, unbekannte Lieferanten, doppelte Rechnungsnummern, fehlende Bestellbezüge, Mengenabweichungen oder ein nicht erreichbares ERP sind unterschiedliche Fälle. Ein Sammelstatus wie ‚Fehler‘ verhindert Priorisierung und Ursachenanalyse. Jeder Klärungsfall benötigt deshalb Original, erkannte Werte, verletzte Regel, bisherige Aktionen, zuständiges Team und eine konkrete nächste Entscheidung.

Nach einer Korrektur setzt der Vorgang an der letzten sicheren Station fort. Bereits erfolgreiche Schritte dürfen nicht unkontrolliert erneut ausgeführt werden. Bei fachlich fehlerhaften Rechnungen bleibt außerdem nachvollziehbar, ob der Beleg abgelehnt, eine Korrektur angefordert oder eine Freigabe bewusst verweigert wurde.

• Formatfehler: Lieferant informieren und Original samt Prüfbericht erhalten
• Dublettenverdacht: Beleg- und Lieferantenschlüssel vor einer Buchung vergleichen
• Bestellabweichung: zuständige Fachrolle mit Position und Toleranz anzeigen
• Zielsystemausfall: begrenzt wiederholen, Ergebnis abfragen und danach eskalieren
• Korrekturbeleg: Beziehung zum Ursprungsbeleg und offene Wirkung dokumentieren

Aufbewahrung und Sicherheit als Teil der Prozesskette planen

Nach den BMF-FAQ ist mindestens der strukturierte Teil der E-Rechnung acht Jahre unverändert in seiner ursprünglichen Form aufzubewahren. Für den konkreten Aufbewahrungsumfang, ergänzende Unterlagen und weitere handels- oder steuerrechtliche Anforderungen sind die jeweils geltenden Vorgaben maßgeblich. Eine alleinige PDF-Visualisierung ersetzt den strukturierten Originalteil nicht.

Technisch sollten Original, Prüfbericht, Freigabe und Buchungsreferenz vor unbemerkter Veränderung geschützt und über Rollen abrufbar sein. Dienstkonten erhalten nur die für ihre Station nötigen Rechte. Protokolle verbinden Regelversion, Entscheidung und Systemaktion, ohne unnötige Rechnungsinhalte in verteilten Logs zu vervielfachen.

Automatisierung mit Abschluss- und Ausnahmequalität messen

Eine hohe Automatisierungsquote allein sagt wenig aus. Der Nenner muss benannt werden: alle Eingänge, nur erkannte E-Rechnungen oder nur technisch valide Standardfälle. Gleichzeitig muss die Abstimmung zeigen, ob angenommene Rechnungen gebucht, bewusst abgelehnt oder als offene Ausnahme vorhanden sind.

Besonders nützlich sind Kennzahlen entlang der Prüfgrenzen. Sie zeigen, ob Probleme aus einem Formatwechsel, Stammdaten, Bestellprozess, Freigaben oder einer Schnittstelle stammen. Damit wird nicht nur schneller gearbeitet, sondern die Ursache wiederkehrender manueller Arbeit sichtbar.

• Anteil erkannter und technisch valider E-Rechnungen je Format und Regelversion
• fachliche Ausnahmequote nach Grundcode, Lieferant und Prozessstufe
• Dubletten, verhinderte Fehlbuchungen und nachträgliche Korrekturen
• Durchlaufzeit sowie Bestand und Alter der Klärungswarteschlange
• Abstimmung zwischen angenommenen, gebuchten, abgelehnten und offenen Vorgängen

In 90 Tagen von realen Belegen zur kontrollierten Automatisierungszone

Der Einstieg beginnt mit realen Eingangsvarianten und einer schmalen Standardklasse, nicht mit einer pauschalen Vollautomatisierung. Testbestände sollten XRechnung, zulässige hybride Formate, fehlerhafte Dateien, Korrekturen und typische Bestellabweichungen abdecken, ohne produktive Daten unkontrolliert zu kopieren.

Vor der ersten automatischen Buchung läuft die Entscheidung im Shadow Mode mit. Fachbearbeitung und Systemvorschlag werden verglichen, Ausnahmen nach Ursache geordnet und Regeln angepasst. Erst danach wird eine begrenzte Fallklasse freigegeben; Versionswechsel bei Validator, ERP-Schnittstelle oder Stammdaten benötigen Regressionstests und eine Rückfallmöglichkeit.

• 0–30 Tage: Kanäle, Formate, Systemrollen, Originalablage und Fehlerklassen erfassen
• 30–60 Tage: Validierung, fachliche Regeln, Schlüssel, Ausnahmeoberfläche und Tests umsetzen
• 60–90 Tage: Shadow Mode, Abstimmung, Berechtigungsprüfung und fachliche Abnahme
• danach: Standardzone schrittweise freigeben und nur anhand belegter Qualität erweitern