This blog is part 2, covering "Leveraging AI to Automate Invoice Processing". If you haven't already, check out part 1 or our recently released webinar on the subject!
The previous attempts at automating processing - the last remaining manual step - based on early OCR and invoice exchange technologies have not quite delivered. However, new AI-based services like Oracles 'Document Understanding' have stolen the show and promise to help free finance teams from the baggage of manual invoice processing!
From creation to transfer, processing and storage, while catering for physical and/or digital documents, the holy grail of end-to-end invoice workflow automation has arrived.
Oracle APEX is a low-code application development platform that allows developers to build secure, scalable and feature-rich applications with out-of-the-box components suitable for enterprise-level applications, with the speed and flexibility of a start-up.
APEX streamlines what developers have been doing already, which is taking shared solutions (sometimes open-source) built and managed by someone else and incorporating them into new projects to save time and maintenance. The difference for APEX is, that the entity doing the sharing and maintaining is Oracle, and all the components therein come with tangible, enterprise-grade support and longevity.
The APEX components of which APEX applications are built cover all manner of things, some examples being:
Because all these features (and more) come standard, the vast majority, if not all repetitive coding is eliminated. This allows developers to focus on the tasks that are truly bespoke to your requirements with no restrictions. As an APEX developer, I can deliver more to the same or higher standard and save time compared to traditional development. And as we know, time is lost opportunity, and time is money.
Looking at our invoice processing solution, we're using Oracle APEX to implement our validations, custom workflows, approvals, and ERP integration into a single application.
Initially, the invoice is subject to validation. Most validations are generic, but some are supplier-specific, both types being configurable using the application. Validation failures trigger tasks to remediate, that then appear to users during the running of custom workflows.
Those custom workflows can be as simple or complex as you need. In our case, some invoices require additional data from several departments before they move on to approvals. With Oracle APEX workflow features, an invoice journey can be tracked and assigned to each department in turn as a pending task, and the departments required are dynamically chosen based on the supplier. Each department would then see a page unique to them to capture the different types of data needed, only progressing to the next department once all required data has been captured, or, if there are no dependencies, all departments could have a task assigned to them simultaneously.
With all additional data in place, both from Document Understanding and supporting departments, the invoice is sent for approval. This is automatic if certain conditions are met, for example, invoices that come from a pre-determined list of suppliers and are under a certain value. Similarly, some invoices need one or multiple levels of approval depending on the value.
Once an invoice has been validated, with supporting data added and automatically or manually approved, it's forwarded to the ERP system to trigger payment.
Here, we can see the APEX development screen used to configure workflows with an example of a typical workflow used for requesting new laptops. There are approval steps, decision trees, timers, and notifications.
This highlights a big reason to deploy your own solution - workflow sovereignty. The main reason automating invoice processing is difficult is because every invoice is different. There is no single format that can be assumed when building an application to scrape invoice data.
The same problem exists when you consider the end-to-end workflow. Every business is different, and there is no single workflow that can be assumed when building an application to encapsulate the process your business requires. This and the cost are big reasons to avoid off-the-shelf SaaS products.
Some things are easy to manage using off-the-shelf workflows, like:
Things that are hard or not possible to manage:
Some of these problems have been solved in some ERP solutions, but migrating to an entirely new ERP is a huge expense and a risky and time-consuming venture. Deploying your own invoice processing application using the technologies mentioned is the most tactical option and considerably cheaper.
You get:
You can also ensure no overlap with other applications or workflows, which means no duplication of effort. Check out our recent blog covering APEX Workflows in more detail.
For our solution, we have red/amber/green workflows, which represent "Zero touch", "Light touch", and "Send it back" processes.
For our green route workflow, we are checking that all validation rules have passed, our ERP has already received a purchase order and was expecting the invoice, and that the value is within the threshold defined. Once these checks have passed, the invoice and data can be forwarded to the ERP to trigger payment.
For our amber route workflow, we are recording any manual changes made to the invoice data before approval or rejection.
This confirmed data could be directly incorporated into model training (when using custom models), which would improve the accuracy of custom models going forward. This is useful when encountering invoices from new suppliers with atypical invoice formats.
There's also the possibility of using Oracle machine learning algorithms to gain valuable insights. Maybe a reoccurring invoice that usually has a flat value suddenly increases - we can flag it for additional approval. If the users select, this approval can be saved as the default response, ensuring the invoice is processed automatically again going forward, unless the value changes once more. Or, the expenditure for a particular supplier has increased dramatically for the quarter in a way that hasn't occurred in previous years, again this can be highlighted, this time for management to investigate.
Lastly, for our red route workflow, any invoices of unacceptable quality, those that weren't expected by the ERP and rejected manually, or outright failed to pass one of the validation rules are referred to the supplier with advice so they can try again.
This image shows an example of the APEX-developed screen a user sees when assessing and adding data to an invoice that is 'in-flight'. The user sees an image of the invoice on the left and a table of data on the right with all relevant information displayed. There is also an additional column on the end exposed for the purposes of this presentation called 'Confidence'.
Label confidence is a value between 0 and 1 (a percentage) given to each label to indicate how confident Document Understanding is that it has correctly assessed the data found.
For each invoice, the label confidence values are aggregated into different categories (maximums, medians, averages, and minimums), each category is split into percentiles, and we report on how many documents fall into each percentile for each category.
The maximum confidence value per document is useful to know as we can verify that there isn't a 'ceiling' to the accuracy of the AI model.
The median confidence value best represents the overall accuracy of the document as this tells us where the label confidence values cluster - without being unfairly weighted by the values at the extremes.
The average confidence value is useful to see when compared to the median, as it shows us the overall effect that low-label confidence values have.
The minimum confidence value is useful as it allows us to anticipate how many labels need highlighting to users for additional confirmation and/or need feeding back to suppliers to improve the quality of invoices.
Aggregate label confidence percentile (number of invoices).
We can see from the results that the median confidence score is at least 80% for all invoices, and 4/5ths of those invoices are in the 90% range.
Additionally, as we might expect, we can see that the lowest confidence score recorded was in the 20% range, but impressively, for half of all invoices, the minimum confidence was as high as 60%.
Fields like supplier names that aren't typically labelled are more susceptible to low confidence scores as they're inferred from their position and context relative to other data. However, this does not automatically translate to the data being incorrectly read. We have found that our samples are often correct despite a low confidence score.
Real outcomes for fields with low confidence will always be on a case-by-case basis for the format of the invoice being processed. But it's worth remembering that custom AI models can be trained over time to be more accurate against your specific invoices, and Oracle's pre-trained models will become more accurate over time as well.
Assessing the overall label confidence begs the question, what causes low label confidence in invoices?
This answer is essentially anything that either stops the overall shape of characters from being recognised or blends the boundary of characters. Think about typical text-based bot detection and CAPTCHAs. The same kind of obfuscation will degrade Document Understandings ability to read text, examples being:
Most of this is the delay sometimes experienced between an email being received and Microsoft sending our endpoint a notification. The quickest we've seen is a few seconds, and it's never been longer than a minute.
OCI allows us to enable 'Provisioned Concurrency' to quote "Reduce initial provisioning time and ensure hot starts." Having a certain number of function containers on standby allows us to keep on top of general traffic efficiently and absorb spikes in traffic more gracefully.
Thanks to this feature, if there are fewer than 40 concurrent requests, the serverless functions respond instantly. If there are over 40 concurrent requests, it takes roughly 10 seconds for a function container to start.
Document Understanding itself can be used synchronously or asynchronously. We're currently using it synchronously, as the Function does a few other things before and after calling the API. But we're investigating moving to using it asynchronously to minimise Function duration. Currently, the API can take between 5 and 20 seconds for invoices between 1 and 50 pages.
Looping through the resulting JSON data using Oracle Databases - JSON Data Structures is incredibly fast and usually takes less than a second.
There are a few limitations to highlight, to show that the implementation discussed can scale extremely well.
The Microsoft Graph endpoint is rate-limited to 10,000 (Outlook) requests over 10 minutes. Up to 20 of these requests can be batched into a single API transaction, and there can be 4 concurrent transactions at any one time.
The Oracle Document Understanding API can process 300 asynchronous requests over 1 minute.
Oracle Functions are limited by memory allocation, and for our function we use the minimum (128MB). Given the maximum available memory per Availability Domain is 60GB, we can theoretically scale to running 480 instances of function concurrently.
That depends on how complex your application workflow requirements are. Nought to a skeleton application (invoice image and data review) can take as little as a few weeks with DSP's help.
Once an application has been built to your requirements and tested, we recommend switching suppliers over one at a time as they send new invoices through the channels they already use.
How long this takes depends on how many suppliers you have and the volume of invoices received. Starting with smaller suppliers and working up to larger suppliers is prudent.
It's safe to scale as quickly as you like. When transitioning one supplier at a time, it is trivial to revert to your old process if an issue occurs for any or all suppliers.
The service limitation you are likely to encounter first is the maximum of 300 asynchronous Document Understanding requests per minute.
That works out at 5 invoices a second, 18,000 an hour or just under 160 million a year.
If that sounds excessive, I can report we are engaged now with a potential customer who processes 10s of millions of invoices a year, which illustrates how critical this often-hidden process can be to some industries.
Based on experience, the cost per page using a solution like the one discussed can be as little as 10% of what you're paying now.
Fundamentally, the Document Understand cost is £8 per 1000 pages, so assuming 500,000 pages a month, that's £4,000 (excl. VAT).
In part 1, we discussed the pain of invoice processing for many businesses today and highlighted previous attempts at moving the situation forward and where those solutions were lacking, before bringing some of Oracle's latest services into the picture to review how they work together to build out a viable long-term solution.
In this blog, we brought Oracle APEX into the mix and reviewed how the solution looks and works from the perspective of users, the strategic enhancements this approach can bring to businesses, and the numbers and practicalities of the approach.
For more information, check out our Oracle APEX Services, and if you liked this blog, check out our other APEX blogs here.
Subscribe to Oracle APEX Insights if you want to stay tuned for more APEX updates.