DSAG-Positionspapier: Business-Partner- Multiple-Address-Adoption: Source-to-Pay

Mit der Einführung des Multiple-Address-Handlings und seiner Adoption im Order-to-Cash-Prozess (O2C) wurde ein wichtiger Schritt hin zu einer konsistenteren Abbildung von Adressbeziehungen innerhalb des Business Partners erreicht. Da jedoch eine vergleichbare Erweiterung im End-to-End-Prozess „Source-to-Pay“ (S2P) derzeit nicht in der SAP-Roadmap vorgesehen ist, bleibt der Nutzen des Multiple-Address-Handlings auf O2C begrenzt – und wirft dadurch zentrale Fragen zur Datenkonsistenz zwischen den E2E-Prozessen auf. Was sollten Unternehmen hierzu wissen? Und wie lässt sich mit dieser Situation konkret umgehen?

September 2025

Ausgangslage: Multiple & zeitabhängige Business-Partner-Adressen in SAP S/4HANA

Im Standard-Kunden- und Lieferanten-Datenmodell von SAP S/4HANA konnte bisher nur eine einzige Adresse pro Stammsatz hinterlegt werden. Dies bedeutete, wenn mehrere Adressen (zum Beispiel eine Warenempfänger- und eine Rechnungsempfängeradresse) für denselben Business Partner (BP) nötig waren, musste jeweils ein zusätzlicher Business Partner mit Ausprägung Kunde und/oder Lieferant für jede weitere Adresse angelegt werden und über das Partnerschema in den jeweiligen organisationsabhängigen Daten (Vertriebs- oder Einkaufsorganisationsdaten) über die entsprechende Partnerrolle hinzugefügt werden.

Eine rechtliche Einheit mit n-Adressen wird daher üblicherweise als n-parallele BP-Stammsätze angelegt, die der gleichen Anzahl an Kunden- und Lieferanten-Stammsätzen zugeordnet sind und so die entsprechenden 1:1-Beziehungen bilden. Diese Erstellung zusätzlicher Business Partner mit Ausprägung Kunde und/oder Lieferant, um die zusätzlichen Adressen desselben Business Partners abzubilden, führt zu Datenredundanzen.

Mit der inzwischen erfolgten Einführung der Option von multiplen und zeitabhängigen Business-Partner-Adressen in den Vertriebsprozessen von S/4HANA kann der Business Partner semantisch richtig – als rechtliche Einheit – verwendet werden, da zu jeder ihrer Adressen deren semantische Verwendung festgelegt werden kann. Eine rechtliche Entität mit mehreren physischen Adressen kann also bei der Verwendung dieses „Multiple-Address-Handlings (MAH)“ durch einen einzigen Business-Partner-Stammsatz repräsentiert werden.

Leider wird SAP die – ursprünglich geplante – Erweiterung der MAH-Option auf die Einkaufsprozesse in S/4HANA nicht umsetzen. Damit bleibt die aktuelle semantische Inkonsistenz zwischen dem Business-Partner-Objekt im Vertriebsprozess (rechtliche Einheit mit allen Adressen) und dem Business-Partner-Objekt in den meisten Einkaufsprozessen (konkrete Adresse der rechtlichen Einheit) bestehen.

Aus Sicht der DSAG stellt die beschriebene semantische Inkonsistenz ein erhebliches Hindernis dar: Aufgrund der daraus resultierenden Herausforderungen in den S/4HANA-Prozessen ist davon auszugehen, dass die von der DSAG ausdrücklich unterstütze Einführung der multiplen und zeitabhängigen Business-Partner-Adressen in zukünftigen S/4HANA-Projekten nur selten zur Anwendung kommen wird.

Bisherige Aktivitäten und aktueller Stand der Umsetzung

SAP hat mit der DSAG eine Themengruppe zum Multiple-Address-Handling gebildet, um gemeinsam mit engagierten Anwenderunternehmen den Business Partner gesamtheitlich als legale Einheit abzubilden. Diese Aktivitäten sind Bestandteil der gemeinsamen „Stammdateninitiative“ auf SAP- und DSAG-Vorstandsebene:

