Skip to Content
Product Information
Author's profile photo Kandasami Pirahalathan

Experience Seamless Supplier Integration with SAP Ariba Powered By Master Data Governance


In today’s world, smart and informed shopping has become a common affair. It’s a big discussion point in every household when it comes to choosing the perfect deal. In the earlier days it was a cumbersome task with limited options. It was very difficult to reach out to every vendor in every corner of the world to get the perfect deal that meets all our expectations. Today, thanks to the new era of digitization, we get all this and more in the comforts of our home. We have online commercial portals providing us a huge number of options where we get to see a huge supplier network. It makes our life very easy and enables us to get the best deals with minimal hassles.

Similarly, when it comes to sourcing, in big enterprises or for that matter in all kinds of big or small companies it becomes an even bigger challenge. Organizations invested on traditional ERP systems, spending a lot of time on finalizing agreements for critical raw materials for their manufacturing unit. Finding a qualified vendor is a major challenge and managing multiple vendors is also a cumbersome task.

To cater to this challenge SAP Ariba offers “Ariba Supplier Lifecycle and Performance (SLP)” which acts as a single hub for storing all Supplier related information and is shared by multiple cloud applications like SAP Ariba Buying and Invoicing, Ariba Sourcing and Contracts. SLP supports seamless integration with SAP ERP. Supplier data that is maintained in ERP integrates seamlessly with SLP and vice-versa.


Fig. 1: Data Synchronization and Sharing in SLP

Ariba Supplier Lifecycle and Performance (SLP):

Ariba Strategic Souring Suite bundle has the subscription of Ariba SLP (Supplier Lifecycle and Performance). Ariba SLP solution is a Unified vendor master in the cloud.  SLP provides a Comprehensive 360° view of the supplier comprising of supplier information, qualification, segmentation, performance and risk data. These are Scalable supplier management matrices based on region, category and business unit. Finally, SLP is Integrated with SAP Ariba procurement applications.


Fig. 2: Supplier 360 in SLP

SLP unifies the internal data available in Vendor Master in ERP systems. For e.g., Purchasing Organization and Company data can be integrated to SLP. Suppliers can also maintain their details directly in SLP. Apart from that the Supplier data is enriched with performance and risk data.


Fig. 3: Supplier Data Model in SLP

SLP Architecture:

SAP Ariba Supplier Lifecycle and Performance is a new product within the Ariba Applications Suite, enabling organizations to actively manage their entire Supplier Master in the Cloud and implement global procurement strategies and policies.


Fig. 4: SLP Architecture

SLP supports the following:

  • New vendor data model, with native integration to SAP ERP, and a web-services architecture for other systems.
  • Flexible hierarchical matrix, which allows managing suppliers based on a combination of category, geographical location, and other dimensions.
  • Complete supplier lifecycle support, including registration, qualification, preference management, and phase-out.
  • Re-designed user experience, with guided processes and streamlined user interaction.
  • Comprehensive 360°view of supplier, aggregating supplier profile, contacts, qualifications, sourcing events, contracts, transactions, performance, spend and other (external) data into a single overview.
  • Native integration to the Ariba Applications Suite (Sourcing, P2O/Guided Buying), providing supplier profiles and enabling compliance with sourcing and procurement policies.

Deployment Model:

Organization can have multiple lines of business and each LOB has its own landscape that manages the suppliers in its ERP system. In most of the cases, same vendor supplies the raw materials to different LOBs. Now, the same vendor is identified with different IDs in the different ERP systems. The unified vendor must be maintained in the Ariba cloud, so that it can be referred by multiple ERPs. Hence, the Vendor details across their LOBs needs to be consolidated. MDG(S) takes care the uniqueness of the Supplier data and maintain the information in SLP.


Fig. 5: Multi-LOBs are transacting with same Supplier A


1) SLP integrates with Multiple ERP system


Fig. 6: Supplier Master is distributed across Multi-ERP landscape


2) SLP integrates with Single ERP System


Fig. 7: Supplier Master is distributed in Single ERP landscape

For those customers, who have a single ERP instance and implement SLP, the Supplier data can be integrated with SLP provided the ERP is having MDG (Master Data Governance) plugin along with DRF (Data Replication Framework).

As we see in the above two deployment model, MDG plays a crucial role in consolidating suppliers, and with the help of DRF replicates unified supplier to the SLP. In addition to this, MDG helps procurement and supply chain LoB to overcome various challenges that they come across during the process. Following are few key challenges faced:

  • How can I improve my procurement decisions, i.e. supplier performance / evaluation, avoid duplicates, spend analysis that falsify my view on my suppliers?
  • How can I ensure high quality of my supplier data, in order to save costs and efforts in subsequent processes, such as shipping to the correct address and, assigning the best source of supply?
  • How can I get complete transparency on who has changed what, when and why?
  • How can I establish a single source of truth for supplier master data in my multi-system environment?

Capabilities of Master Data Governance:


Fig 8: Master Data Governance


  • Upload into MDG via file or services, and complete further processing in MDG. In addition to central maintenance, data from external sources is supported.
  • Perform Duplicate Checks
  • Apply, reuse, and integrate existing business logic and infrastructure to validate data
  • Validate change requests using prebuilt workflows and user interfaces within SAP Business Suite
  • Maintain a verifiable audit trail of when, why, and by whom master data is changed and Change requests with built-in approval process
  • Perform single item maintenance and mass maintenance available
  • The data model can be extended by customer
  • Perform Easy Search & Display, Flexible Create, Change, Mass Change, and Mark for Deletion
  • Control master data flow between SAP and non-SAP applications with predefined data models
  • Replicate changes ad hoc, by schedule, or via workflow using enterprise services, SAP IDocs, RFCs or Flat Files


