E-Rechnung ins ERP integrieren, ohne Schnittstellenbruch

Auf dieser Seite

• Ausgangslage: Was im typischen KMU-ERP schon steckt
• Die Formate im technischen Detail
• XRechnung (reines XML)
• ZUGFeRD 2.4 / Factur-X 1.08 (Hybrid-PDF)
• Profile: Nicht jedes Profil ist ein gültiger Steuerbeleg
• Validierungsarchitektur: Drei Schichten, bevor die Rechnung ins ERP kommt
• Integrationspfade: Postfach-first, dann API
• Stufe 1: Postfach-first (kein API-Vertrag nötig)
• Stufe 2: REST-API-Integration
• Stufe 3: Peppol Access Point
• Feldmapping: Die häufigsten Stolperstellen
• Migration ohne Big Bang: Der Stufenplan
• Phase 1: Empfang zuerst (sofort möglich)
• Phase 2: Ausgangsrechnungen pilotieren (2026)
• Phase 3: Rollout und Automatisierung
• Pilot-Checkliste 2026
• Was der Dienst technisch übernimmt

Für ERP-Verantwortliche und IT-Berater, die nicht „was bis wann" wissen wollen, sondern wie der Stack technisch aussieht: Welches Format, welches Profil, welche Validierungsschichten, welcher Integrationspfad und wie eine Pilotphase noch 2026 ohne Testmonate-Risiko gelingt.

Überblick für Entscheider und Buchhaltung: E-Rechnung einführen ohne IT-Projekt

---

Ausgangslage: Was im typischen KMU-ERP schon steckt

Die meisten mittelständischen ERP-Systeme (ob DATEV, Sage, abas, HS Rechnungswesen oder Microsoft Dynamics) liefern seit 2024/2025 E-Rechnungs-Module mit. Der Lieferumfang ist jedoch sehr unterschiedlich:

• Ausgangsrechnungen: Viele Systeme erzeugen ZUGFeRD-Hybriddateien bereits out-of-the-box. Qualität und Profil variieren stark. Nicht jede generierte Datei besteht die KoSIT-Validierung (KoSIT/xeinkauf.de).
• Eingangsrechnungen: Das ist die häufigere Baustelle. Das ERP kann zwar ein XML parsen, sobald es strukturiert vorliegt, aber der Empfangskanal (Postfach, SFTP, Peppol) ist selten konfiguriert.
• Buchungslogik: Felder wie Steuerschlüssel, Kostenstelle, Zahlungsziel müssen aus dem XML-Dokument auf interne Konten gemappt werden. Dieses Mapping ist projektspezifisch.

Was das bedeutet: Es geht fast nie um eine Neuprogrammierung. Es geht um Kanal einrichten, Mapping konfigurieren, Validierung vorschalten und Fehlerfälle definieren.

---

Die Formate im technischen Detail

XRechnung (reines XML)

XRechnung ist ein deutscher Standard auf Basis der EN 16931, herausgegeben von KoSIT (xeinkauf.de). Aktuelle Produktivversion: 3.0.2. Version 4.0 implementiert die überarbeitete EN 16931-1:2026 und ist für Mitte bis Ende 2026 geplant (Termin noch nicht final bestätigt).

Zwei XML-Syntaxen sind erlaubt:

• UBL (Universal Business Language, ISO/IEC 19845)
• CII (UN/CEFACT Cross Industry Invoice, D16B)

Beide sind semantisch äquivalent gemäß EN 16931. Welche Syntax das ERP bevorzugt, entscheidet in der Praxis oft der Empfänger. Bei B2G-Rechnungen gibt die ausschreibende Stelle die Syntax vor.