Als erstes wurde der Order-to-Cash Prozess (O2C) überarbeitet und auch erfolgreich mit dem Release S/4HANA 2022 für die SAP-Anwenderunternehmen ausgeliefert.

SAP hat hier signifikant in das Business Partner Multiple-Address-Handling im O2C-Prozess investiert. Mit dem Retourenprozess wurde sogar ein erster Prozess aus dem Source-to-Pay-Prozess (S2P) mit umgesetzt.

Aus Sicht der DSAG werden die umfangreichen Investitionen von SAP in die Entwicklungen der entstandenen Lösung in S/4HANA ausdrücklich begrüßt.

Leider hat sich SAP entschieden, das Multiple-Address-Handling nicht weiter in den Source-to-Pay-Prozess zu integrieren. Aus DSAG-Sicht stellt dies fachlich betrachtet eine Inkonsistenz durch die unterschiedliche Semantik des Business Partners in O2C und S2P dar:

Konsequenz aus DSAG-Sicht

Die von SAP nicht mehr geplante Erweiterung des für den O2C bereits implementierten Multiple-Address-Handlings für den S2P-Prozess führt aus DSAG-Sicht potenziell zu Schwierigkeiten, da diverse Prozesse sowohl Kunden- als auch Lieferantendaten enthalten. Dies gilt insbesondere für:

• Prozesse die sowohl Kunde als auch Lieferant betreffen
• Kunden- und Lieferanten-übergreifende Prozesse
• Prozesse, die den Lieferanten in Summe betreffen (adressunabhängig)
• Stammdatenpflegeprozesse

Prozesse, die sowohl Kunden als auch Lieferanten betreffen

Bei diesen Prozessen werden sowohl Kunden als auch Lieferantenstammdaten benötigt. Wenn Kunden bereits die multiplen und zeitabhängigen Business-Partner-Adressen verwenden, jedoch der Lieferant diese Option nicht besitzt, können bei der Suche nach dem richtigen Lieferanten Probleme auftreten, da diese mehrmals vorhanden sind und es nicht immer ersichtlich ist, welcher der richtige ist. Folgende Prozesse sind beispielsweise davon betroffen:

• Intercompany-Prozesse: Dieselben legalen Einheiten werden sowohl auf O2C- als auch auf S2P-Seite verwendet. Durch die unterschiedlichen Datenmodelle auf den beiden Seiten müssen die Stammdaten separat und redundant angelegt werden – auf der Kundenseite die Legaleinheit mit mehreren Adressen, auf der Lieferanten-Seite ein Business Partner pro Adresse.
• Streckengeschäft: Bei Direktlieferung vom Lieferanten zum Kunden wird die Lieferadresse (des Kunden) in die Bestellung übernommen. Sofern im O2C-Beleg eine Adresse hinterlegt ist, muss diese auch in die Bestellung übernommen werden. Es ist unklar, wie dieser Fall bei der unterschiedlichen Business-Partner-Semantik im O2C bzw. S2P abgebildet werden soll.
• Abholung durch den Kunden: Bei Abholung durch den Kunden muss dieser auch als Spediteur (Lieferant) angelegt werden. Unterschiedliche Semantiken des Business Partners im O2C bzw. S2P erzwingen eine Doppelanlage des Business Partners.
• Verkauf an Spediteur, zum Beispiel wenn dem Spediteur (Lieferant) Verpackungsmaterialien verkauft werden, da nicht ausreichend Ladungssicherung vorhanden ist. Unterschiedliche Semantiken des Business Partners im O2C bzw. S2P erzwingen hier die Doppelanlage des Business Partners.
• Reklamationsabwicklung, zum Beispiel wenn der Kunde den entstandenen Mehraufwand bei einer Reklamation berechnet und dementsprechend auch als Lieferant angelegt werden muss. Unterschiedliche Semantiken des Business Partners im O2C bzw. S2P erzwingen hier die Doppelanlage des Business Partners.
• Partnerrollen, bei denen sowohl Kunden als auch Lieferanten eine Rolle spielen: Es ist unklar, wie die Fälle bei unterschiedlichen Business-Partner-Semantiken im O2C bzw. S2P abgebildet werden sollen, wo sowohl Kunden als auch Lieferanten in einer Partnerrolle verwendet werden, z. B. bei einem Kundenauftrag mit (a) „Regulierer“ und (b) „Spediteur“. Es besteht erhöhter Schulungsbedarf, da nach Kunden anders gesucht werden muss als nach Lieferanten.

