Invoice Verification for SAP

2.3 Tolerances

There are many tolerances that relate to invoice verification available, and you don’t have to configure them all. Some of them may not be relevant for your implementation. It is important to understand that you have to think of these tolerances as controlling whether an invoice should be blocked. They are not used to determine if an invoice can be posted (saved).

2.3.1 Why Have Tolerances?

What is the point of tolerances? While it is true that you would not want vendors to be overpaid, you should consider the true cost of investigating small differences.

Let’s use an example. A vendor has invoiced you for a total of € 10,000 for a purchase order including 100 items at a price of € 99.90 for each item. This has resulted in a difference of € 10. If you calculate the true cost of passing this invoice to the buyer for investigation, and the buyer contacting the vendor, then changing the purchase order to reflect the correct price, and the invoice verification clerk then re-matching the invoice, it certainly will come to far more than € 10.

It is for your company to decide if this true cost is justified, and this decision may well be influenced by the general standard of vendors that you use. It may be acceptable that your vendors take advantage of this tolerance, or it may be that the sheer frequency of such small differences makes it unacceptable.

That is exactly what the tolerances are there for: They enable the implementation team to work with the financial department to decide what, if any, differences will be allowed.

2.3.2 What Kind of Tolerances are There?

It is also important to realize that the tolerances in invoice verification relate to more than prices or values. There are tolerances that relate to dates, and one such tolerance is linked to the delivery date. This is very useful when a vendor has sent an invoice too early, something often done deliberately.

The delivery-date tolerance can be used to check the invoice date against the requested delivery date. A vendor will sometimes send the goods and invoice early, and without this tolerance the invoice would normally be paid because the invoice quantity would match the goods-received quantity. This special tolerance however, would check the invoice date and delivery date and block the invoice for payment because of the early invoice.

Early invoices cost your company in two different ways:

• You lose cash-flow due to early payment.
• You have to pay to store the goods until the date you actually need them.

2.3.3 Special Tolerances

Certain tolerances don’t seem important at first but in fact are extremely useful. One example is the Moving Average variance tolerance. If you do not use moving average prices (MAP) in your implementation, then this tolerance is not required. Section 3.6 gives more information on moving average prices.

As explained earlier, when an invoice is posted with a variance in value, the financial postings still occur but the invoice is blocked for payment. This can cause major problems if you are using MAP, because the incorrect invoice price will affect the MAP even though the invoice did not match and was blocked.

For instance, suppose you have a material that has a MAP of € 100 per item, and you post an invoice with a per-item value of € 1,000 for this material, perhaps because of a keying error by the vendor or invoice verification clerk. In this case, the MAP will be increased significantly even though the invoice will be blocked for payment.

That is why SAP has provided this tolerance. You can set it (normally with a reasonably large tolerance) so that when an invoice is posted for an item a warning message is displayed indicating that posting this invoice will cause a significant change in the MAP.

This can prevent future problems if the item is consumed at the potentially artificial cost. Remember that if the invoice is subsequently corrected, this will not correct the values used in any postings that occurred between the initial invoice posting and the correction.

2.3.4 Other Tolerances

Another useful tolerance is related to those invoices that contain lines that do not relate directly to a purchase order. These cannot be three-way matched, and so SAP provides a tolerance that can be set to block an invoice line that does not relate to a purchase order if it exceeds a certain value. Another user can then check this blocked invoice line to ensure that the invoice is valid.

One special tolerance that must be used correctly is the one called Form small differences automatically. It is vital that this is used only to allow extremely small differences, such as rounding errors otherwise it will allow invoices to be paid even though they do not match.

It is quite normal for this tolerance to be set to a value as small as € 1, which is a typical variance caused by tax postings such as value-added transaction (VAT). This tolerance is also unique because it does not affect whether the invoice is blocked.

It influences the mathematical check carried out to ensure that all invoice lines and taxes add up to the total invoice value that has been entered. We have seen this tolerance set to very high values by mistake, and this has always resulted in many problems throughout the invoice process.

2.3.5 Configuring the Tolerances

Configuration of the tolerances is covered in Section 4.4 in detail, but there are some tips that can help get you started.

First, you must ensure that you have all of the required tolerances set up for your company code or codes. We find that the easiest way to do this is to copy the standard tolerances that SAP has configured for the company code 0001. This way, you will at least have the minimum set of tolerances, and all that you will have to do is to change the values of the tolerances to suit your requirements. Some transactions will expect certain tolerance keys to exist for the company code being used and will report errors if they do not exist. By using the 0001 tolerances, you can avoid this problem.

For the development client, we normally copy the following tolerance keys from company code 0001, unchanged, as shown in Figure 2.13. This will at least allow you to use the system before you configure the final tolerance settings.

Figure 2.13: Basic Set of Tolerances Used as a Starting Point

Each tolerance key is described in Section 4.4.

2.3.6 Error Messages Resulting from Tolerances

To ensure that you have the correct error-message settings for each tolerance, you can set the message to an E or a W. Messages set to E are treated as errors and will not allow the process to continue. Messages set to W are treated as warnings and can be ignored to allow the process to continue.

You can also configure different error message settings for each user or group of users, so that one user gets an E message and another gets a W message.

Figures showing the settings and full details are contained in Section 4.2. As an example of how this can be used, you may wish to prevent certain tolerances from being allowed unless they have been authorized. To achieve this, you need to set the error message to an E for non-supervisory users but set the message to a W for a supervisor.

When users get the E message preventing the invoice from being processed, they must ask a supervisor to post the invoice. The supervisor will just get a warning message, but will be allowed to continue.

Note that some error messages are controlled from within the program or transaction. Even though you can change them in configuration, this will not always be used by the program and so the configuration is superseded by the program code.