Are you tasked with selecting a new purchasing system or procure-to-pay system for your organization?

Then the obvious question to consider is – What are the different use cases for Procure to Pay / Purchasing system, and what makes sense for your organization?

You might be in  IT and tasked by CFO to look for a system to automate your purchasing process, or you are a purchasing manager looking to automate the manual paper-based process.

You could also be a procurement rockstar and looking to further optimize your team’s performance by modernizing your procurement systems.

You started with a simple problem statement, and after some time on Google, you now have multiple vendor options to choose from and different use cases to choose far.

We understand your pain, and this has a lot to do with the proliferation of the market with different vendors. There is no shortage of purchasing automation vendors.

Don’t agree with us.

Just search “purchasing software” on google and see the vendor listing on Capterra.

And then you can see results on Capterra

There are 103 vendors who offer purchasing software

Now if you are in purchasing you must be thinking, that is great news. It’s a buyer market and we have a lot of options.

But the bad news is that you have to look at these options and decide what is best for you.

Now how we got to a place where you have 103 options for a procurement system. That is a topic for another blog post.

But on a high level – Capterra is an online directory of software vendors so it is easy to get listed. But beyond that, the evaluation of capabilities is left up to users like you.

Another reason for this vendor proliferation is that different vendors might be catering to different use cases and it is not one size fits all.

Yes, we are stating the obvious but that is the reality of the market.

Don’t worry, we got you covered.

In this post, we will cover common use cases for Procure to Pay or purchasing system and then define the pros and cons of each.

End of the day, you have to decide what is best for your company but our hope is to help you decide on a direction and use case which is best for your company given your current situation.

Each of these use cases has different implementation cost and different complexity when it comes to rollout and adoption of a system like this.

So keep that in mind, simpler the use case – less expensive the solution and easier to roll-out to the entire organization.

Let’s get started

1. Purchasing use case

This is the most common use case when it comes to purchasing automation.  This use case covers the basic requisition process and the process ends with a purchase order created and sent to the supplier.

What problem does it solve?

A company might have in an adequate process for the purchase requisition. We see this commonly with companies who either have manual/email based purchasing approval process or a process set up in an old ERP/Accounting system.

The goal for the company is to automate the process and set up a basic purchasing process. The steps involved in this use case are

Requisition creation and approval

1. Users are able to create requisitions in a user-friendly web-based system. The requisition can then be worked upon by the buyer before it can be converted into an order.

2. The approval process can be fully automated using this process. Any good procurement system should be able to handle all the approval scenarios. Some common examples we have seen with our customers

– Approval based on the job title. For example, a Director can approve up to $100,000.

– Category based approvals – for example, all IT spend should be approved by an IT person before the order can be sent to the supplier.

– In some cases, companies have a blanket approval process. For example, anything over $100,000 needs to be approved by an executive director.

3. In case users know what they are looking for, the orders can be created directly by the users. This can be easily achieved by establishing catalogs for users.  All commonly purchased items can be added to a catalog.

The users can then search the catalogs and that enables an Amazon.com type user experience for your employees.

There are two types of catalogs which can be implemented, Supplier catalogs and internally managed catalogs.

Supplier catalogs as the name suggests are managed by suppliers. These catalogs are also called Punchouts and are implemented for those vendors who have a large spread of items. A common example of punch out vendors is your office supplies vendors like Staples or Amazon.com

Internally managed catalogs are managed by the purchasing teams. Once the price is negotiated, the team goes in and create an item in the catalog.

It is very similar to setting up an item in the item master but with a lot more information which enabled users to take better purchasing decisions.

ProcureDesk enables this by providing an intuitive interface for users and an easy to manage catalog management for the purchasing team.

Purchase orders

4. The system also generates the purchase order which can then be sent to the supplier. For the order to be sent to the supplier, most systems like ProcureDesk requires that a supplier record exists in the system. Also, the suppliers should be involved in this on-boarding process so that they are aware of the new system.

We generally encourage our customers to onboard their suppliers because that eliminates a manual step from the process.

One thing to keep in mind is that some systems need long onboarding process for the suppliers and that can significantly reduce the number of onboard suppliers. The onboarding process generally requires 1-1 call with vendors and that requires time and effort on both sides.

You vendors might not have times for this and especially if you have a lot of small mom and pop suppliers. The solution should be not just easy for your users but it should also be easy for your suppliers. You should avoid long on-boarding processes.

Benefits of purchasing use case 

1. The company sees an immediate boost in productivity for the purchasing team because the entire order process is now automated.  

2. Employees get an easy to use purchasing system, which leads to a better experience for employees. Better experience with purchasing process leads to better engagement with Procurement and more spend under control.

