I recently returned from a trip to a customer in an amazing Eastern European city where a major US corporation runs financial shared service operations for their entire EMEA and NA businesses. They have completely moved away from paper based Accounts Payable transaction processing to electronic about five years ago. Their main back-end system is SAP ERP and for AP automation and optimization, Process Tracking System for Accounts Payable suite (a partner ABAP and J2EE Add-on) is used in conjunction with OCR. They process around a million invoices on this system every year and given the scale of operations, are constantly finding ways to improve the overall process efficiency.
The company already employs OCR to automate the extraction of data from the invoices that are not electronic. All OCR engines require some level of “validation” where a human is required to verify and potentially correct a field that does not pass the confidence level threshold. This is still a substantial improvement over completely manual data entry as the overall number of keystrokes is reduced. The leadership of this shared service operation, however, wanted to strike an optimal balance between the amount of OCR validations and potential keystrokes later in the process. With this in mind, they originally decided to go with header only OCR because they felt the increase in % of invoices requiring validation or teaching due to line data extraction and very complex line structures was not worth the investment. They also did not believe in a template based approach where validation rates and OCR accuracy is increased by teaching or training vendor invoice formats. To them, and I agree, this replaces a lower cost data entry operator with higher cost IT resource who now needs to constantly babysit the software and keep up with vendor invoice format changes.
When compared to a full line data OCR setup, this header only OCR approach did have a major drawback: invoices that do not need approval or exception handling (typically PO based invoices with open GRs or 2-way invoices with enough open value and low invoice amount that does not require approvals), still need to be touched a second time in SAP. Despite SAP’s MIRO transaction being very efficient with line matching, someone needs to open the transaction, accept proposed lines (with other data prepopulated from OCR) and finish posting – a fairly mechanical process. When they compared their process with peers who have deployed line level OCR, these types of invoices were getting auto-posted. Over the last five years, OCR technology has improved substantially and with some best in breed engines the need for validation has been reduced. This analysis meant that they could invest in a line level OCR project and take the operational efficiency to the next level. Given the complex structure of the invoices, the leadership was not convinced though that the cost of investment would yield the desired ROI and wanted to explore other options.
A full electronic invoice receipt (EDI, or eInvoicing) would eliminate the need for OCR and potentially provide the desired automation levels. Although procurement had begun an electronic invoicing initiative, converting the majority of invoice volume to full electronic was still a distant dream. Also, they did not want to wait for adoption to reach such a critical mass. At that point, shared service leadership and the Dolphin team took a step back and reanalyzed the makeup of current invoices. It took some outside the box thinking but the group realized that there is another way where they could potentially auto-post a large variety of PO based invoices by comparing the invoice header amounts to the value of total open GRs or value of the 2-way PO lines when the calculated tax amount is backed out. For non-PO invoices, there is a facility in PTS-AP to auto-code certain invoices based on patterns like vendor# and plant. I will spare the gory details, but Dolphin quickly configured its invoice ingestion gateway to “synthesize” the invoice line data based on this logic and voila –suddenly substantial number of invoices were auto-posting with absolutely no change on OCR front!
We recently expanded this process to multi-line POs while at the same time integrated the volumes of three newly acquired companies at this shared service operation. The results so far are very promising and if not for this outside the box thinking, shared service would need to add substantial new FTEs to cater to the increased volumes.