What is SAP Invoice Verification?

Excerpt from Invoice Verification for SAP® by Stephen Birchall.

What is Invoice Verification?
Most organizations that struggle with poor implementations of SAP Invoice Verification misunderstand the basic process involved. Invoice Verification is simply a function that allows you to capture the details of vendor invoices. If you start from this admittedly simplified viewpoint, the basic design will more likely be robust and you will be more likely to have a process that works as it should.
Having said that, it is merely a method of capturing the details from the vendor’s invoice, it’s clear that the function does a lot more than this, but you can deal with the remainder of the design once you have established the basic principle. For instance, if the details of the invoice that was captured in this way match the expected details specified by any related purchase order (PO) and goods receipt (GR), the invoice can be made available automatically for payment. Unmatched invoices are excluded from the payment run and need to be investigated and released before payments can be made. If you make this basic process overly complex or inefficient (by straying too far from the basic SAP functionality), payments made to vendors will be late. Possible consequences of this include a loss of cash discounts, having purchase orders rejected by the vendor, and even losing the vendor account.

It is essential, therefore, to understand the basic process of invoice verification before you design or modify it. It is equally important to have confidence in the SAP standard
functionality, even though it may appear to be very different from your current processes. The standard process provided by SAP is suitable for most businesses,
though this may not appear to be the case at first glance. The standard process has many configuration options and is normally more than flexible enough to cater to the
needs of an invoice verification department, be that a global “shared service center” or a local accounts payable department.

Because you are most likely to succeed if you adopt the standard SAP process, rather than trying to alter the SAP process to fit your current functionality, we will start
with a high-level view of the process.

1.1 High-Level Process
The main aim of any invoice verification process is to ensure that vendors are paid the correct amount at the right time (not too late but also not too early). The process
should have a high incidence of first-time matching to ensure that as little time as possible is spent trying to manually match invoices that appear to be incorrect. It is
important to include as few steps as possible in the process, considering that the process of handling payments does not in itself add value to the company.
1.1.1 The Main Steps
The main steps included in the process are:

• Capture of the vendor’s invoice details
• Matching of those details to the details that we believe to be correct
• Investigation and management of any mismatches
• Release for payment of validated invoices
• Accounting entries (including taxes and delivery costs)
• Details recorded for audit purposes

Keep reading in Invoice Verification for SAP® by Stephen Birchall.

Invoice verification in SAP is an often misunderstood subject, despite its central role in contributing to a company’s fiscal health. Adding to the confusion is the fact that it falls between two teams the MM team and the FI team and each assumes that the other is responsible for the design and configuration of Invoice Verification. Although the process can be streamlined, many organizations get the design and use of invoice verification wrong, resulting in vendors not being paid and accounts being placed on stop, which prevents further Purchase Orders from being processed until the vendor has been paid.

The aim of this book is to help readers fully understand the invoice verification process, particularly the changes in ERP 6.0. If they get the design right, then the process will run smoothly and vendors will be paid on time (not too early either). User input can be kept to a minimum and much of the process can be automatic. There are one or two basic mistakes that are made during the design of the process and the guide highlights these (and many other confusing areas), and describes, in simple terms, the options available along with the consequences of getting it wrong.