3. We generally see some reduction in Spend either through cost saving or cost control. Given that executives now have better visibility into Spend, they can make better decisions on whether a specific spend can be avoided.

4. Catalogs drive a better experience for users but also gives better spend visibility to the procurement team. The team can then use this visibility to drive better cost savings across the board.

Pros

This approach is faster to implement as the use case is limited to purchasing. So faster time to value.

Cons

1. You still need to spend effort on on-boarding the suppliers, with the same effort you can also onboard them to submit invoices, which we discuss in the next use case.

 

2. Purchasing and invoice automation use case

What problem does it solve?

This use case addresses the problem of an end to end process automation. Companies who implement this use case are looking at increasing the efficiency of their entire procure to pay process. There are obvious benefits to this approach which we will discuss later.

You normally have a process owner who is responsible for looking at the end to end process and working across procurement and accounts payable teams to design a process which is efficient and enhance the productivity of both teams.

Once the process is defined, any good Procure to Pay tool can help you automate this process. If you have a single system to manage the end to end process, you can avoid a lot of issues with data transfer between different systems and the headaches which come along with that.

What is a good procure to pay system?

 One system doesn’t fit all so we have defined how you should go about defining your use cases and working with vendors to find the best fit for your organization.

What is covered in this use case?

1. It covers all the steps we mentioned above in the purchasing use case.

2. After the purchase order is sent to the vendor, you can also have your vendors acknowledge that they have received the order.

3. Once the product is shipped, the users can then create receipts in the system. You should look at the cases for self-receipts, also called Desktop receiving and centralizing receiving.

A word of caution, if your users are not used to creating receipts then may be centralized receipting would be your best option to start with.

Once the process is up and running, you can then start incorporating desktop receiving for certain categories. The objective of creating a receipt in the system is to acknowledge that the product has been received. It is not going to help if users just blindly accept receipts.

4. The next step is for the invoice to be created in the system. There are two ways this can be managed.

a) A/P team index or create the invoice in the system.

b) Supplier submits the invoice in the system through a supplier portal or EDI.

When you are looking at the business case for Procure to pay system, you should be looking at the productivity gains which can be achieved by moving suppliers to e-invoicing. That means that suppliers are able to submit their invoices online without the need to send the invoices to A/P department.

This will significantly reduce the workload on the A/P clerks and those resources can then be moved into more value-add resources like early payment discount analysis, duplicate invoice analysis etc.

The only adoption challenge with e-invoicing is on-boarding suppliers to the supplier portal or something similar where they can submit the invoices.

The other way to onboard suppliers is to transfer invoices through EDI – Electronic data interchange.

EDI significantly improve the productivity for both suppliers and customers. If your supplier does have the capability to do EDI transactions then that is always preferred.

Before you embark on e-invoicing, you should look at your top suppliers and assess their capabilities with EDI. You should also ask your suppliers if they already use some sort of supplier portal so that you can assess the viability of on-boarding them to another supplier portal.

At ProcureDesk, we have transitioned to an email-based system so that you don’t need to onboard your suppliers and they can still submit invoices electronically without the need to go through a length email process.

5. Matching process

The next step in the Procure to pay process is matching the incoming invoices with the orders and receipts to ensure that all documents are matching before the invoice can be cleared for payment.

This is not just a best practice but could also be a mandate to meet compliance for Section 404 of Sarbanes Oxley. There are two types of matches which can be configured in any procure to pay system.

2-way match

In a 2-way match scenario, the system matches the invoices with the purchase orders and ensures that the quantity and price match with the purchase order. The 2-way match should be only done for services since there is no receipt.

A word of caution for A/P teams – It is very common that suppliers send their invoices in advance and the service might not be fully delivered or not delivered as per the satisfaction of the stakeholder. You might want to look at a process where someone in the budget owner team is accepting the invoice before it can be paid.

3-way match

In a 3-way match scenario, the system matches the invoice with purchase order and receipt. If the quantity, price etc. is the same on all the documents, the system then marks the invoice for payment.

The process is straightforward if everything is common across all the documents but that is not the case always. There would be times when these don’t match. The system can them follow a process to check if the exceptions are within a tolerance range.

You should be able to define a tolerance range in which you are ok to accept exceptions. For example, the order quantity is 100 and supplier sent 101 because that’s how they sell the items. If you have a tolerance defined, the system can check if the exception is in the tolerance range, and if it is, it will automatically send it for payment.

6. The last step in the procure to process is the payment to the supplier.

This may or may not happen in the procurement or procure to pay system. Most P2P systems do have this functionality but companies land up relying on their ERP system for payments.

