E-Rechnungspflicht 2027: ERP-Shop-Schnittstelle

Die verpflichtende E-Rechnung im inländischen B2B-Verkehr wurde mit dem Wachstumschancengesetz vom März 2024 eingeführt und richtet sich an der europäischen Initiative VAT in the Digital Age (ViDA) aus (EDICOM). Der Gesetzgeber hat die Einführung gestaffelt, damit Unternehmen ihre Prozesse und Systeme schrittweise umstellen können. Wichtig ist die Unterscheidung zwischen Empfangspflicht und Ausstellungspflicht: Der Empfang ist bereits Pflicht, das Ausstellen wird erst später verbindlich.

Seit dem 1. Januar 2025 muss jedes inländische Unternehmen E-Rechnungen nach EN 16931 empfangen und verarbeiten können -- ein Empfänger darf eine konforme E-Rechnung nicht mehr ablehnen (EDICOM). Für das Ausstellen gilt eine Übergangsfrist: Bis zum 31. Dezember 2026 dürfen alle Unternehmen weiterhin Papier- oder PDF-Rechnungen versenden, Letztere mit Zustimmung des Empfängers (Bundesfinanzministerium). Ab dem 1. Januar 2027 entfällt diese Erleichterung für Unternehmen mit einem Vorjahresumsatz über 800.000 Euro -- sie müssen dann strukturierte E-Rechnungen ausstellen (DATEV). Ab dem 1. Januar 2028 sind schließlich alle inländischen B2B-Unternehmen zur Ausstellung verpflichtet (Bundesfinanzministerium).

Eine weitere Erleichterung betrifft Kleinbetragsrechnungen: Für Rechnungen mit einem Bruttobetrag bis 250 Euro besteht keine Pflicht zur strukturierten E-Rechnung (Bundesfinanzministerium). Ebenso bleiben etablierte EDI-Verfahren, die nicht vollständig dem E-Rechnungsstandard entsprechen, übergangsweise bis Ende 2027 zulässig, sofern sich die Beteiligten auf das Format einigen (Bundesfinanzministerium). Wie sich klassische EDI-Strecken in eine moderne Architektur einbinden lassen, beschreibt unser Beitrag zur EDI-Anbindung mit EDIFACT.

Eine E-Rechnung im Sinne des Gesetzes liegt vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und elektronisch weiterverarbeitet werden kann und der europäischen Normenreihe EN 16931 entspricht (Bundesfinanzministerium). In Deutschland erfüllen vor allem zwei Formate diese Anforderung: XRechnung als reines XML-Format und ZUGFeRD als hybrides Format aus Version 2.0.1 -- mit Ausnahme der Profile MINIMUM und BASIC-WL (Bundesfinanzministerium). Beide werden von DATEV als konforme Standards genannt (DATEV).

XRechnung ist ein rein strukturierter Datensatz: Eine XML-Datei nach EN 16931 ohne menschenlesbaren Sichtbeleg. Sie wird über die Syntaxvarianten UBL oder CII abgebildet und ist vollständig maschinenlesbar. Ein Mensch braucht einen Viewer, um die Rechnung zu lesen. ZUGFeRD dagegen ist ein hybrides Format: Eine PDF/A-3-Datei mit eingebettetem XML-Datensatz. Der Empfänger sieht ein gewohntes PDF, die Buchhaltungssoftware liest parallel die strukturierten Daten aus. Damit verbindet ZUGFeRD die Lesbarkeit für Menschen mit der maschinellen Verarbeitbarkeit.

Die Verbreitung der E-Rechnung wächst, aber viele Unternehmen sind noch nicht durchgängig aufgestellt. Inzwischen versenden 43 Prozent der Unternehmen E-Rechnungen, und weniger als die Hälfte (45 Prozent) kann Rechnungen überhaupt als E-Rechnung empfangen (Bitkom). Gleichzeitig empfangen nahezu alle Unternehmen (96 Prozent) Rechnungen weiterhin per E-Mail (Bitkom) -- ein deutliches Zeichen dafür, dass der Medienbruch zwischen PDF und strukturiertem Datensatz in der Praxis noch dominiert. Bei ausgehenden Rechnungen nutzen 55 Prozent der Unternehmen die E-Rechnung bereits, davon allerdings nur ein knappes Drittel (30 Prozent) häufig (Bitkom).

