Best Practice for Dealing with Invoice Lines

by Matt Dartford

When processing vendor invoices in SAP we must capture information at header level and item level. The header data applies to the whole document and includes organisational information, total amounts and reference. The item data relate to specific order lines and will specify the price and quantity being invoiced. In a simple SAP scenario the AP clerk may manually input certain key header fields in MIRO. For the items they will most likely input the PO number (or possibly Delivery Note or some other reference) and then allow SAP to propose the invoice items. This would prepopulate the required fields – including quantity and amount – based on what has been ordered and/or received.

The benefit of the MIRO proposal is clear – it reduces the effort required for the AP clerk to input the invoice into SAP. Given that this scenario involves manual input you would expect the user to notice any discrepancy between the proposed line items and the items as invoiced. In addition, the line amounts must total the (manually input) header amount in order to post, so incorrect quantities or prices would likely be spotted.

When processing invoices in a SAP Invoice Management (aka VIM) and OCR scenario we have some options when deciding how to deal with invoice lines. The item data is taken from the invoice – maybe by OCR extraction or from an IDoc interface – therefore there is no need to propose data from MIRO. You may therefore decide to set up VIM so that the OCR line data is used as the basis for invoicing. This seems to be the ‘correct’ approach because ultimately the invoice as provided by your vendor is what should be input and processed.

But is this the ‘best’ approach?

If your vendors always send invoices with lines that clearly and unambiguously match the Purchase Order lines then maybe so. But unfortunately – to a greater or lesser extent – that is not the case. Very often the presentation of invoice lines may not mirror exactly the Purchase Order. Item descriptions may not match and the invoice or PO may be either summarised or listed to a greater degree of granularity. As a result the system will be unable to automate the line matching which means that some manual intervention is required.

In order to minimise the workload for AP and the business you may therefore wish to ignore the OCR lines completely. In this scenario as well you may wish to rely on the MIRO proposal – the system can be setup to automatically populate the items based on this. Assuming the totals tally with the header information then the invoice will post, even though the item data as printed on the vendor invoice may present differently.

When trying to define ‘best practice’ the recommendation would be to use the solution as a means to drive compliance and streamline the workflows for identifying and resolving any and all discrepancies. Where difficulties arise in matching invoice lines to PO lines then very likely this indicates either an issue with the invoicing processes of the supplier, or an issue with your own procurement process and the way in which orders are raised. In both cases the correct course of action should be to improve those processes – rather than seek a technical ‘workaround’.

Despite this there are instances where best practice may not be the most appropriate approach. Depending on the priorities of your organisation you may see a VIM/OCR solution as tool to automate your AP processes as much as possible and in doing so introduce additional efficiencies to your Finance processes. In which case a rigorous observance of item data as invoiced by the vendor may not be worth the effort. When designing a solution this can be taken into account – though with a preference for adopting best practice even where it may not initially be the ‘path of least resistance’! ES2P has worked on a number of VIM projects where we’ve implemented appropriate, fit-for-purpose solutions for invoice processing. Why not drop us a line if you want to find out more.