SAP Career Guide - A beginner’s manual on SAP careers for students and professionals

The book was very clear and exactly what I needed. I have read other work by Espresso Tutorials and have always found it excellent

L. Lachner

Invoice Verification for SAP

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...



  • Preface
  • 1 What is Invoice Verification?
  • 1.1.1The Main Steps
  • 1.1.2Capturing the Invoice Details
  • 1.1.3The Use of Invoice Verification
  • 1.1.4 Processing Mismatched Invoices
  • 1.2.1 Mismatches During Input (MIRO)
  • 1.3.1 Using Workflow when Mismatches Occur
  • 1.3.2 Using MRBR
  • 1.3.3 Automatic invoice release
  • 2 Specific Functions in Detail
  • 2.1.1 What Does the GR-Based IV Flag Do?
  • 2.1.2 The Risks of Setting the Flag Off
  • 2.1.3 The Risks of Setting the Flag On
  • 2.1.4 On Vs. Off
  • 2.1.5 How the Flag Works
  • 2.1.6 Entering an Invoice for a Purchase Order with the Flag Set On
  • 2.1.7 Entering an Invoice for a Purchase Order that has the Flag Set Off
  • 2.1.8 Where is the Flag Set?
  • 2.2.1 Difference Between Planned and Unplanned Delivery Charges
  • 2.2.2 A Third Option
  • 2.2.3 Planned Delivery Charges
  • 2.2.4 Posting Planned Delivery Charges in Invoice Verification
  • 2.2.5 Unplanned Delivery Charges
  • 2.2.6 A Third Option
  • 2.3.1 Why Have Tolerances?
  • 2.3.2 What Kind of Tolerances are There?
  • 2.3.3 Special Tolerances
  • 2.3.4 Other Tolerances
  • 2.3.5 Configuring the Tolerances
  • 2.3.6 Error Messages Resulting from Tolerances
  • 2.4.1 How Does ERS Work?
  • 2.4.2 How Safe is the Process?
  • 2.4.3 ERS for Inter- or Intra-Company Scenarios
  • 2.4.4 The ERS Process
  • 2.4.5 The ERS Settlement Transaction
  • 2.5.1 What Does Invoice Reduction Do?
  • 2.5.2 The Invoice-Reduction Process
  • 2.5.3 The Financial Posting of the Difference
  • 2.6.1 Consignment Stock
  • 2.6.2 Pipeline Stock
  • 2.7.1 Periodic Invoicing Plans
  • 2.7.2 Partial Invoicing Plans
  • 2.7.3 How Does the Process Work?
  • 2.7.4 Invoice Verification Relating to Invoicing Plans
  • 2.7.5 Basic Configuration for Invoicing Plans
  • 2.8.1 Posting a Subsequent Credit
  • 2.8.2 Posting a Subsequent Debit
  • 2.8.3 Posting a Normal Credit
  • 2.9.1 The Basic Process
  • 2.9.2 An Example of How to Use this Function
  • 2.10.1 ERS for Delivery Charges
  • 2.10.2 Prepayment of Invoices
  • 2.10.3 Variance Types
  • 2.10.4 Assignment Test
  • 2.10.5 Other New Functions and Options now Available
  • 3 Financial Aspects of Invoice Verification
  • 3.3.1 Sample Scenarios of the Use of the GR/IR Clearing Account
  • 3.3.2 Using MR11 to Manage the GR/IR Clearing Account
  • 3.3.3 Regular Maintenance of the Clearing Account
  • 3.4.1 The Calculate Tax Flag
  • 3.4.2 The Tax Tab in the MIRO Transaction
  • 3.5.1 The Difference Between Standard Pricing and MAP
  • 3.5.2 Advantages of Each Option
  • 3.6.1 The Parameter Tab
  • 3.6.2 The Free Selection Tab
  • 3.6.3 The Additional Log tab
  • 3.6.4 The Printout/data medium tab
  • 3.6.5 Running F110
  • 3.6.6 The F110S Transaction
  • 4 Configuration
  • 4.2.1How to Configure System Messages
  • 4.4.1Account Assignment
  • 4.4.2Simulation
  • 4.4.3G/L Accounts Function
  • 4.5.1Number Assignment
  • 4.5.2Tax Treatment in Invoice Reduction
  • 4.5.3Maintain Default Values for Tax Codes
  • 4.5.4Configure Treatment of Exchange-Rate Differences
  • 4.5.5Configure Posting of Unplanned Delivery Costs
  • 4.5.6Edit PO Supplement Text in Invoice Verification
  • 4.5.7Define Mail to Purchasing When Price Variances Occur
  • 4.5.8Configure Vendor-Specific Tolerances
  • 4.5.9Maintain Bar-Code Entry
  • 4.5.10Activate Direct Posting to G/L Accounts and Material Account
  • 4.5.11Maintain Item-List Variants
  • 4.5.12Aggregation
  • 4.5.13Define Start Logo
  • 4.5.14Set Check for Duplicate Invoices
  • 4.5.15Nota Fiscal and Chain Liabilities
  • 4.5.16Prepayment (New to ERP 6)
  • 4.5.17Variance types (New to ERP 6)
  • 4.5.18Assignment Test (New to ERP 6)
  • 4.7.1Determine Payment Block
  • 4.7.2Set Tolerance Limits
  • 4.7.3Activate Workflow Template
  • 4.7.4Item Amount Check
  • 4.7.5Stochastic Blocks
  • 4.11.1Specify Automatic Settlement of Planned Delivery Costs (New to ERP 6)
  • 4.11.2ERS Invoice Numbering (New to ERP 6)
  • 4.17.1Changes to Existing User Exits and Includes in Latest Releases
  • AThe Author
  • BDisclaimer

Weitere Informationen


Stephen Birchall







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.


The same tolerance is used during goods-receiving to indicate significant changes to the MAP caused by a goods receipt at a value different from the current MAP, because of a different purchase order price.

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.

Invoice Verification

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.

Alle Inhalte. Mehr Informationen. Jetzt entdecken. - Ihre Lernplattform für SAP-Software

  • Zugriff auf alle Lerninhalte1
  • Regelmäßige Neuerscheinungen
  • Intelligenter Suchalgorithmus
  • Innovatives Leseerlebnis
  • Maßgeschneidere Lernpfade
  • Zertifikate & QA-Tests2

Sie haben bereits ein Konto?

1 Sie erhalten Zugriff auf alle Lerninhalte. Online-Trainings, Zertifikate sind NICHT Teil der Flatrate.

2 Weitere Informationen auf Anfrage.