Wer den Lieferantenstamm migrieren will, darf ihn nicht wie eine einfache Adressliste behandeln. Ein Lieferant verbindet allgemeine Identitätsdaten mit Finanzinformationen, Bankverbindungen, Zahlungsbedingungen und den Rollen verschiedener Einkaufsorganisationen. Passen diese Ebenen nach dem ERP-Wechsel nicht mehr zusammen, ist der Datensatz zwar sichtbar, aber nicht zuverlässig bestell-, prüf- oder zahlbar.
Die Kernaufgabe lautet deshalb: Nicht nur einzelne Felder übertragen, sondern die fachlichen Beziehungen des Lieferanten im Zielsystem neu aufbauen und in den betroffenen Geschäftsprozessen testen.
Den Lieferantenstamm migrieren heißt Beziehungen rekonstruieren
Im alten ERP kann „der Lieferant“ auf mehrere Tabellen, Masken und Organisationsebenen verteilt sein. Ein Bereich enthält Name und Anschrift, ein anderer die Daten für die Finanzbuchhaltung und ein weiterer die Einstellungen des Einkaufs. Zusätzliche Ansprechpartner, Bankkonten, Steuerinformationen oder Sperren besitzen eigene Schlüssel und Gültigkeiten.
Das neue ERP fasst diese Informationen möglicherweise anders zusammen. In SAP S/4HANA ist der Lieferant beispielsweise in das Geschäftspartnermodell eingebunden und wird um Buchungskreis- sowie Einkaufsorganisationsdaten erweitert. Andere ERP-Systeme verwenden andere Bezeichnungen. Die fachliche Aufgabe bleibt gleich: Eine rechtliche oder organisatorische Einheit muss mit den richtigen Rollen, Konten und Einkaufsbereichen verbunden werden.
Deshalb beginnt die Migration am Zielobjekt. Erst wenn seine Ebenen und Pflichtbeziehungen verstanden sind, lässt sich beurteilen, welche alten Tabellen und Felder gemeinsam einen vollständigen Lieferanten ergeben.
Eine Lieferantenakte besteht aus mindestens drei Ebenen
Die genaue Struktur ist systemspezifisch. Für die Planung hilft trotzdem eine fachliche Trennung in drei Ebenen, weil sie unterschiedliche Verantwortlichkeiten und Tests verlangt.
Allgemeine Identität
Hierzu zählen beispielsweise Name, Anschriften, Kommunikationsdaten, Steuermerkmale und Ansprechpartner. Diese Angaben beantworten, mit wem das Unternehmen arbeitet. Sie können für Einkauf und Finanzwesen gemeinsam gelten, besitzen aber dennoch mehrere Adressen oder zeitabhängige Varianten.
Finanz- und Zahlungsdaten
Diese Ebene steuert, wie Verbindlichkeiten behandelt und Zahlungen vorbereitet werden. Dazu können Buchungskreiszuordnung, Abstimmkonto, Zahlungswege, Zahlungsbedingungen, Mahn- oder Sperrinformationen und Bankverbindungen gehören. Welche Felder benötigt werden, hängt von Zielsystem, Land, Konfiguration und internen Kontrollen ab.
Einkaufsrollen und Organisation
Der Einkauf benötigt unter anderem die Zuordnung zu den vorgesehenen Einkaufsorganisationen, Bestellwährung, Liefer- und Konditionsmerkmale oder Partnerfunktionen. Ein allgemein angelegter Lieferant ist deshalb nicht automatisch in jedem Einkaufsbereich verwendbar. Das Zielsystem kann ausdrücklich verlangen, dass der bestehende Datensatz auf eine Organisationsebene erweitert wird.
Diese drei Ebenen bilden keinen universellen Importstandard. Sie sind eine Prüflogik: Ist der Lieferant identifiziert, finanzseitig verwendbar und für die richtigen Einkaufsbereiche freigeschaltet?
Bankdaten brauchen eine eigene Herkunfts- und Freigabespur
Bankverbindungen sind besonders sensibel, weil ein formal gültiger Wert direkt in den Zahlungsprozess wirken kann. Bei der Migration genügt es daher nicht, IBAN, Kontoinhaber oder Bankkennzeichen aus irgendeiner gefundenen Tabelle zu kopieren. Das Projekt muss wissen, zu welchem Lieferanten und zu welcher bisherigen Rolle die Verbindung gehört, ob mehrere Konten existieren und welcher Bestand als autoritativ gilt.
Auch die Zielvoraussetzungen müssen früh geprüft werden. Manche Systeme benötigen beispielsweise ein gepflegtes Bankverzeichnis oder eigene Schlüssel, bevor Lieferanten-Bankdaten geladen werden können. Ein technisch korrektes Lieferantenfile scheitert dann nicht an der Adresse, sondern an einem fehlenden abhängigen Stammdatensatz.
Wir würden Bankdaten deshalb als eigene Teilmenge mit klarer Quelle, Transformationsregel und fachlicher Kontrolle führen. Die Freigabe sollte dem bestehenden internen Kontrollprozess des Unternehmens folgen. Die Migration darf keine neue Bankverbindung allein aus Ähnlichkeit, einem alten Freitext oder einer vermeintlich plausiblen Ergänzung erzeugen.
Zahlungsbedingungen werden nach Bedeutung zugeordnet
Alte und neue Systeme verwenden häufig Schlüssel für Zahlungsbedingungen. Zwei Codes können ähnlich aussehen und trotzdem andere Nettofristen oder Skontoregeln bezeichnen. Umgekehrt können verschieden benannte Codes fachlich dieselbe Bedingung abbilden.
Die richtige Zuordnung entsteht deshalb nicht aus dem Feldnamen, sondern aus der Bedeutung. Für jeden alten Schlüssel wird geprüft, welche Regel dahintersteht und welchem freigegebenen Zielschlüssel sie entspricht. Gibt es im neuen ERP keine passende Entsprechung, braucht das Projekt eine fachliche Entscheidung: Zielkonfiguration ergänzen, eine definierte neue Regel verwenden oder den betroffenen Lieferanten gezielt nachpflegen.
Diese Entscheidung gehört als Mapping-Regel dokumentiert. Mapping bezeichnet die fachliche Verbindung zwischen einem benötigten Zielwert und seiner Quelle oder Erzeugungslogik. Wie solche Regeln aufgebaut werden, erläutert unser Beitrag Datenmapping und Transformationsregeln im ERP-Projekt.
Einkaufsorganisationen entscheiden über die praktische Nutzbarkeit
Nach dem Import lässt sich ein Lieferant suchen und anzeigen. Beim Anlegen einer Bestellung meldet das System dennoch, dass er für den vorgesehenen Einkaufsbereich nicht angelegt oder gesperrt ist. Dieses Fehlerbild zeigt, warum reine Stammsatzmengen wenig aussagen: Die allgemeine Identität wurde übertragen, die notwendige Organisationsbeziehung fehlt.
Vor der Migration muss deshalb geklärt werden, welche Lieferanten in welchen Einkaufsorganisationen tatsächlich gebraucht werden. Eine pauschale Erweiterung aller Lieferanten auf alle Bereiche kann technisch bequem wirken, erzeugt aber Berechtigungen und Auswahlmöglichkeiten, die fachlich nie vorgesehen waren. Eine zu enge Auswahl verhindert dagegen die operative Beschaffung.
Die Zielregel kann aus aktiver Nutzung, Werk- oder Buchungskreisbezug, vorhandenen Einkaufsbelegen und einer fachlichen Bestätigung abgeleitet werden. Welche Nachweise geeignet sind, hängt von der alten Datenstruktur ab. Wichtig ist, dass die Regel wiederholbar ist und nicht erst nach dem Go-live durch einzelne Fehlermeldungen entdeckt wird.
Dubletten sind nicht nur gleiche Namen
Im Lieferantenstamm können gleiche Unternehmen mehrfach vorkommen, etwa wegen Standorten, früher getrennter Einkaufs- und Kreditorenpflege oder historischer Nummern. Nicht jede Ähnlichkeit ist eine Dublette. Zwei Datensätze können bewusst unterschiedliche Organisationen, Zahlwege oder Vertragsbeziehungen repräsentieren.
Vor einer Zusammenführung müssen deshalb mindestens Identität, Adressen, Steuermerkmale, Bankverbindungen, offene Vorgänge und Organisationsrollen verglichen werden. Wird nur nach Namen zusammengeführt, können legitime Beziehungen verloren gehen. Werden alle alten Nummern ungeprüft getrennt übernommen, bleibt die Mehrfachanlage bestehen und erschwert Einkauf sowie Zahlung.
Der Beitrag Dubletten bei der ERP-Migration zusammenführen zeigt, wie Zusammenführung und Nachweis voneinander getrennt werden.
Eine Zielmatrix verbindet Feld, Rolle und Prozess
Für einen Lieferanten reicht eine flache Feldliste selten aus. Wir empfehlen eine Zielmatrix, in der jede benötigte Information mit ihrer Ebene und ihrer späteren Verwendung verbunden wird.
| Zielinformation | Fachliche Ebene | Zu klärende Herkunft | Prozessprüfung |
|---|---|---|---|
| Name und Anschrift | Allgemeine Identität | Führender Lieferanten- oder Geschäftspartnerbestand | Lieferant eindeutig auffindbar und korrekt adressierbar |
| Bankverbindung | Zahlungsdaten | Autorisierte Bankdatenquelle samt Zuordnung | Zahlungsvorschlag verwendet die freigegebene Verbindung |
| Zahlungsbedingung | Finanzwesen oder Einkauf | Alter Code plus fachliche Frist- und Skontobedeutung | Beleg erhält die erwartete Fälligkeit |
| Einkaufsorganisation | Organisationsrolle | Aktive Nutzung und bestätigter Zielbereich | Bestellung ist im vorgesehenen Bereich möglich |
| Sperrstatus | Steuerung und Kontrolle | Gültiger Altstatus und fachliche Entscheidung | Gesperrte Lieferanten bleiben im passenden Prozess gesperrt |
Die Matrix zwingt das Projekt nicht in ein bestimmtes ERP-Modell. Sie verhindert aber, dass ein Feld technisch übertragen wird, ohne seine organisatorische Rolle und spätere Prüfung zu kennen.
Drei Prozesse beweisen mehr als ein erfolgreicher Import
Nach dem Laden sollten Lieferanten nicht nur gezählt oder stichprobenartig geöffnet werden. Mindestens drei Prozessrichtungen müssen mit passenden Testfällen geprüft werden:
- Beschaffung: Lässt sich der Lieferant in der richtigen Einkaufsorganisation für eine Bestellung verwenden und werden vorgesehene Konditionen übernommen?
- Rechnungsprüfung: Treffen Buchungskreis, Zahlungsbedingung und Kontierung so zusammen, dass eine Eingangsrechnung korrekt verarbeitet werden kann?
- Zahlung und Kontrolle: Werden nur freigegebene Bank- und Zahlungsdaten verwendet und bleiben notwendige Sperren wirksam?
Zusätzlich braucht es Vollständigkeitsprüfungen: Wie viele aktive Lieferanten waren je Organisation vorgesehen, wie viele wurden geladen und welche wurden mit dokumentiertem Grund ausgeschlossen? Die Datenvalidierung bei der ERP-Migration verbindet solche Mengenabgleiche mit fachlichen Prozessprüfungen.
Warum drei schnelle Lösungen die Ursache verfehlen
Eine einzige breite CSV-Datei kann für ein einfaches Zielobjekt genügen. Sie löst aber keine fehlenden Beziehungen, wenn Finanz- und Einkaufsdaten unterschiedliche Schlüssel und Organisationsebenen besitzen. Ebenso riskant ist es, unbekannte Zahlungsbedingungen mit einem allgemeinen Standard zu füllen. Der Import wird dadurch möglicherweise grün, doch die fachliche Vereinbarung ändert sich.
Auch eine vollständige Neuanlage aller auffälligen Lieferanten ist nicht automatisch sauber. Sie kann bestehende Dubletten vervielfachen und offene Vorgänge von ihrem ursprünglichen Geschäftspartner trennen. Jede dieser Maßnahmen hat einen sinnvollen Einsatzbereich, sobald die fachliche Entscheidung feststeht. Als Ersatz für Quellanalyse und Mapping genügt sie nicht.
Wer muss beim Lieferantenstamm entscheiden?
Einkauf und Finanzwesen betrachten denselben Lieferanten aus unterschiedlichen Prozessen. Beide Perspektiven werden benötigt. Der Einkauf bestätigt Organisationsrollen, Bestellbarkeit und beschaffungsbezogene Regeln. Das Finanzwesen bestätigt buchungs- und zahlungsrelevante Einstellungen. IT und ERP-Partner erklären Quellen, Zielstruktur und technische Ladewege.
Wir können diese Informationen zusammenführen, Quellbeziehungen analysieren, Mappingvorschläge vorbereiten und wiederholbare Migrationsdateien erzeugen. Die Freigabe von Zahlungsbedingungen, Bankdaten, Sperren und Organisationsrollen bleibt beim zuständigen Unternehmen. So wird aus verteilter Zuständigkeit ein prüfbarer Lieferantenbestand, ohne fachliche Verantwortung zu verschieben.
Ein Lieferant ist erst migriert, wenn Einkauf und Zahlung funktionieren
Die erfolgreiche Anlage eines Datensatzes ist nur der technische Anfang. Vollständig migriert ist der Lieferantenstamm erst, wenn allgemeine Identität, Finanzdaten und Einkaufsrollen zusammenpassen, Abhängigkeiten im Ziel vorhanden sind und die vorgesehenen Prozesse mit freigegebenen Daten funktionieren.
Wer diese Beziehungen vor dem ersten großen Test sichtbar macht, vermeidet eine besonders teure Art von Fehler: einen Lieferanten, der im neuen ERP vorhanden aussieht, aber genau im Bestell-, Rechnungs- oder Zahlungsprozess nicht so arbeitet, wie das Unternehmen ihn braucht.