Wichtigstes Pflichtfeld für B2G: die Leitweg-ID (BT-10, „Buyer Reference"). Sie identifiziert die empfangende Stelle innerhalb einer Behörde. Format: [Code]:[Bereich]:[Prüfziffer]. Fehlt sie oder ist sie falsch, wird die Rechnung automatisch abgewiesen. Für reine B2B-Rechnungen ist BT-10 technisch optional, aber als interne Referenz (Bestellnummer, Projektnummer) dennoch zu empfehlen.

ZUGFeRD 2.4 / Factur-X 1.08 (Hybrid-PDF)

ZUGFeRD ist ein Hybridformat: eine PDF/A-3-Datei mit eingebettetem CII-XML. Herausgegeben von FeRD (ferd-net.de). Die aktuelle Version 2.4 (identisch mit Factur-X 1.08, dem französischen Pendant) wurde am 4. Dezember 2025 veröffentlicht und ist seit dem 15. Januar 2026 in Kraft. Technische Basis: UN/CEFACT CII D22B, backward-kompatibel mit D16B (ZUGFeRD 2.x früher).

Neu in 2.4: Sub-Positionen (Bundles, Kits, zusammengesetzte Artikel) lassen sich jetzt MwSt.-konform abbilden. Das betrifft vor allem Branchen mit komplexen Leistungsbündeln (Maschinen + Wartung, Software + Support).

Profile: Nicht jedes Profil ist ein gültiger Steuerbeleg

Praxisregel: MINIMUM und BASIC WL sind keine gültigen Umsatzsteuerbelege nach deutschem Recht (BMF FAQ E-Rechnung). Wer eingehende ZUGFeRD-Dateien im Buchungsprozess automatisch verarbeitet, muss sicherstellen, dass das Profil mindestens BASIC ist, sonst fehlt die Vorsteuer-Grundlage. Im Zweifel Steuerberater einbinden.

Mehr zu den Formaten: XRechnung erklärt · ZUGFeRD / Factur-X

---

Validierungsarchitektur: Drei Schichten, bevor die Rechnung ins ERP kommt

Valide im Sinne des Gesetzes bedeutet, dass ein Dokument alle drei Schichten besteht:

Schicht 1: XML-Schema-Validierung (syntaktisch) Jedes Profil hat ein eigenes XSD. Der Parser prüft, ob das Dokument strukturell korrekt ist: alle Pflichtknoten vorhanden, Datentypen stimmen. Fehler hier sind fatal: das Dokument kann nicht weiterverarbeitet werden.

Schicht 2: Schematron-Validierung (fachlich) Schematron-Regeln prüfen die semantische Korrektheit gemäß EN 16931 sowie die deutschen Zusatzregeln (BR-DE). Beispiele: Summen stimmen mit Einzelpositionen überein, Steuerschlüssel passen zur ausgewiesenen MwSt., Rundungen sind korrekt. Fehler werden mit Regel-ID ausgegeben (z.B. BR-DE-15), was die Fehlersuche im ERP-Mapping erheblich vereinfacht.

Schicht 3: Geschäftsregel-Prüfung (empfängerseitig) Über die formale Validierung hinaus kann der Empfänger eigene Regeln durchsetzen: Ist die Leitweg-ID korrekt? Existiert die referenzierte Bestellnummer? Stimmt die Lieferantenadresse mit dem Stammdatensatz überein? Diese Schicht läuft empfängerseitig im ERP, nicht im Validator.

Werkzeug: Der offizielle KoSIT-Validator ist Open Source und kann lokal oder als CI-Schritt in jede Build-Pipeline eingebaut werden (KoSIT auf GitHub). Online-Validierung für Tests: erechnungs-validator.de.

---

Integrationspfade: Postfach-first, dann API

Stufe 1: Postfach-first (kein API-Vertrag nötig)

Der niedrigschwelligste Einstieg, für die meisten KMU der richtige erste Schritt:

1. Eine dedizierte E-Mail-Adresse (oder SFTP-Verzeichnis) empfängt eingehende E-Rechnungen.
2. Ein vorgeschalteter Dienst parst den Anhang, validiert das Dokument gegen KoSIT-Regeln und extrahiert die strukturierten Felder.
3. Die extrahierten Daten werden als strukturierte Datei (JSON, CSV oder direkt als Buchungssatz) in das ERP geschrieben, per vorhandenem Import-Mechanismus, ohne neue Schnittstelle.

Für den Ausgang läuft der Prozess gespiegelt: Das ERP exportiert die Rechnungsdaten (oft schon als CSV oder über ein bestehendes Exportformat), der Dienst wandelt sie in valides XRechnung- oder ZUGFeRD-XML um und versendet über den konfigurierten Kanal.

Vorteil: Keine API-Verhandlung mit dem ERP-Hersteller, kein Entwicklungsauftrag, kein Wartungsvertrag für eine neue Schnittstelle. Das ERP bleibt unverändert.

Stufe 2: REST-API-Integration

Wenn das Volumen steigt oder Echtzeit-Verarbeitung nötig ist, folgt der API-Pfad:

ERP / Datenbank
       ↓  REST / JSON
  [Validierung: Schicht 1 + 2]
       ↓
  [Format-Konvertierung → XRechnung XML oder ZUGFeRD PDF/A-3]
       ↓
  [Versandkanal-Routing: E-Mail | SFTP | Peppol]
       ↓
  Empfänger + [Statuslog → ERP zurück]

Die API nimmt strukturierte Rechnungsdaten als JSON oder XML entgegen. Rückgabe ist das fertige Dokument plus Validierungsreport. Zwei Verarbeitungsmodi:

• Synchron: Request/Response, geeignet für Einzelrechnungen und interaktive Prozesse
• Asynchron: Queue-basiert, geeignet für Batch-Verarbeitung und höhere Volumen; Ergebnis wird per Callback oder Polling abgerufen

Wichtig für die Implementierung:

• Idempotenz: Dasselbe Rechnungsdokument darf mehrfach gesendet werden, ohne dass eine Duplikatrechnung entsteht. Das setzt eindeutige Belegnummern oder externe Referenz-IDs voraus.
• Fehlerklassifikation: Temporäre Fehler (Netzwerk, Timeout) müssen von permanenten getrennt werden (invalides Mapping, fehlende Pflichtfelder). Nur permanente Fehler landen im ERP-Fehlerprotokoll und erfordern menschliche Intervention.
• Mandantenfähigkeit: Mehrere Buchungskreise, Steuernummern und Profile müssen parallel betreibbar sein.

Stufe 3: Peppol Access Point

Für B2G-Rechnungen (öffentliche Auftraggeber) ist in vielen Fällen ein Peppol-Anschluss erforderlich. Peppol ist ein europäisches Transportnetzwerk. Der Rechnungssender benötigt einen akkreditierten Access Point, der die Dokumente ins Peppol-Netz übergibt. Für B2B ist Peppol optional, gewinnt aber als Routing-Standard an Bedeutung, insbesondere bei Großkunden mit eigenen Peppol-IDs.

---

Feldmapping: Die häufigsten Stolperstellen

XRechnung und ZUGFeRD definieren rund 60 semantische Kerndatenelemente (BT = Business Term). Die kritischen Mapping-Punkte in der Praxis:

Das Mapping ist einmalig aufzusetzen und dann stabil. Der größte Zeitaufwand in einem Piloten liegt nicht im Format, sondern im Mapping-Workshop mit dem ERP-Berater: Welches ERP-Feld entspricht welchem BT? Was passiert, wenn das ERP-Feld leer ist?

---

Migration ohne Big Bang: Der Stufenplan

Phase 1: Empfang zuerst (sofort möglich)

Die gesetzliche Empfangspflicht gilt seit dem 1. Januar 2025 (BMF FAQ). Das ist der technisch einfachste Schritt: Postfach einrichten, Validierung vorschalten, Dateien in vorhandenes ERP-Importverzeichnis ablegen. Keine neue Schnittstelle, keine Codeänderung am ERP.

Phase 2: Ausgangsrechnungen pilotieren (2026)

Experten empfehlen, die Ausgangsseite noch 2026 zu testen; dann bleibt ausreichend Pufferzeit vor der Versandpflicht, die ab 2027 für Unternehmen mit mehr als 800.000 € Vorjahresumsatz gilt (IHK Frankfurt). Ziel des Piloten: eine kleine Tranche echter Ausgangsrechnungen (5 bis 10 Stück, mit realen Empfängern, die zustimmen) im neuen Format erzeugen, KoSIT-validieren, versenden, Quittierung prüfen.

Phase 3: Rollout und Automatisierung

Nach erfolgreichem Piloten: Buchungsregeln für häufige Lieferanten-Profile abbilden, Fehlerbehandlung definieren, Eskalationspfad für fehlerhafte Eingangsdokumente festlegen. Erst jetzt lohnt der API-Ausbau, wenn das Volumen es rechtfertigt.

---

Pilot-Checkliste 2026

Vor dem ersten produktiven Einsatz:

• [ ] Empfangskanal eingerichtet: Dedizierte E-Mail-Adresse oder SFTP-Verzeichnis aktiv; Anhänge landen in definiertem Staging-Bereich
• [ ] KoSIT-Validator integriert: Jedes eingehende Dokument läuft durch Schema- und Schematron-Prüfung, bevor es ins ERP übergeben wird
• [ ] Profil festgelegt: Mindestens EN 16931 (COMFORT) für B2B-Eingang; für Ausgang mit Empfänger abstimmen
• [ ] Feldmapping dokumentiert: Alle BT-Felder auf ERP-Felder gemappt, Sonderfälle (Leerfeld, Freitext) definiert
• [ ] Fehlerbehandlung beschrieben: Was passiert bei Schicht-1-Fehler (syntaktisch), Schicht-2-Fehler (fachlich), Schicht-3-Fehler (empfängerseitig)? Wer wird benachrichtigt?
• [ ] Testlauf mit echten Dokumenten: Mindestens 5 reale Eingangsrechnungen durch den neuen Prozess geleitet und Buchungsergebnis geprüft
• [ ] Ausgangstest mit Einverständnis des Empfängers: Mindestens 2 Ausgangsrechnungen im neuen Format versendet, Empfangsbestätigung dokumentiert
• [ ] Archivierungsweg geprüft: GoBD-konforme Ablage der E-Rechnungs-Originaldatei (XML oder PDF/A-3) sichergestellt, nicht nur die Druckansicht (GoBD-Archivierung prüfen)
• [ ] Versandpflicht-Frist bekannt: Vorjahresumsatz 2026 dokumentiert; ab 01.01.2027 (>800.000 €) oder 01.01.2028 (alle anderen) ist der Versand Pflicht. Fristen im Überblick

---

Was der Dienst technisch übernimmt

Der Dienst bildet die Integrations- und Validierungsschichten, nicht das ERP. Das bedeutet konkret:

• Validierung gegen KoSIT-Regeln vor jedem ERP-Import und nach jeder ERP-Ausgabe
• Format-Konvertierung (Eingang: XML/ZUGFeRD → ERP-Import; Ausgang: ERP-Export → XRechnung/ZUGFeRD)
• Abstimmung des Mappings mit dem ERP-Anbieter des Kunden, als koordinierter Einrichtungsprozess, nicht als Dauerprojekt
• Fehlerprotokollierung und Eskalation bei ungültigen Dokumenten
• Revisionssichere Ablage der Originaldokumente

Das ERP bleibt, wie es ist. Die Schnittstelle zum ERP ist die bereits vorhandene Import-/Export-Funktion, keine neue Programmierung am ERP-Kern.

Für den nicht-technischen Einstieg: Was tue ich jetzt: Schritt für Schritt