E-Rechnungs-ERP-Integration: Rechnungsdaten sauber koppeln
E-Rechnungs-ERP-Integration: was 2027 ansteht
Ein ERP-System, also die Software, in der Aufträge, Bestellungen und Stammdaten zusammenlaufen, war nie für maschinenlesbare Rechnungen gebaut. International heißt das Thema E-Invoicing.
E-Rechnungs-ERP-Integration bezeichnet die Kopplung zwischen einem betriebswirtschaftlichen System und dem Rechnungsweg. Sie wandelt Rechnungsdaten aus dem führenden System in ein strukturiertes Format nach der europäischen Norm EN 16931 um, übergibt sie an den Versandkanal und ordnet eingehende Rechnungen automatisch den passenden Vorgängen zu. Die Buchhaltungslogik selbst bleibt dabei unverändert.
Wie dringend das ist, zeigt der Abstand zwischen Frist und Praxis. Nach den Fristen des Bundesfinanzministeriums zur E-Rechnung müssen inländische Unternehmen seit dem 1. Januar 2025 E-Rechnungen empfangen können. Eine Erhebung unter 502 Unternehmen ergab im Juni 2026, dass ein Drittel noch nie eine strukturierte Rechnung versendet hat und 21 Prozent mit Textverarbeitung oder Tabellen arbeiten.
Ab welchem Umsatz die Pflicht greift
Die Ausstellungspflicht kommt nicht auf einen Schlag, sondern in Stufen. Wer sie kennt, terminiert das Projekt, statt es zu verschieben. Der Empfang ist längst geregelt, der Versand folgt.
- Seit 01.01.2025: alle inländischen Unternehmen müssen E-Rechnungen empfangen können
- Bis 31.12.2026: Papier und PDF bleiben beim Versand zulässig
- Ab 01.01.2027: Ausstellungspflicht bei mehr als 800.000 Euro Vorjahresumsatz
- Ab 01.01.2028: Ausstellungspflicht für alle übrigen Unternehmen
- Bis Ende 2027: bestehende EDI-Verfahren bleiben übergangsweise nutzbar
Diese Staffelung verschiebt den Aufwand, sie senkt ihn nicht. Ein Unternehmen knapp unter der Umsatzgrenze gewinnt zwölf Monate und braucht dieselbe Anbindung, ob der Versand später über das Peppol-Netzwerk läuft oder über einen anderen Kanal. Bei vielen kleinen Lieferanten schlägt die Staffelung zuerst auf der Eingangsseite durch. Dort entscheidet nicht die eigene Frist, sondern die des Rechnungsstellers. Das trifft auch Vereine mit unternehmerischem Bereich, deren eigene Ausstellungspflicht erst 2028 beginnt.
Muss ein ERP E-Rechnungen selbst erzeugen?
Nein, und diese Antwort spart oft fünfstellige Beträge. Das führende System muss die Daten liefern, nicht das Format. Die strukturierte Rechnung entsteht in einer Schicht davor, was auch älteren Systemen ohne Herstellerupdate einen Weg offen hält. Genau diese Aufgabe, zwischen zwei Systemen zu übersetzen und zu vermitteln, erfüllt Middleware seit jeher.
Was der Empfang seit 2025 verlangt
Eine E-Rechnung zu empfangen heißt mehr als eine E-Mail-Adresse. Der XML-Datensatz, im Behördenverkehr eine XRechnung, muss gelesen, geprüft und revisionssicher abgelegt werden, und zwar so, dass eine spätere Betriebsprüfung den Weg nachvollziehen kann. Genau diese Eingangsrechnungsverarbeitung haben viele Unternehmen formal erfüllt und drucken den Anhang trotzdem aus. Damit ist die Pflicht erfüllt und der Nutzen verschenkt. Für Rechnungen an den Bund kommt derselbe Datensatz zusätzlich über die OZG-konforme Rechnungseingangsplattform herein.
Wie Rechnungsdaten das Bestandssystem verlassen
Der Weg nach draußen ist der technisch einfachere Teil jeder E-Rechnungs-ERP-Integration. Die Rechnungsdaten liegen bereits strukturiert im System, sie müssen nur in eine normierte Form gebracht und übergeben werden. Für die Entwicklung von Schnittstellen ist das Alltagsgeschäft. Schwierig wird es dort, wo das gewachsene System Felder nicht kennt, die die Norm verlangt.
Konvertieren statt am Kernsystem operieren
Zwei Wege führen zum Ziel, mit sehr unterschiedlichem Risiko. Der erste rüstet das führende System selbst um, meist über ein Herstellermodul. Der zweite setzt eine Konvertierungsschicht davor, die Daten abholt, ins Zielformat übersetzt und weitergibt.
Der zweite Weg hält das Kernsystem unangetastet. Ein Fehler in der Konvertierung legt dann keine Auftragsabwicklung lahm, sondern nur den Rechnungsversand, und er lässt sich isoliert beheben. Bei wenigen Systemen genügt dafür eine gebuchte Integrationsplattform aus der Cloud, bei vielen und eigenwilligen Formaten trägt eine eigene Lösung länger. Der Unterschied zeigt sich meist erst, wenn ein Format seine Version wechselt.
Woran das Mapping der Stammdaten scheitert
Mapping bedeutet, jedes Feld der Norm einem Feld im Bestandssystem zuzuordnen. Klingt mechanisch, ist es aber selten. Die Norm verlangt Angaben, die in gewachsenen Systemen entweder fehlen, uneinheitlich gepflegt sind oder in einem Freitextfeld stehen. Dieselben Fallstricke treten bei jeder Form von ERP-Schnittstellen auf, beim Rechnungsweg nur früher, weil der Empfänger maschinell prüft.
❗ Steuersätze, die als Text statt als Schlüssel hinterlegt sind
❗ Kundennummern, die je nach Vertriebsweg unterschiedlich aufgebaut sind
❗ Zahlungsbedingungen, die nur im Kommentarfeld stehen
❗ Einheiten, die nicht dem international vereinbarten Schlüsselverzeichnis folgen
❗ Rechnungsempfänger, die von der Lieferadresse abweichen und nicht getrennt geführt werden
Jeder dieser Punkte lässt eine Prüfung fehlschlagen, und zwar erst beim Empfänger. Deshalb gehört die Bereinigung der Stammdaten vor die E-Rechnungs-ERP-Integration, nicht danach.
Pflichtfelder, die im ERP fehlen
Manche Angaben entstehen erst durch den Rechnungsweg. Eine Käuferreferenz etwa, die der Empfänger vorgibt, hat im eigenen System keinen natürlichen Ort. Solche Felder werden entweder als Erweiterung angelegt oder in der Konvertierungsschicht ergänzt. Die zweite Variante ist schneller, verlagert die Pflege aber aus der Fachabteilung.
Digitaler Rechnungseingang ohne Abtippen
Der digitale Rechnungseingang ist der teurere Teil und wird regelmäßig unterschätzt. Eine E-Rechnung zu empfangen kostet fast nichts, sie richtig zuzuordnen dagegen viel. Genau hier entscheidet sich, ob eine E-Rechnungs-ERP-Integration Geld spart oder nur Papier ersetzt.
Wie findet eine Rechnung zur richtigen Bestellung?
Über einen Abgleich mehrerer Merkmale, nicht über ein einzelnes. Ein digitaler Rechnungseingang vergleicht die Daten mit offenen Bestellungen und Wareneingängen und schlägt die wahrscheinlichste Zuordnung vor. Je sauberer die Referenzen gepflegt sind, desto häufiger stimmt sie ohne Zutun.
Vier Merkmale tragen den Abgleich:
- Bestellnummer oder Auftragsreferenz aus dem strukturierten Datensatz
- Lieferantenkennung, abgeglichen gegen den Kreditorenstamm
- Positionsdaten wie Menge, Einheit und Einzelpreis
- Wareneingangsbeleg, sofern das Verfahren ihn vorsieht
Fehlt die Bestellnummer, greift der Abgleich über die übrigen Merkmale und liefert einen Vorschlag statt einer Zuordnung. Der Anteil solcher Vorschläge ist die eigentliche Kennzahl im Rechnungsworkflow, weil jeder davon einen Menschen kostet.
Was einen Rechnungsworkflow ins Stocken bringt
Ein Rechnungsworkflow scheitert selten an der Technik, sondern an Fällen, die im Konzept nicht vorkamen. Gutschriften, Teillieferungen, Sammelrechnungen über mehrere Bestellungen, Rechnungen ohne vorherige Bestellung: Jede dieser Formen braucht im Rechnungsworkflow eine eigene Regel, sonst landet sie im Fehlerkorb.
Vor der Buchung steht in jeder Rechnungseingangsverarbeitung die technische Prüfung. Eine E-Rechnung zu validieren heißt zu kontrollieren, ob die XML-Rechnung dem Schema entspricht, ob Beträge und Steuer rechnerisch zusammenpassen und ob der Beleg nicht schon einmal eingegangen ist. Diese Prüfung ist etwas anderes als die Freigabe, bei der eine Person die sachliche Richtigkeit bestätigt. Die Trennung lohnt sich, weil beide Teile unterschiedliche Fehler finden.
E-Rechnungs-ERP-Integration, die den Wechsel überlebt
Eine E-Rechnungs-ERP-Integration entsteht meist unter Termindruck und läuft danach zehn Jahre. Damit stellt sich früh eine Frage, die im Projekt gern hinten runterfällt: Was passiert mit dieser Schicht, wenn das führende System getauscht wird? Vier Punkte zeigen schon im Entwurf, wie haltbar sie ist.
- Lässt sich das Zielformat wechseln, ohne die Datenübergabe anzufassen?
- Steht die Feldzuordnung als Konfiguration bereit oder als Programmcode?
- Werden Fehlerfälle protokolliert und ohne Systemzugriff auswertbar abgelegt?
- Läuft die Schicht weiter, wenn das führende System kurzzeitig ausfällt?
Ein Nein ist kein Ausschlusskriterium, sondern eine bewusste Verkürzung, die später Geld kostet. Im Mittelstand entstehen daraus meist Erweiterungen statt Ablösungen, was für Softwarelösungen für kleine und mittlere Unternehmen auch sonst gilt.
Rechnungsworkflow und Systemwechsel zusammendenken
Eine E-Rechnungs-ERP-Integration überlebt den Wechsel, wenn sie nicht an den Interna des alten Systems hängt. Statt auf Datenbanktabellen zuzugreifen, arbeitet sie gegen eine definierte Übergabe. Der Aufwand dafür ist beim Bau gering und beim Wechsel entscheidend. Ob eine einzelne Schnittstelle genügt oder eine vermittelnde Schicht nötig wird, entscheidet die Zahl der beteiligten Systeme, und dort verläuft die Grenze zwischen Middleware und API.
TenMedia baut genau diese Schicht: Datenübergabe aus dem Bestandssystem, Feldzuordnung auf die Norm und die Zuordnungslogik im Rechnungseingang, ohne Eingriff in die Buchhaltungslogik. Beim Datenbankumzug einer Warenwirtschaft mit Onlineshop trug dieselbe Trennung zwischen kaufmännischem System und Vorsystem. Für ältere Systeme ohne Herstellerupdate hält das oft die Frist. Eine tragfähige E-Rechnungs-ERP-Integration entsteht nicht im Rechnungsmodul, sondern zwischen den Systemen.