Kunden- und Lieferanten-übergreifende Prozesse

Mit Kunden- und Lieferanten-übergreifenden Prozessen sind Prozesse gemeint, die gesamtheitlich auf der Legaleinheit erfolgen.

Beispiele sind hier:

• Business-Partner-Screening: Das Screening erfolgt gesamtheitlich auf der Legaleinheit. Ohne die Erweiterung des Multi-Adress-Handlings auf die S2P-Prozesse müssen dort die einzelnen Adressen gescreent werden und sie müssen ggf. einzeln gesperrt/entsperrt werden. Es fallen ggf. höhere Kosten für die Nutzung des Screening-Dienstes an.
• Financial Risk: Die Risiko-Bewertung erfolgt gesamtheitlich auf der Legaleinheit. Ohne die Erweiterung des Multi-Adress-Handlings auf die S2P-Prozesse fehlt die Gesamtsicht (oder die Verknüpfung muss anderweitig erfolgen, was die Komplexität erhöht). Es besteht bei negativer Bewertung das Risiko, dass einzelne Standorte vergessen werden zu sperren. Es fallen ggf. höhere Kosten für die Nutzung des Bewertungs-Dienstes an.
• Reporting: Das Reporting betrachtet gesamtheitlich die Legaleinheit. Ohne die Erweiterung des Multi-Adress-Handlings auf die S2P-Prozesse fehlt die Gesamtsicht (oder die Verknüpfung muss anderweitig erfolgen, was die Komplexität erhöht).
•  

Wenn bei diesen Prozessen die Kunden-Business-Partner bereits die multiplen & zeitabhängigen Business-Partner-Adressen benutzen, die Lieferanten aber nicht, sind die Business Partner extrem zeitaufwendig und komplex zu bearbeiten. Sobald sowohl Kunde als auch Lieferant die multiplen & zeitabhängigen Business-Partner-Adressen im Einsatz haben, werden diese Prozesse massiv vereinfacht und schlanker, somit auch weniger zeitaufwendig und effizienter.

Prozesse, die den Lieferanten in Summe betreffen (adressunabhängig)

Hiermit sind Prozesse gemeint, die den Lieferanten gesamtheitlich als Legaleinheit betrachten. Beispiele sind hier:

• Lieferantenbewertung: Die Lieferantenbewertung erfolgt gesamtheitlich auf der Legaleinheit (Teilbewertungen ggf. auch adressspezifisch). Ohne die Erweiterung des Multi-Adress-Handlings auf den S2P-Prozess fehlt die Gesamtsicht (oder die Verknüpfung muss anderweitig erfolgen, was die Komplexität erhöht). Es besteht bei negativer Bewertung das Risiko, dass einzelne Standorte vergessen werden zu sperren.
• Global Spend: Das Global-Spend-Reporting betrachtet gesamtheitlich die Legaleinheit. Ohne die Erweiterung des Multi-Adress-Handlings auf den S2P-Prozess fehlt die Gesamtsicht (oder die Verknüpfung muss anderweitig erfolgen, was die Komplexität erhöht).

Generell geht es bei diesen Prozessen darum, dass durch die aktuelle Lösung (ein Business Partner pro Adresse, also n Business Partner für n Adressen) die Prozesse noch komplexer gemacht werden als sie schon sind. Denn für diese Prozesse müssen dann alle Business Partner, die eine Legale Entität bilden, zusammengefasst werden.

Stammdaten-Pflegeprozesse

Bei der Stammdatenpflege gibt es zahlreiche Risken, wenn die multiplen & zeitabhängigen Business-Partner-Adressen nur für Kundenseite bereitgestellt werden und semantisch das Datenmodell von Kunde und Lieferant nicht identisch ist. Beispielsweise:

