e-Procurement is simply the automation of the basic procurement cycle using information technology and the internet. This cycle starts with a requisition, may or may not require an authorization, and centers around the creation, transmission, and fulfillment of a purchase order. Thus, it also involves goods receipts, reconciliation, payment, tax reclamation, and analysis.
Since e-Procurement is, or at least should be, very straight forward, and since the e-Procurement Wiki spends a lot of time defining the procurement cycle, necessary core capabilities, and important features, we’re just going to talk about the functionality that differentiates a true e-Procurement solution from a set of tools that don’t really provide you the value that e-Procurement is supposed to promise you. Thus, compared to many of the posts in this series, this post will be short and sweet.
1. Does it support requisitions, orders, goods receipts, invoices, and m-way matching in an integrated fashion?
You don’t just want two way matching, or even 3-way matching – you want m-way matching that gives you the ability to match all of the data in the system that relates to a given purchase order. Before the purchase order is issued, you want to make sure it matches the requisition that was authorized. Before an invoice is paid, you want to make sure that it is for the items in the purchase order, that were received and annotated in the goods receipt, at the rates agreed to in the contract, and at the rates in the current price list if the contract rate is defined as a discount off of a catalogue or market price. Thus, even 3-way invoice to purchase order, goods receipt, and contract might not even be enough functionality for every buy! And anything less definitely will not cut it!
2. Does it integrate with a modern supply network offering that lets you and your suppliers manage your catalogue and pricing as appropriate?
Let’s face it – the whole point of e-Procurement is that it’s supposed to make the process of buying easy! If you have to use a separate application to find what you need, and then manually enter that information into your e-Procurement application, that’s not easy. Moreover, the “compliance” and “decreased maverick spend” many vendors promise will never materialize, because you can’t even be sure the purchase order is correct since human error can creep in at the requisition stage. (The buyer can get the product identifier wrong, the product wrong, or even the price wrong. And if a vendor gets a purchase order with an approved purchase price that is higher than what’s in the contract, do you really think they are going to point that out?)
3. Does it integrate with your payment system and allow payments to be correlated to invoices?
A lot of the e-Procurement solutions out there don’t do e-Payment, and that’s fine, as long as they recognize that it’s not an e-Procurement solution if it doesn’t recognize payments! Simply noting that an invoice is paid is not only not very useful (especially if the supplier disputes the fact), but probably not in compliance with good accounting practice or Sarbanes Oxley. At least one system has to track complete payment information and correlate that to invoices in your enterprise, and I don’t know about you, but I thought that was procurement, and, hence, that the capability belongs in an e-Procurement application!