Im E-Commerce fallen pro Tag schnell hunderte Belege an. Diese manuell in ein konformes Format zu bringen, ist weder wirtschaftlich noch verlässlich machbar und bindet wertvolle Arbeitszeit. Eine ERP-Shop-Schnittstelle automatisiert den gesamten Weg: Sobald eine Bestellung abgeschlossen ist, werden die Positionsdaten, Steuersätze, Adressen und Beträge aus dem Shop ausgelesen, im ERP zu einer Rechnung mit korrekter Kontierung verarbeitet und als ZUGFeRD- oder XRechnung-Beleg erzeugt. Der strukturierte XML-Datensatz wandert anschließend GoBD-konform in die DATEV-Buchhaltung -- ohne dass jemand ein PDF abtippt oder Felder manuell überträgt.

Der Kern jeder E-Rechnung-Schnittstelle ist ein sauberer, nachvollziehbarer Datenfluss. Er beginnt bei der Bestellung im Shop und endet beim revisionssicher abgelegten Buchungsbeleg in DATEV. Dazwischen liegen mehrere Verarbeitungsschritte, die jeweils klar abgegrenzt und protokolliert sein müssen, damit die Belegkette lückenlos bleibt.

Das Herzstück dieses Ablaufs ist das Mapping zwischen Shop-, ERP- und Buchhaltungsfeldern. Welche Position auf welches Erlöskonto läuft, welcher Steuerschlüssel bei innergemeinschaftlichen Lieferungen greift und wie Versandkosten verbucht werden -- all das muss einmalig sauber definiert werden. Wie ein solches Feld-Mapping methodisch aufgebaut wird, vertieft unser Beitrag zum Daten-Mapping zwischen ERP und Shop. Für den anschließenden Abgleich der Zahlungseingänge mit den offenen Posten lohnt ein Blick auf die Payment Reconciliation im ERP-Abgleich.

Ein oft unterschätzter Punkt ist die eindeutige Referenzierung. Jeder Beleg, der den Weg vom Shop über das ERP bis zu DATEV nimmt, braucht eine durchgängige Belegnummer und eine Verknüpfung zur ursprünglichen Bestellung. Nur so lassen sich Rechnung, Gutschrift und Zahlung später zweifelsfrei demselben Geschäftsvorfall zuordnen. Die Schnittstelle hält dafür eine Zuordnungstabelle vor, die Shop-Bestellnummer, ERP-Belegnummer und DATEV-Referenz miteinander verbindet. Wird eine Bestellung storniert oder teilweise retourniert, erzeugt die Schnittstelle einen korrespondierenden Gutschriftbeleg, der über dieselbe Referenz auf den Ursprungsbeleg verweist -- ein zentraler Baustein für eine prüffeste Belegkette.

Auch die Frage von Echtzeit gegenüber Batch entscheidet sich am Datenfluss. Bei moderatem Bestellvolumen genügt in der Regel ein Tageslauf, der alle Belege gesammelt erzeugt und übergibt. Wächst das Volumen oder sollen Belege unmittelbar nach Bestellabschluss bereitstehen, bietet sich die ereignisgesteuerte Variante an: Ein abgeschlossener Auftrag löst sofort die Erzeugung und Validierung des E-Rechnung-Belegs aus. Beide Ansätze lassen sich in derselben Middleware abbilden, sodass ein Wechsel von Batch zu Echtzeit später meist ohne Neubau möglich bleibt. Entscheidend ist, dass jeder Schritt -- Auslesen, Erzeugen, Validieren, Übergeben -- protokolliert wird und ein fehlerhafter Beleg nicht stillschweigend verloren geht, sondern in einer Wiedervorlage landet, die der Buchhalter gezielt nachbearbeiten kann.

