# ERP-Integrations-Checkliste für E-Rechnungen und moderne Rollouts

- Date: 2026-04-20
- Modified: 2026-08-29
- Geprüft: 14. Juli 2026
- Reading time: 2 Min. Lesezeit

Praxisnahe ERP-Checkliste für E-Rechnungsprojekte: Datenmapping, Formatwahl, Validierung, Ausnahmebehandlung und Go-live-Kontrollen.

> Geprüft anhand von Peppol BIS Billing 3.0, OASIS-UBL-2.1-Spezifikation.

Diese Checkliste richtet sich an ERP-Verantwortliche, Finance Operations und Implementierungsleiter, die E-Rechnung in bestehende Buchhaltungs- oder eigene Billing-Stacks integrieren.

Der häufigste Fehler ist, E-Rechnung nur als Exportformat-Thema zu behandeln. In Wahrheit umfasst das Projekt Stammdatenqualität, Länder-Routing, XML-Erzeugung, Validierung, Ausnahmebehandlung und Rückkopplung in den Finanzprozess.

## 1. Zielumfang zuerst festlegen

- Länder, Empfängertypen und Kanäle für Phase eins definieren.
- Zielformate pro Workflow festlegen: XRechnung, ZUGFeRD/Factur-X, UBL oder CII.
- Entscheiden, ob das ERP finale XML erzeugt oder Konvertierung als Brücke dient.
## 2. Quelldaten vor dem Mapping bereinigen

- Stammdaten zu Verkäufer, Käufer, Steuerkennungen, Adressen, IBAN und Zahlungsbedingungen prüfen.
- Positionsdaten, Rabatte, Zu-/Abschläge und USt-Kategorien auf Konsistenz prüfen.
- Felder markieren, die außerhalb des ERP ergänzt werden müssen, etwa Käuferreferenz oder Leitweg-ID.
## 3. Mapping und Validierung gemeinsam entwerfen

Trennen Sie Mapping nicht von der Validierungslogik. Fehlende Pflichtfelder und Codelistenfehler lassen sich am besten schon während des ERP-zu-XML-Mappings erkennen.

- Jedes Pflichtfeld einer ERP-Quelle oder einem expliziten Fallback-Prozess zuordnen.
- Codelisten für USt-Kategorien, Zahlungsarten, Währungen und Länder bestätigen.
- Festlegen, welche Validator-Berichte gespeichert werden und wer fehlerhafte Rechnungen korrigiert.
## 4. Ausnahmeprozess vor dem Go-live bauen

- Definieren, wer fehlende Kennungen oder unsichere Extraktion prüft.
- Dokumentieren, wann eine Rechnung aus Quelldaten neu erzeugt statt im XML nachgebessert wird.
- Reaktionszeiten für Validierungsfehler festlegen, damit Finance weiß, was den Versand blockiert.
## 5. Mit realistischen Belegen testen

- Zuerst einfache Inlandsszenarien testen.
- Dann Rabatte, gemischte USt-Sätze, Befreiungen, Gutschriften und empfängerabhängige Kennungen testen.
- End-to-End-Tests inklusive Zielkanal und nachgelagertem Import oder Portal durchführen.
## 6. Nur mit operativen Verantwortlichen live gehen

- Finanzteams darauf schulen, was vor dem Versand geprüft werden muss.
- Validierungsstatus und Korrekturverantwortung im Tagesgeschäft sichtbar machen.
- Für die erste Rollout-Welle einen Fallback für manuell zu behandelnde Rechnungen bereithalten.

## FAQ

### Soll das ERP immer direkt die finale XML erzeugen?

Nicht zwingend. Langfristig kann das sinnvoll sein, aber während des Rollouts ist eine Konvertierungs- und Validierungsschicht oft die sicherere Brücke.

### Was ist das größte Integrationsrisiko?

Schlechte Quelldaten. Selbst ein korrekter XML-Generator scheitert, wenn Käuferkennungen, USt-Logik, Zahlungsbedingungen oder Codelistenwerte im ERP falsch sind.

### Reichen einige Happy-Path-Rechnungen zum Testen?

Nein. Sie brauchen realistische Belege mit gemischter USt, Befreiungen, Rabatten und empfängerabhängigen Kennungen, sonst treten Fehler erst nach dem Go-live auf.

## Offizielle Quellen

- [Peppol BIS Billing 3.0](https://docs.peppol.eu/poacc/billing/3.0/bis/)
- [OASIS-UBL-2.1-Spezifikation](https://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html)