Skip to content

How to Create a Business Justification for Automated Invoice Processing - Part 1

John Stinchcombe
By John Stinchcombe, 05 January 2021

In this 3-part guest blog, digital transformation expert John Stinchcombe considers how end customers can create a business justification for invoice process automation.

Part 1: Introduction, how automated invoice processing solutions work, key success factors for this software application

Part 2: Factors to consider when building a business justification, risks vs rewards.

Part 3: Implementation and ongoing costs, financial and non-financial outcomes, summary.


Part 1

Introduction

The purpose of this blog series is to highlight the sky-high inefficiencies endured by organisations undertaking AP Invoice Processing. It’s easy to forget that solutions for this particular business problem have been available for a couple of decades.  If the problem is that painful then the business justification should be relatively easy to prepare.

Traditional Invoice Processing involves an experienced AP team member working through each supplier invoice (whether submitted in paper or as a PDF via email) and meticulously running through prescribed steps to verify its validity and accuracy before submitting it to ERP for payment. This process varies by organisation depending on whether there’s an associated purchase order or supply contract. On completion of these essential checks and balances, and once any exceptions are managed as well as optional approvals granted, payment can be made to the supplier.

It’s often said that such a prescribed process should be easy to automate and that the nirvana of ‘straight through processing’. In other words, 100% automation should be possible. 

However, such an ambition is not all plain sailing as many organisations who were sold such a vision will attest.


How Do Automated Invoice Processing Solutions Work?

Before getting to the business justification, it’s worth reviewing how these systems work and have evolved over the past 15-20 years.  The first systems worked with scanned paper invoices and most only this type of input. These were often referred to as ’Invoice Scanning’ or ‘Invoice OCR’ systems.

The earliest of these systems required that individual supplier invoice layouts were ‘templated’ in the system.  This was necessary to ensure that OCR processed only those elements on the scanned image that needed to be converted to data; this data was checked using business rules or compared to verification data such as supplier information from the finance system.  A ‘Validation’ interface allowed users to check and amend fields that were flagged by the OCR or verification process as suspect. This was the extent of the human involvement in the process.

Later, OCR-based systems performed a full-text OCR process that created a digital representation of the entire invoice; data-parsing algorithms then set to work to identify and extract the relevant invoice data fields. As these systems were essentially working on newly created digital data, it wasn’t too long before native, electronic format versions of invoices (such as PDF, Excel or HTML) were processed with the same algorithms.  The benefit of these systems was that no templates were needed, the so-called data extraction algorithms or ‘locators’ did the heavy lifting to first identify and then extract each data field.  Ironically, these systems work best for most standard native electronic documents but due to the large variety of invoice layouts and standards, unreliable results were sadly all too common.  Such scenarios naturally led to comparisons with manual systems and brought into question the viability of automation solutions.

One of the challenges with these early generation invoice processing systems is that sadly, their efficacy falls away steadily almost as soon as they’re implemented.  Simply put, invoice layouts change over time and organisations add suppliers with invoice types that the system configuration may have never encountered.  Frustratingly, some fields of these new invoices would be recognised but others would not.  Very few organisations could justify the expense of a technician’s time to add these invoices into the ‘invoice project’ and so a degree of manual intervention was needed until the next system review and update of the invoice processing project.

Contemporary solutions such as Kofax Readsoft Online and Kofax AP Agility combine the best of these techniques along with machine learning. Automated Invoice Processing is an excellent fit for machine learning as specific invoice layouts proliferate and once learned, the benefits of an already learned invoice layout can be shared with all users of the system. 


Key Success Factors for this Software Application

In order to automate this process, we need to replicate tasks that are performed by human beings. In short, this can be summarised below:

  • Review each invoice for validity, e.g. VAT number, supplier details, reference to your organisation.
  • Check supplier identification details down to specific legal entity if applicable.
  • If present, check the validity of any Purchase Order reference.
  • Retrieve the corresponding Purchase Oder and match the invoice line details, SKU/article codes, quantity, price etc with your purchase order (note that this can become complex where partial shipments or call offs are permitted).
  • Check whether goods/services have been received and receipted as acceptable quality.
  • Optionally assign a GL cost code to each of the invoice lines.
  • Check invoice sign-off matrix and if applicable, send the invoice for approval.
  • Chase approvals until all approved.


There are two important factors to face when considering the automation of Invoice Processing and building a justification. You can read about these in Part 2 of this 3-part log series.


Find Out More:

We use cookies to give you the best experience of using this website. By continuing to use this site, you accept our use of cookies. Please read our Cookie Policy for more information.