• Kunden als Lieferant ausprägen (und umgekehrt): Ist durch die unterschiedlichen Datenmodelle nicht möglich.
• Dublettenprüfung: Es ist keine gesamtheitliche Dublettenprüfung möglich, da für die Lieferantenseite redundante Business-Partner-Stammsätze existieren (und im Dublettencheck mit auftauchen). Es besteht durch das unklare Ergebnis der Dublettenprüfung das Risiko, dass durch die Anwender ungewollte Dubletten angelegt werden.
• Unterschiedliche Stammdaten-Pflegeprozesse: Stammdaten-Pflegeprozesse müssen kunden- und lieferantenseitig grundlegend unterschiedlich aufgebaut werden. Das erhöht die Komplexität zum einen technisch (z.B. bei der MDG-Nutzung) als auch organisatorisch (z.B. durch erhöhten Schulungsbedarf).
• Pflege von Grunddaten: Durch die Aufteilung des Lieferanten in verschiedene Adress-Business-Partner besteht das Risiko von inkonsistenter Datenpflege. Bei der Änderung von Grunddaten, z. B. Namensänderungen (Umfirmierungen ohne Betriebsübergang), müssen alle zugehörigen Adress-Business-Partner konsistent überarbeitet werden.
• Pflege von Ansprechpartnern: Durch die semantische Trennung müssen Ansprechpartner sowohl auf Kunden- als auch auf Lieferantenseite gepflegt werden.

Fazit

Die DSAG begrüßt die von SAP umgesetzten Entwicklungen im Bereich der multiplen Adressen innerhalb des O2C-Prozesses. Diese Neuerungen bieten Unternehmen die Möglichkeit, ihre Prozesse flexibler und effizienter zu gestalten. Besonders im O2C-Prozess, in dem Business Partner häufig mit einer Vielzahl von Adressen angelegt werden, stellt diese Funktionalität eine wertvolle Unterstützung dar.

Gleichzeitig empfiehlt die DSAG ihren Mitgliedern, die Einsatzmöglichkeiten dieser Funktionalität sorgfältig zu prüfen, insbesondere im Hinblick auf die spezifischen Anforderungen und Rahmenbedingungen ihres Unternehmens. Dabei sollten die oben genannten Punkte berücksichtigt werden, um eine fundierte Entscheidung zu treffen.

Allerdings bleibt abzuwarten, ob und in welchem Umfang Unternehmen diese Funktionalität in der Praxis implementieren werden, insbesondere angesichts der bestehenden Herausforderungen und der begrenzten Abdeckung weiterer Prozessbereiche wie Source-to-Pay.

Darüber hinaus weist die DSAG darauf hin, dass das ursprüngliche Thema der semantischen Inkonsequenz zwischen der legalen Einheit und einzelnen Adressen weiterhin ungelöst ist. Dies könnte in Zukunft zu bislang nicht absehbaren Problemen bei der Einführung neuer Prozesse oder Module führen.

Es ist jedoch zu beachten, dass auch andere SAP-Module wie Ariba oder CRM die Funktionalität für multiple Adressen bislang nicht unterstützen. Dies erschwert eine durchgängige und konsistente Abbildung von Geschäftspartnern über verschiedene SAP-Lösungen hinweg und kann zu weiteren semantischen Inkonsistenzen führen.

Die DSAG schätzt die bisherigen Fortschritte und die enge Zusammenarbeit mit SAP in diesem Bereich sehr. Gleichzeitig sieht sie großes Potenzial, die Funktionalität für multiple Adressen weiter auszubauen und auf zusätzliche Prozessbereiche wie S2P sowie weitere Module zu erweitern. Eine solche Weiterentwicklung würde Unternehmen dabei unterstützen, die Vorteile eines zentralen Stammdatenobjekts noch umfassender zu nutzen und die Datenqualität sowie die Effizienz in ihren Prozessen weiter zu steigern.

Die DSAG freut sich darauf, diesen Dialog mit SAP fortzusetzen und gemeinsam an Lösungen zu arbeiten, die den Anforderungen der Unternehmen gerecht werden und die Innovationskraft der SAP-Lösungen weiter stärken.