Accounts Payable (AP) is often the first initiative when it comes to Business Process Automation projects, and it’s easy to understand why. AP directly effects how much money leaves an organisation, it’s a business process typically fraught with manual steps, and it’s a process that crosses almost every industry so vendors tend to focus on it first. AP Automation can also be seen by senior management as a way to get some high value quick runs on the board and encourage staff involvement in the wider Digital Transformation strategy.
When it comes to the approval stages of an AP process, electronic approval of the Invoices is effective in that in confirms the accuracy and authority levels around vendor payments, however in some ways it is also the proverbial ambulance at the bottom of the cliff. As a budget holder, wouldn’t you rather people sought permission before spending your budget, rather than asking for forgiveness afterwards? If the approval is sought once the goods or services have already been consumed, then often it can be too late to reverse a transaction, even if you’d rather decline the authorisation of an invoice. When that happens, the approval itself essentially just becomes a rubber stamp.
The AP Invoice has an often-overlooked sibling document that is frequently left out of scope. One which I argue is more important to have an approval process wrapped around to ensure your purchasing policies are met. Of course, I’m talking about Purchase Orders (PO’s).
The very nature of a Purchase Order (PO) is to confirm the details of a transaction with a vendor before it happens to ensure transparency, accuracy and legitimacy of the transaction. However often the PO is left out of scope of the initial AP Automation project, which in turn makes the AP validation that much more difficult.
Here are just a few quick reasons why you should consider a PO Automation project:
Many New Zealand businesses, particularly the homegrown kiwi companies that started small and have since grown into the trusted brands we all know, still have the same processes around PO’s as when the business first started. The PO’s are often found in pre-printed carbon-copy books with hastily scrawled handwritten notations, often incomplete and without all the required details. Furthermore, they are often scattered throughout various desk drawers in multiple departments, or worse, across multiple sites.
Ask yourself a two quick questions: Right now, how many PO’s have been issued by your organisation that have not yet been invoiced? And what is the total value of those PO’s? If you can’t answer those question easily, or if you are beholden on end-of-month reporting to get that information out your systems, then ask yourself the follow up question: How accurate is our cashflow forecasting?
By leaving PO’s out of scope of a Business Process Automation project around AP Invoices, you run the risk of not having visibility across your PO’s and minimising your ability to track outstanding orders or missing invoices.
Purchasing approval is not always the enforcement of a monetary transaction limit, though granted that is a common factor. It can also be about ensuring staff are using approved vendors. It can be about ensuring bulk purchasing arrangements are adhered to. It can be about ensuring that due diligence has been carried out. In some cases, it can also be about fraud prevention and ensuring company money is being spent on company expenses.
Often companies that use PO’s have them siloed with the finance team who act as the gatekeepers to guard the access to corporate spending. This can sometimes mean the process leading up to the issuing of a PO is dependent on manual steps such as email correspondence, phone conversations, business case documents, vendor quotes, tender responses, and CAPEX requests. While there are some finance systems that can allow you to create and manage PO’s, very few can also manage these initial business steps that lead to the manual keying of a PO into the system.
It is important to realise that not all finance systems are created equally when it comes to purchase orders. Many advertise a PO functionality though they can sometimes be what I call a ‘Bullet-Point sales feature’. PO’s get listed as an option on a checklist of functional specs without much explanation as to how exactly they work. Some systems may let you create a PO, though it may be missing the approval steps. Some systems may give you a PO reference, but not actually create an auditable document. Still other systems may even force you to create a portion of your PO’s retrospectively after the invoice arrives, so that the PO is converted into the invoice in order to process the transaction. If your finance system only does part of the job, this begs an important question: What is the point? Sure, you need to do it because the PO reference might be a compulsory field in your finance system, but that’s a technical reason not a process one.
Technology should enhance best practice processes, not hinder them. The purchasing process does not start with the creation of a purchase order, so why would you have a business process or system that behaves like it does…?
When the AP invoice arrives one of the first tasks ought to be matching what you are being billed for against what you ordered and what you received. If this three-way matching (or two-way matching if you aren’t dealing with a goods invoice) is validated, and if your PO was approved prior to the order being placed with the vendor, how much value is added to your business to then route the invoice for approval again? By approving the PO ahead of the transaction, you are effectively spreading the approval process across the month rather than creating a bottleneck in your end of month processing.
If you have multiple people involved in the ordering process it could be easy to double up on some orders. When your PO’s are based in physical PO books it is difficult to detect over-purchasing before it happens. Similarly, when PO’s are paper based it becomes difficult to identify when a duplicate invoice is presented for the same PO.
You must ask the question: If the goal of AP Automation is to improve efficiency, why would you build your process upon a foundation of manual steps and paper-based documents? Addressing AP Automation without factoring in a plan for PO automation would be like servicing a race-car engine and not changing tires. Sure, it might drive faster on the straights, but will it be fuel efficient and hold the track?
So, before you start an AP Automation project, have a chat with us about the business objectives for your project. It might be that by addressing the scope of the project now, we can help you deploy a far more robust solution that delivers better visibility, accuracy, and efficiency to both the business and the users.
If you have any questions or would like to have a chat about how we can help, please contact us today.
Solution Sales Executive
Follow UpFlow Solutions on LinkedIn for more helpful blogs and videos