Source-to-Pay (S2P) & Procure-to-Pay (P2P)

Source to Pay

In the market of software procurement solutions we often hear both Source-to-Pay (S2P) and Procure-to-Pay (P2P) used interchangeably. The difference between the two being that S2P extends the P2P process into strategic sourcing. S2P is an end-to-end procurement process that covers sourcing, negotiating with, contracting and payment of suppliers. Typically when discussing these subjects we are considering solutions such as Ariba, SAP or Coupa.

These tools incorporate big data, data analysis on market trends, historic spend, process management, spend management, supplier/sourcing management, invoice management and more, to:

Provide greater visibility into the procurement process
Integrate the procurement processes into one platform
Strengthen processes, support regulatory and contractual compliance
Improve collaboration during sourcing
Facilitate the negotiation better pricing
Provide more accurate spend forecasting

Tackling Source to Pay

An S2P solution is typically deployed through the implementation of S2P or P2P software solutions. SaaS vendors in the space generally have not just a software platform to support the process but also a platform of suppliers. Being able to see both a community of suppliers for sourcing and trend data on what the buying community has procured gives the organisation far greater visibility into their procurement.

Implementation generally entails in depth analysis, understanding and mapping of procurement processes to the selected software platform. In order for the platform to be able to appropriately manage procurement, you essentially need to map your chart of accounts into the platform. This includes suppliers, cost centres, nominal codes, commodity codes, budgets, approval limits and approvers. We might view this as the standing data that supports the implementation of the procurement system. However this data is subject to change with new cost centres being set up periodically, suppliers removed, suppliers added, cost centre owners and budgets changing. It therefore needs to be integrated.

Along with the ongoing changes to reference data, we need to manage approval chains and then handle the bulk of the integrated traffic in the form of invoices passing to the finance system and payments passing back to the procurement system. Notwithstanding that finance systems can be quite complex to integrate with or provide limited options for integrations, organisations also have the added challenge of having to model and integrate a hierarchy of data. The hierarchy comes from both the chart of accounts and the approval chains that need to be represented in the procurement system.

Common Mistakes

Organisations often realise post-procurement of a S2P solution that they have significant work to do in terms of rationalising their chart of accounts. This can lead them to an unnecessarily complex implementation of a S2P solution and a significantly extended delivery cycle.

It’s common to find that your finance system doesn’t store all of the hierarchy of standing data required for the implementation. Ownership of cost centres, approval limits, authorisation of sign off or the right authorisation chain of approval. Sometimes we need to look to directory services in the organisation or the HR system to derive some of the standing data.

Another mistake in implementation comes from confusing what you need to know and when you need to know it. This can compromise the experience for the end user by expecting them to be able to classify exactly in finance terms where something they are buying will ultimately land in the finance system. Often these items can be retrospectively classified in accounting terms by more skilled employees with knowledge of where things should sit.

Lastly, with all the complexities inherent in this type of implementation timing can often force organisations into developing very tightly coupled solutions or point-to-point implementations of integration. This ultimately leads to vendor lock in with both the S2P and ERP solution.

How Chakray Help

At Chakray, we help organisations of all sizes navigate complex integration challenges. Understanding when data models and concepts have broader application in the organisation helps get things right from the onset. We build integration solutions that expose API entry and exit points and make sure data models that underpin APIs are appropriate and represent the business rather than the software solution. In doing so, we help you avoid vendor lock in.

We work with organisations to ensure flexible integration solutions are deployed that enable digital delivery throughout the organisation rather than implementing isolated point solutions.

Get in touch