Invoice processing in Accounts Payables is a commonly quoted use case for RPA. I see it commonly referenced all across multiple RPA use cases and case studies. It’s not hard to imagine why – it’s a manual intensive process – logging into multiple systems, reconciliation of data. You follow Route A in case there is an error or Route B if there isn’t.
But an interesting article I recently read encouraged me to scratch under the surface and take a look at what realistically can be achieved with RPA in invoice processing automation. Are things really that simple, especially for an enterprise? While in this blog we will analyse only the invoice related use case, I think the thought process can be extrapolated for any other process that you may be evaluating to automate.
Before I move on, first things first, I am taking an example of a large enterprise for this extrapolation- A company that probably has multi- location/currency/lingual operation. The reason of doing so is to demonstrate a scenario where the company may be interacting with the same vendor in different countries in a different manner. Thus we are taking into account more variations in the invoice template.
Let’s look at the text-book journey of an invoice before lands in the ERP
- Invoice Capture
- Validation ( Matching, de-duplication, errors)
- Linking to PO and delivery notes
- Approval Routing (Translation step may be added)
- Approved invoices sent to ERP
And now lets study the scope of variability in invoices
- State: The invoice can be an image that needs an OCR engine for data extraction or it can be a digital document like a PDF. So we have 2 states in which an invoice can enter the system
- Format: Word file, Paper, Fax, PDF file, XML, XLS or for that matter data housed in applications such as ERPs, Mainframe, CRMs. Roughly practically you can encounter at least 6 different formats ( Word, XML, PDF, Fax, XLS, from CRM/ ERP)
- Template – Every single country and sometimes even region can have its own template (Due to applied taxes, formats will differ for each financial jurisdiction). I think we can safely assume that if you are enterprise working with different countries, you will easily encounter at least 20 different templates. Please note that even the same vendor can have different templates based on the region of invoicing.
Now let us combine these scenarios and come up with a number
State(2) x format(6 )x Template(20) = 240!
There are 240 scenarios that your Robots need to tackle! And God forbid if something crashes in there because it could not read a certain number properly. A complicated troubleshooting exercise follows.
A wise workaround maybe that we don’t start automation for all in one go. We look for the most prolific path. Example 30 p.c. invoices are generated by a Vendor A, these come in a PDF format and come from the US region. So this is easily a good candidate process to start with and then netting in the next best candidate.
Summarizing it all, before we start an RPA exercise, just step back and try to go incremental and build up on it. Taking on too much too much complexity in one go will only increase chances of failure. Lets give RPA a fair chance.