Mit der E-Rechnung ändern sich auch die Anforderungen an die Aufbewahrung. Eingehende elektronische Belege müssen im empfangenen Format archiviert werden -- eine E-Rechnung als XML darf also nicht in ein PDF umgewandelt und nur dieses gespeichert werden (DATEV). Maßgeblich ist der strukturierte Teil, etwa der XML-Datensatz. Bei hybriden ZUGFeRD-Belegen ist der PDF-Teil nur dann zusätzlich aufzubewahren, wenn er steuerlich relevante Zusatzinformationen enthält, die im XML nicht abgebildet sind (DATEV).

Die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form) verlangen eine lückenlose, unveränderbare und nachvollziehbare Belegkette. Eine automatisierte Schnittstelle erfüllt das systematisch: Jeder Verarbeitungsschritt wird mit Zeitstempel protokolliert, jeder Beleg erhält eine eindeutige Referenz, und der Originaldatensatz wird revisionssicher abgelegt. Dieses Protokoll dient bei einer Betriebsprüfung als Nachweis für die ordnungsgemäße Verarbeitung.

In der Praxis bedeutet das, die Archivierung von Anfang an in den Datenfluss einzuplanen statt sie als nachgelagerten Schritt zu behandeln. Sobald die Schnittstelle einen Beleg erzeugt hat, legt sie den XML-Datensatz in einem revisionssicheren Speicher ab und vermerkt Zeitpunkt, Format und Profil. Auch eingehende E-Rechnungen von Lieferanten unterliegen derselben Pflicht: Sie sind im empfangenen Format aufzubewahren, nicht als ausgedrucktes oder konvertiertes Abbild. Eine durchdachte Schnittstelle deckt daher beide Richtungen ab -- das Erzeugen ausgehender Belege ebenso wie das strukturierte Ablegen eingehender E-Rechnungen. So bleibt die Belegkette über den gesamten Geschäftsverkehr hinweg konsistent und nachvollziehbar, was bei einer späteren Prüfung Zeit und Diskussionen spart.

Die Erfahrung aus Integrationsprojekten zeigt wiederkehrende Stolpersteine. Wer sie von Anfang an kennt, vermeidet teure Nacharbeit kurz vor dem Stichtag. Die häufigsten Probleme entstehen nicht in der Technik, sondern in der sauberen Abbildung der umsatzsteuerlichen Logik und der Empfänger-spezifischen Anforderungen.

Besonders die korrekte Steuerlogik verdient Aufmerksamkeit. Die Schnittstelle muss für jeden Beleg den passenden Steuerschlüssel ermitteln -- basierend auf Lieferland, Kundenstatus (B2B oder B2C) und der Gültigkeit der USt-IdNr. Diese Logik gehört in eine zentrale Middleware, damit sie konsistent für alle Verkaufskanäle greift und bei Gesetzesänderungen an einer Stelle gepflegt werden kann.

Eine E-Rechnung-Schnittstelle lässt sich strukturiert in überschaubarer Zeit umsetzen. Der wichtigste Erfolgsfaktor ist die frühe Einbindung des Steuerberaters, der das Kontenmapping und die Steuerschlüssel definiert. Wer die Umsetzung deutlich vor dem jeweiligen Stichtag startet, gewinnt Zeit für einen risikoarmen Parallelbetrieb.

Händler, die ihre E-Rechnung-Schnittstelle in eine größere Integrationsstrategie einbetten möchten, finden weiterführende Ansätze in unseren Beiträgen zur SAP Integration Suite und Clean-Core-Shop-Anbindung sowie zur Migration auf den Dynamics 365 BC API-v2-Shop-Connector. Beide zeigen, wie sich die Rechnungslogik sauber in moderne ERP-Architekturen einfügt.