MM-IV-LIV-CRE Set Tolerances for Incoming Invoice

Tolerance checks in MM-IV

1. Vendor-specific tolerance checks:

In this step, you define tolerance groups for each company code. You can assign these tolerance groups to each vendor in the vendor master record.
You can define the following tolerances:

Total-based acceptance
If the difference is within the tolerance range, the system automatically generates a difference line on a neutral income/expense account for small differences for invoices with debit/credit differences when posting the invoice.

Total-based invoice reduction
If the difference is within the tolerance range, the system posts the difference to a clearing account and generates a credit memo in a second document to clear this.

The system uses the following logic:
1. The system determines the difference between the net invoice amount (= gross invoice amount less taxes and unplanned delivery costs) and the net total of the items.
If the net invoice amount is the greater, the difference is positive; if the net invoice amount is the smaller, the difference is negative.

2. Negative differences:
a) If the negative difference is smaller than the absolute negative small difference limit defined, the system generates a posting to a small differences account for this difference.
b) If the negative difference is greater than the absolute small difference limit defined, the system checks if the absolute difference is smaller than the lower of the absolute and percentage lower  limits.
If this is the case, the system creates a posting to a small differences account.
If this is not the case, the system cannot post the invoice.

3. Positive differences:
a) If the positive difference is smaller than the positive small difference limit defined, the system generates a posting to a small differences account for this difference.

b) If the positive difference is greater than the positive small difference limit defined and the Check limit field is not selected for total-based invoice reduction, the system checks whether the positive difference is smaller than the lower of the absolute and percentage upper limits.
If this is the case, the system creates a posting to a small differences account.
If this is not the case, the system cannot post the invoice.

c) If the positive difference is greater than the positive small difference limit defined and the Check limit field is selected for total-based invoice reduction, the system checks if the difference is smaller than the lower of the absolute and percentage upper limits for total-based invoice reduction.
If this is the case, the system generates a posting to a clearing account for invoice reduction and creates a credit memo document.
If this is not the case, the system cannot post the invoice.

The system does not try to reduce the invoice based on the total in the following cases:
  - If you manually reduced an invoice item
  - If you manually accepted a difference in the document header
  - If you entered a credit memo

In these cases, the system checks directly whether it can accept the positive difference.

Further notes
If the system can create a small difference, it posts this difference to the account specified in account determination for transaction DIF.

If no tolerance group is assigned to a vendor or if no tolerances have been specified for the assigned tolerance group, the system creates a difference line if the difference is smaller than the tolerance defined for tolerance key BD.

2. General tolerance limits

In this step, you specify the tolerance limits for each tolerance key for each company code.
When processing an invoice, the R/3 System checks each item for variances between the invoice and the purchase order or goods receipt. The different types of variances are defined in tolerance keys.

The system uses the following tolerance keys to check for variances:

AN: Amount for item without order reference
If you activate the item amount check, the system checks every line item in an invoice with no order reference against the absolute upper limit defined.
-> for G/L account postings too

AP: Amount for item with order reference
If you activate the item amount check, the system checks specific line items in an invoice with order reference against the absolute upper limit defined. Which invoice items are checked depends on how you configure the item amount check.

BD: Form small differences automatically
The system checks the balance of the invoice against the absolute upper limit defined. If the upper limit is not exceeded, the system automatically creates a posting line called Expense/Income from Small Differences, making the balance zero and allowing the system to post the document.

BR: Percentage OPUn variance (IR before GR)
The system calculates the percentage variance between the following ratios: quantity invoiced in order price quantity units : quantity invoiced in order units and quantity ordered in order price quantity units : quantity ordered in order units. The system compares the variance with the upper and lower percentage tolerance limits.

Example:
PO         100 KG (order unit)   ->     1 PC (order price unit)
Invoice    80 KG                     ->     1 PC

1PC / 80 KG               1 PC / 100 KG (base)
80%                          100 %

   -> this means 20% variance

• BW: Percentage OPUn variance (GR before IR)
  The system calculates the percentage variance between the following ratios: quantity invoiced in order price quantity units: quantity invoiced in order units and goods receipt quantity in order price quantity units : goods receipt quantity in order units. The system compares the variance with the upper and lower percentage limits defined.
• DQ: Exceed amount: quantity variance
  If a goods receipt has been defined for an order item and a goods receipt has already been posted, the system multiplies the net order price by (quantity invoiced - (total quantity delivered - total quantity invoiced)).
  If no goods receipt has been defined, the system multiplies the net order price by (quantity invoiced - (quantity ordered - total quantity invoiced)).
  The system compares the outcome with the absolute upper and lower limits defined.
  This allows relatively high quantity variances for invoice items for small amounts, but only small quantity variances for invoice items for larger amounts.
  You can also configure percentage limits for the quantity variance check. In this case, the system calculates the percentage variance from the expected quantity, irrespective of the order price, and compares the outcome with the percentage limits configured.
  The system also carries out a quantity variance check for planned delivery costs.
• DW: Quantity variance when GR quantity = zero
  If a goods receipt is defined for an order item but none has as yet been posted, the system multiplies the net order price by (quantity invoiced + total quantity invoiced so far).
  The system then compares the outcome with the absolute upper tolerance limit defined.
  If you have not maintained tolerance key DW for your company code, the system blocks an invoice for which no goods receipt has been posted yet. If you want to prevent this block, then set the tolerance limits for your company code for tolerance key DW to Do not check.
• KW: Variance from condition value
  The system calculates the amount by which each delivery costs item varies from the product of quantity invoiced * planned delivery costs/ planned quantity. It compares the variance with the upper and lower limits defined (absolute limits and percentage limits).