MDG with its inbuilt validations in place makes sure a consistent supplier master data is available across the entire organization. As we have seen in both the deployment models, with the help of DRF replicates the data to SLP. Let’s see how DRF helps to replicate data.


Fig 9: Data Replication Framework


DRF is capable of replicating data to SAP and non-SAP systems. It supports the replication of data into systems with non-harmonized customizing or with heterogeneous keys for material. For example, in cases where the same material has a different material number on the master data governance (MDG) hub than on a client (key mapping), or similar material groups have a different code in hub and clients (value mapping), it has the flexibility to replicate selected data only to a specific client system by defining filters. It uses the existing communication channels like Enterprise Services, ALE/IDOC, RFC and File. It also monitors the replication activities, failures etc.


“We will share more insights on One Master Data Service (MDS) and more details on Data Replication Framework and its usage in the Ariba Cloud products in subsequent blogs.”


Stay Tuned!!


Authors –

Kandasami Pirahalathan         – SAP Ariba

Kanhu Ranjan Padhi                – SAP S/4HANA Procurement

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sitakant Tripathy
      Sitakant Tripathy

      Great article Kandasami Pirahalathan Kanhu Ranjan Padhi on SLP. We had a issue with the SLP integration coz we were on EHP5 and I had to spend some time to read the stack to make it work. I must say SAP has done brilliant work in reusing these robust stack even if they are like more than a decade old and SMT stands out as an amazing utility. If only I had found SMT earlier?.

      waiting for the follow on blogs.


      Author's profile photo Kanhu Ranjan Padhi
      Kanhu Ranjan Padhi

      Sitakant thanks a lot.

      Yes Service Mapping tool (SMT) we need to use which is required during replciation and which also handles the key aspects like key and value mapping.

      Kanhu ~


      Author's profile photo Praveen Rohankar
      Praveen Rohankar

      Awesome blog.

      Can you please also help to understand the process of replicating the legacy vendor data in SLP when the customer already have the Sourcing & Procurement in their landscape and now wants to implement SLP.

      Author's profile photo Kanhu Ranjan Padhi
      Kanhu Ranjan Padhi

      Hi Praveen,

      Sorry for the delayed response. We will reply to your query soon.




      Author's profile photo Mrutynjaya Vishwanath Mavuri
      Mrutynjaya Vishwanath Mavuri

      Nice Blog, Can you help me to get the below details

      How master data is/is not flowing between each of the modules of Ariba (SLP, B/I) & Sourcing and Contracts (S/C)?

      • How is Supplier master data utilized for S/C? Does B/I share supplier master with S/C or is it a separate table within Ariba modules?
      • If a supplier is setup in SLP, what data is shared with S/C?
      • What are other master data required to be loaded for S/C?
      • How is any updates/changes to data (supplier, pay term) reflect between the modules (SLP, B/I, S/C)?
      • How can we trigger self-service portal (supplier registration form) for legacy loaded suppliers ?
      Author's profile photo Kanhu Ranjan Padhi
      Kanhu Ranjan Padhi

      Hi Vishwanath,

      We will respond to your queries shortly.



      Author's profile photo Mauro Ferradini
      Mauro Ferradini

      to directly address your questions:

      • S2C and B&I run on different databases, and keep in sync some of their data. One of these elements is the Common Supplier, which represents all the supplier data you find in S2C but doesn’t contain operational data such as Partitioned Supplier or Supplier Location. This last is only managed within B&I.
      • SLP replicates to S2C all that S2C can accept: what fits into a Common Supplier and into a supplier user (from a Contact in SLP).
      • No other data. B&I on the other hand, as of today, needs both the partitioned and location data loaded separately via CSV.
      • Updates flow from external systems to SLP and from there, if applicable, to S2C. As of today there is no integration between SLP and B&I (while its on the roadmap however).
      • SLP features a similar Self-Registration feature as legacy SIPM, but legacy loaded vendors will likely need to go through a mass-invitation process rather than a self-registration process. If your question is about allowing legacy loaded vendors in B&I (hence also available in S2C) to autonomously register themselves in SLP without an invitation and match the existing record, that is not possible.
      Author's profile photo Joni Salmela
      Joni Salmela

      Hi all!

      Great post indeed.


      1. Any thoughts on the direction that Ariba SLP would be going regarding to supplier hierarchy and how would this be in sync with SAP ERP / MDG vendor models (vendor types and partner functions)?


      2. Any thoughts on what implications there are for  the supplier / vendor model when the aim is eventually to run sourcing event + create a contract + push the contract vis CLID or Contract terms document to ERP or P2O solutions + order + receive invoice, as all are requiring supplier ID, but which (especially with large companies) is not the same entity for all the steps. Hence some sort of hierarchy would be needed in my view.

      Here especially thinking what would be the best practice setup when thinking about the different levels of supplier entities (e.g. HQ supplier vs local subsidiaries) and which supplier level should be used for:

      A) registering in SLP

      B) Sourcing

      C) Contracting

      D) GOA (contract) in ERP / Contract Compliance in Buying

      E) Ordering

      F) Invoicing


      Would be interested to elaborate a bit more and sparr around the topic


      Thanks and have a great summer! ☀️