Invoice automation solutions are nothing new, but the change in model from on-premise to SaaS-based ERP solutions has led to organisations trying to build a solution into the ERP system.

One such solution is Oracle’s IDR (Intelligent Document Recognition), which is provided as part of ERP Cloud. Does this out-of-the-box solution meet your needs or are you coming across issues because your business processes are simply different?

For example, do you need to have multiple mailboxes to receive your invoices to segregate them based on the country they relate to?

Do you want the system to recognise supplier addresses to identify the supplier or assume the PO number read is correct, which then automatically applies the supplier and the Business Unit?

 Email Address or Addresses?

With Invoice automation, we’ve all been there, customers frequently have dozens of legal entities that are spread across the globe and each of them is used to having a mailbox for their own region. Additionally, they like using their own companies mailbox. With IDR, the approach is that the email address is singular and handles all regions/countries and is an Oracle mailbox.

There are ways around this, you can set up your own mailboxes and forward the email to the central account, but the monitoring of the mailbox disappears. You no longer have the option of separate mailboxes, one for enquiries and another for invoices or a single mailbox for both, the choice is made for you, they have to be separate. These aren’t bad choices, they’re just ones enforced on you that may not suit your business process.

Reading the address of the invoice or just using the PO?

Invoice processing has certain elements that follow legal requirements, especially in the UK in terms of an invoice document being VAT compliant. Two of these requirements are:

Suppliers company name, address and contact information

Company name and address of the customer you are invoicing

All invoices commonly contain this information, however, what if the information is wrong? Does your current solution pick up on this?

IDR doesn’t process a PO invoice by reading the address, it assumes that the PO number identified on the invoice is correct and processes it through without an issue. The danger of this is that at no point has it flagged a user to say the invoice has an incorrect address, the invoice will hopefully have other issues to prevent it from payment but supplier recognition is no longer based on invoice address data, it’s based on a purchase order number.

This issue isn’t a new one and is not specific to IDR, it also relates to EDI solutions as well. Commonly the data transformation applied to records will flip PO data to enable the invoice to be generated. The hope is that the EDI solution is using some of the data provided in the record submission to check the VAT registration number and/or the address data to ensure they match your master data.

Should you consider alternatives?

 Do what suits your business process, organisations are guilty of thinking that something that forms part of a larger component or solution is the right approach to use. When it comes to Tax engines, organisations commonly use alternative solutions or when it comes to reporting there are again 3^rd party solutions that might have functionality that meet your requirements better.

Why is invoice processing any different, the simple answer it isn’t.  

Any organisation that approaches 3^rd Parties does so knowing that they are experts in their respective areas. Oracle produces a great ERP, but does the Invoice Automation feature meet your business needs?  See the Oracle Cloud Marketplace for a range of  alternative products providing enhancements

For more information on Automated Invoice Processing of supplier invoices with Oracle ERP Cloud (Fusion)