• LA: Amount of blanket purchase order
  The system calculates the sum of the value invoiced so far for the order item and the value of the current invoice and compares it with the value limit of the purchase order. It then compares the difference with the upper percentage and absolute tolerances defined.
• LD: Blanket purchase order time limit exceeded
  The system determines the number of days by which the invoice is outside the planned time interval. If the posting date of the invoice is before the validity period, the system calculates the number of days between the posting date and the start of the validity period. If the posting date of the invoice is after the validity period, the system calculates the number of days between the posting date and the end of the validity period. The system compares the number of days with the with the absolute upper limit defined.
• PP: Price variance
  The system determines by how much each invoice item varies from the product of quantity invoiced * order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).
  When posting a subsequent debit/credit, the system first checks if a price check has been defined for subsequent debits/credits. If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product of the quantity to be debited/credited * order price and compares this with the upper and lower tolerance limits (absolute limits and percentage limits).
• PS: Price variance: estimated price
  If the price in an order item is marked as an estimated price, for this item, the system calculates the difference between the invoice value and the product of quantity invoiced * order price and compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).
  When posting a subsequent debit/credit, the system first checks whether a price check has been defined for subsequent debits/credits, If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product quantity to be debited/credited * order price. It then compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).
• ST: Date variance (value x days)
  The system calculates for each item the product of amount * (scheduled delivery date - date invoice entered) and compares this product with the absolute upper limit defined. This allows relatively high schedule variances for invoice items for small amounts, but only small schedule variances for invoice items for large amounts.
• VP: Moving average price variance
  When a stock posting line is created as a result of an invoice item, the system calculates the new moving average price that results from the posting. It compares the percentage variance of the new moving average price to the old price using the percentage tolerance limits defined.

Variances are allowed within predefined tolerance limits. If a variance exceeds a tolerance limit, however, the system issues a message informing the user. If an upper limit (except with BD and VP) is exceeded, the invoice is blocked for payment when you post it. You must then release the invoice in a separate step. If the tolerance limit for BD is breached, the system cannot post the invoice.

Note that if you set all limits for a tolerance key to Do not check, the system does not check that tolerance limit. Therefore any variance would be accepted. This does not make sense particularly in the case of the tolerance key Form small differences automatically.

3. Item amount check:

In this step, you determine whether the system blocks invoice items when their value exceeds a certain amount.
You set the limit above which items are blocked as the "absolute upper limit" for the following tolerance limits:
AN for invoice items without order reference
AP for invoices with order reference

This depends on two criteria:
    Item category
    Goods receipt indicator
The system checks the amount for all possible combinations of item category and goods receipt indicator in all the company codes in which the check is active.

4. Stochastic block

A stochastic block is not set at item level, but for the whole invoice. If a stochastic block is set when you post the invoice, the system automatically sets an R in the field Payment block in the document header data; there is no blocking indicator in the individual items.
Invoices with stochastic blocks can only be released manually.

5. Invoice blocks:

Function modules:
MRM_AMOUNT_CHECK
==> CALL FUNCTION 'MRM_TOLERANCE_CHECK'

MRM_QUANTITY_CHECK
==> CALL FUNCTION 'MRM_TOLERANCE_CHECK'

Structure I_MRM_AMCK is filled from PO

MRBR

Important tables:
RBKP
RBKP_BLOCKED -> this is read by MRBR
RSEG
BSEG

Important fields:
RBKP-ZLSPR: only filled in case of manual or stochastic block!
RBKP_BLOCKED-MRM_ZLSPR: A, S, M, W
RSEG- SPGRP  
SPGRM  
SPGRT  
SPGRG  
SPGRV  
SPGRQ  
SPGRS  
SPGRC  
BSEG-ZLSPR (vendor item)

Invoice block = > Payment block
Payment block <> Invoice block

In the case of quantity, price, and schedule variances and when an invoice is blocked due to quality inspection, the invoice may still be blocked although the blocking reason is no longer valid, so you have to release them with MRBR.

You can have the system automatically release invoices in the background. You use program RM08RELEASE for this. Let your system administrator know which variants should be created for the program and which jobs have to be defined.

You can only process blocked invoices that were posted in conventional Invoice Verification (MR01) using the invoice release transaction in conventional Invoice Verification (MR02).
You can process blocked invoices that were posted before Release 4.6A in Logistics Invoice Verification using the invoice release transaction in conventional Invoice Verification (MR02) or you can use report RM08RBKPBLOCKED to convert them and process them using the invoice release transaction in Logistics Invoice Verification (MRBR).

When invoice doesn't appear in MRBR -> note 394466 MRBR: Blocked invoice not displayed 
Error message M8?657: authorization problem (field EKGRP)
FAQ: 394370

Other important notes:
209424  Workflow release for payment not in MR1M / MIRO
685688  Release of "old" invoices as of SAP R/3 Enterprise
331033  MRBR/MR02: Signs for diffrnce values and quantities
333930  MR3M/MIR4: Display of payment block
684447  MIR4: No payment block in document display  

Appendix:

FI - tolerance limits for users,
Customizing:
(Financial Accounting->Financial Accounting Global Settings->Document->Line Item->)

    1. step: Assign User/Tolerance Groups
    2. step: Define Tolerance Groups for Employees, an example:
       Amount per document                           500.000,00        
       Amount per open item account item        100.000,90        
       Cash discount per line item                          10,000 %      
                      Amount      Percent   Cash discnt adj.to         
   Revenue       511,29      10,0 %        10,00                  
   Expense       511,29      10,0 %        10,00