This is primarily for the reason that they are also making other payments from the ERP system and they don’t want to have two different systems for payments.

7. If the payment of the invoice is happening in another system then there is an additional step of sending the payment status back to the procure to pay system.

In that case, the integration interface can take care of sending the payment status back to the procurement system.

The common data sent back to the P2P system is remittance data, remittance method ( Check or ACH) and reference details.

If you have a supplier portal and suppliers are enabled on the portal, they can see the payment/remittance details on their own and they don’t have to call your A/P department for inquiring about the payment status.

Pros

1. This use case is very helpful for middle market companies because it automates the end to end process and increases the efficiency of the whole process.

2. P2P automation improves the productivity of both procurement and Accounts Payables teams.

3. It provides better spend visibility and allow finance and budget owners to ask better questions. If you can link spend from invoice to order to requisition, then that allows a granular visibility for everyone and hence enable better decision making.

Cons

1. It requires a longer implementation cycle because it involves a long process and both procurement and accounts payable teams.

2. You also have to consider additional reporting requirements around control totals so that you can ensure that invoice count and amount sent to the ERP system matches what is in the ERP system.

3. It requires more integration touch points based on the approach you have decided.

4. It is more expensive overall because of more features.

 

3. Requisition only use case

This use case address only the requisition part of the procure to process. The requisition is created in the procurement system and after approval is sent to the ERP system for further processing.

What problem does it solve?

It is not uncommon to see this scenario in large companies who are using ERP systems SAP or Oracle.

The purchasing and invoicing process is well established in the ERP system but these companies are looking for a good frontend process for the Indirect spend purchases like IT, office supplies, services etc.

So instead of implementing a new system, they would implement a new requisition and approval process which modernize the experience for the end users but keep the process same for back-end functions or teams.

The ERP system handles PO transmission to the vendors and rest of the process is handled in the ERP system. The typical process in the procurement system is as follows

1. The user creates a requisition in the procurement system.  This is the same use case as described in the Purchasing use case.

2. The requisition is then approved in the procurement system.

3. Once the requisition is approved, it is sent to the ERP system.

4. The ERP requisition module then converts the requisition in the purchase order.

5. The rest of the process is then handled in the ERP system.

Pros

1. It is easy to implement because of the simplicity of the use case.

2. It provides a better experience for end users, especially for casual buyers and without the need to change the entire process.

3. It is lower in cost both from the implementation perspective as well as ongoing subscription cost.

Cons

1. It only solves for the end users but this use case doesn’t address the end to end use case for productivity improvement.

4. Procure to pay with third-party invoicing

In this use case, the invoicing doesn’t happen in the procure to pay system but on a third party system or portal.

The procurement system is still responsible for conducting 2 and 3-way match and sending the invoice back to the ERP system for payment.

What problem does it solve?

It is possible that your company is already using a third party portal where your suppliers are submitting invoices.

Those invoices are then sent to your ERP system for further processing.

Now while you are evaluating the procure to pay use case, you might not want to use any new portal. It takes time and effort to onboard suppliers on a new portal, so it makes perfect sense to use existing investment in a third party portal.

So this is how it works

1. Your employees use procure to pay system for creating requisitions.

2. Requisitions are then approved and Purchase orders are generated by the purchasing system.

3. The receipts are created in the new procurement system.

4. Invoices are created in the third party invoicing portal and then imported in bulk into the procurement system.

5. Procurement system then matches PO, Receipts, and Invoice.

6. Once the invoices are cleared, the procurement system sends it to the ERP system for payment.

Pros

1. It protects the current investment in the supplier portal.

2. Your suppliers don’t have to go through training for a new system and that it huge time savings.

3. It reduces the overall implementation time.

Cons

1. The suppliers might have to use two different system in the case.

2. It increases the integration complexity because now you have to integrate with another system for invoices.

3. It could increase additional complexities because the matching process could take more.

5. Conclusion

We have covered four main use cases for purchase to pay system and we are sure there are more which are not covered here.

Of course, it is up to you to decide what scenario makes sense for you. While you evaluate what use case makes more sense for you, use the following considerations

1. Who are your key stakeholders and does the use case solve the key issues for them? 

2. How complex is the use case? A simple user case reduces the time required to implement it and it reduces the implementation cost.

3. What can you IT team support? Vendors would provide integration support ut your IT team still needs to be involved. Make sure your IT team can support the chosen use case in the desired timeframe.5.

Here is a quick comparison of the  different scenarios and the features available in each one of them

ProcureDesk can help with identifying the right use case for your organization. Sign up for a free consultation.