In this blog I am going to share the invoice tolerance limits learning and understanding which would help to understand  invoice blocking techniques and provide a base to apply in real time situations depending on the client’s need.

This document will help consultant who is going to implement Open Text Vendor Invoice Management (VIM)


Please refer Part-2 for remaining tolerance keys

Introduction:

In the Procure to Pay(P2P) life cycle procurement part ends when Account Payable(AP) processor/Invoice clerk posts the vendor invoice in SAP using MIRO transaction which is also called Logistics Invoice Verification(LIV). It is tedious job for invoice clerk manually to verify each and every invoice line item is conforming to agreed price or quantity in PO. SAP provides systemic way of verifying this kind of discrepancies and block the invoice for payment using the 2 digit key called “Tolerance key”.

Lower & upper tolerance limits for all possible discrepancies can be maintained in tolerance key. I would try to explain all the invoice tolerance keys in this blog with possible examples.

There are 2 kinds of invoice matching in SAP which are controlled by tolerance keys.

  • 3 way match:

Invoice line item is checked against corresponding purchase order and good receipt documents item for price & quantity matching

/wp-content/uploads/2014/04/3way_436322.png

  • 2 way match:

Invoice is checked against only to PO price/qty if there is no goods receipt planned

/wp-content/uploads/2014/04/2way_436323.png


Let us understand the how the automatic block is working via tolerance keys. In SAP we have many tolerance keys, I am going to discuss only below keys in this part AN,AP,BD,BR,BW,DQ,DW.

Tolerance Limits:

    • SAP tolerance limits work only for MIRO transaction
    • Invoice posted in FB60 is not subject to tolerance keys limit check
    • Tax amount is not included during tolerance check
    • It is stored in table T169G

Invoice blocking ways:

In SAP vendor invoice can be blocked for payment by anyone of the following way.

  1. Automatic block:

Only if there is a discrepancy due to price or quantity or date variance in an invoice.
If the item amount is exceeded from the limit maintained in the tolerance key.

   2.Manual block:

Invoice processor could manually block an invoice either at item level or header level

   3.Blocking through payment term:

Invoice can be blocked always with a particular payment term even if there is no variance

   4.Stochastic blocking:

Random blocking of invoices without any variance

   5.Blocking at vendor master level:

Invoice can be blocked always for a particular vendor if specific blocking key is maintained at vendor master level

Blocking indicators:

       Blocking indicators are available both at header and item level of invoice document. System set this indicator in the document wherever and whenever it is appropriate.

Header level:

Table: RBKP_BLOCKED                      Field: MRM_ZLSPR

Possible values:

A

Automatically blocked due to existence of blocking reasons

S

Stochastically blocked

M

Manual payment block set in header – no blocking reasons

W

Automatically blocked due to entry via Web Invoice

Item level:

Table: RSEG                                                  Value = X

Fields:

SPGRP

Blocking reason price

SPGRM

Blocking reason quantity

SPGRT

Blocking reason date

SPGRG

Blocking reason OPQ

SPGRV

Blocking reason Project

SPGRQ

Manual blocking reason

SPGRS

Blocking reason amount

SPGRC

Blocking reason: Quality

 

1.AN – Amount for an item without order reference

Definition:

“System checks every line item in an invoice with no order reference against the absolute upper limit defined.”

Without order reference means direct posting to G/L or Material.

System behavior:

If only the invoice line item is greater than absolute upper limit the invoice would be blocked.

Let us understand with below example.

  AN.png

It updates RBKP table without a header Block – R. But updates table RBKP_BLOCKED with payment block – ‘A’.

No entries in RSEG table as it is directly posted to G/L or Material

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

AN

No blocking indicator update(ZLSPR)

A-     Auto block

No update

(item amount block)

Not possible

2.AP – Amount for an item with order reference

Definition:

“System checks every line item in an invoice with order reference against the absolute upper limit defined.”

Pre-requisite:

  • Item amount check must be activated at company code level – OMRH
  • Item amount check must allowed for item category and GR indicator – OMRI

System behavior:

Let us understand with below example

AP1.png

No blocking indicator at header table RBKP but RBKP_BLOCKED table has blocking indicator ‘A’.

Blocking indicator RSEG- SPGRS (Blocking reason item amount) is set at item level.

Item amount block must be released manually. There is no automatic release possible even if we perform any one of the following activities

  • Post subsequent credit
  • Adjust AP tolerance limit

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

AP

No blocking indicator update(ZLSPR)

A-Auto block

RSEG- SPGRS = X

(item amount block)

Not possible

3.BD – Form small differences automatically

Definition:

“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”

System behavior:

Let us understand with below example

Small difference within tolerance limit:

As per the PO reference the invoice amount is 1000 USD.

But vendor actual invoice copy has amount of 1002 USD.

AP invoice processor enters the invoice amount as per the vendor’s invoice copy which is 2 USD higher than PO price.

BD.png

Since small difference is within the tolerance limit, invoice would be posted without block. Small difference amount would be debited to small difference G/L account maintained for the transaction event key DIF in OBYC.

               Same rule is applied in the lower side as well

Small difference above the tolerance limit:

PO price: 1000 USD

Vendor invoice amount: 1003 USD

If the small difference above the tolerance limit then system would not allow to post the invoice with hard error “ Balance is not zero”. Still AP invoice processor could able to post invoice via menu bar option Edit -> Accept and Post provided if he/she has authorization object M_RECH_AKZ allowed.

BD1.png

If we post with above option then system would behave as below.

  • Invoice will be posted without block
  • Small difference G/L account (DIF) get posted
  • RBKP – MAKZN (net amount accepted manually) field will get updated with small diff. amount : 3.00

BD2.png

Tolerance Key

Tolerance

RBKP

RBKP_BLOCKED

RSEG

Auto release

BD

Within range

No blocking indicator update(ZLSPR)

No update

No blocking reason update

NA

BD

Above

No blocking indicator update(ZLSPR)

MAKZN field updated with diff. amount

No update

No blocking reason update

NA

                                                                                                                                                                                            

4.BR: Percentage OPUn variance (IR before GR)

Definition:

The system calculates the percentage variance using below formula and compares the variance with the upper and lower percentage tolerance limits.

BR.png

Pre-requisite to simulate this scenario:

  1. No GR based IV
  2. Variable order unit is activated at material level
  3. Maintain tolerance key DW with “Do not check” active

Tolerance:

BR1.png

Material master:

BR2.png

‘CRT’ is maintained as order unit

‘EA’ is maintained as order price unit in info record 1 EA = 100 USD

PO Details:

PO has been created with CRT as Order unit and EA as Order price unit

Po quantity: 2 CRT = 24 EA

BR3.png
Invoice details:

Invoice is simulated before GR as below

Scenario 1:

Order unit quantity – 2 CRT

Order price unit quantity – 22 EA and amount 2200 USD

Observation: There is no warning message on the variance.

Let us use the above formula to find the variance percentage.

BR4.png

Difference is 100 – 91.6 = 8.9 % which is within the BR tolerance limit 10% maintained

Scenario 2:

Order unit quantity – 2 CRT

Order price unit quantity – 21 EA and amount 2100 USD

BR5.png

Observation: There is a warning message as below.

BR6.png

Let us use the above formula to find the variance percentage.

BR7.png

Difference is 100 – 87.5 = 12.5 % which is more than the BR tolerance lower limit 10%. Hence we are seeing the above warning message which will block the invoice for payment.

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

BR

No blocking indicator update(ZLSPR)

A- Auto block

RSEG- SPGRS = X

(item amount block)

Not possible

5.BW: Percentage OPUn variance (GR before IR)

Definition:

“The system calculates the percentage variance using below formula and compares the variance with the upper and lower percentage tolerance limits.

BW.png

Let us understand with same master data

PO Details:

PO quantity in order unit – 2 CRT

Po quantity in order price unit – 24 EA

GR Details:

GR quantity in order unit – 2 CRT

GR quantity in order price unit – 22 EA

BW1.png

IR Details:

Scenario 1:

IR quantity in order unit – 2 CRT

IR quantity in order price unit – 20 EA

Observation: There is no warning message on the variance.

Variance % = (20/2) / (22/2) *100

                     = 90.9%

Difference is 100 – 90.9 = 9.1 % which is within the BR tolerance limit 10% maintained

Scenario 2:

IR quantity in order unit – 2 CRT

IR quantity in order price unit – 19 EA

Observation: There is a warning message as below

BR6.png 

Variance % = (19/2) / (22/2) *100

                     = 86.4%

Difference is 100 – 86.4 = 13.6 % which is more than the BR tolerance limit 10% and invoice posted with payment block.

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

BR

No blocking indicator update(ZLSPR)

A- Auto block

RSEG- SPGRS = X

(item amount block)

Not possible


6.DQ: Exceed amount: quantity variance

This tolerance key has both absolute and percentage limits.

Definition:

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

System behavior:

Absolute limits:

Let us see the system behavior if only absolute values are maintained and percentage limits are marked as “Do not check”.

Upper limit: 100.00                                                       Lower limit: 100.00

Test data :- (GR has been defined)

PO quantity = 100 EA

PO price      = 100 USD

GR quantity = 50 EA

      a) System behavior when invoice quantity is 51

Variance   = PO price x   (quantity invoiced – (total quantity delivered – total quantity invoiced))

                 = 100 * (51 – (50-0))

                 = 100 * (1)

                 = 100

Variance 100 is equal to upper limit 100 and there will not be any warning message.

   

      b) System behavior when invoice quantity is 52 

Variance = PO price x   (quantity invoiced – (total quantity delivered – total quantity invoiced))

                 = 100 * (52 – (50-0))

                 = 100 * (2)

                 = 200

Variance 200 is more than upper limit 100 and there will be a warning message as below.

DQ.png

      

When we post invoice with above variance it will get blocked for payment.

It updates tables as below

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

DQ

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRM = X

(Quantity block )

Yes

Automatic release possible if the blocking reason RSEG- SPGRM is deleted when we post GRN for the balance quantity or credit memo for the excess invoiced quantity.

Same rules apply on the lower side as well

Test data :- (GR has not been defined)

PO quantity = 100 EA

PO price      = 100 USD

GR not possible

     a)System behavior when invoice quantity is 51

     Variance = PO price x   (quantity invoiced – (total quantity ordered – total quantity invoiced))

                 = 100 * (51 – (50-0))

                 = 100 * (1)

                  = 100

     Variance 100 is equal to upper limit 100 and there will not be any warning message.

    

     b)System behavior when invoice quantity is 52

     Variance = PO price x   (quantity invoiced – (total quantity ordered – total quantity invoiced))

                 = 100 * (52 – (50-0))

                 = 100 * (2)

                 = 200

     Variance 200 is more than upper limit 100 and there will be a warning message as below. Invoice will be blocked for payment and same tables will be updated as above.

DQ1.png

Percentage limits:

“We 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.”

Let us see the system behavior with same example if only percentage limits are maintained and absolute values are marked as “Do not check”.

Upper % limit: 10.00                                                     Lower % limit: 10.00

Test data :- (GR has been defined)

PO quantity = 100 EA

PO price = 100 USD

GR quantity = 50 EA

     a)System behavior when invoice quantity is 55

     Variance = (quantity invoiced – total quantity delivered)/ (quantity expected)*100 %

                 = (55-50)/50 * 100 %

                 = (5/50)*100 %

                  = 10 %

     Variance 10% is equal to upper limit 10 % and there will not be any warning message.

     b)System behavior when invoice quantity is 56

     Variance = (quantity invoiced – total quantity delivered)/ (quantity expected)*100 %

                    = (56-50)/50 * 100 %

                    = (6/50)*100 %

                    = 12 %

     Variance 12% is more than upper limit 10% and there will be a warning message as below. Invoice will be blocked for payment and same tables will be updated as above.

DQ2.png

Both Variances active:

If both absolute & percentage variance are active the system would block which ever tolerance is first breached.

Quantity check for Delivery cost:

The system also carries out a quantity variance check for planned delivery costs when we post only planned delivery cost.

Tolerance key not maintained:

If the tolerance key DQ is not maintained for a company code when we perform the same transactions discussed earlier, system considers this as zero tolerance and block the invoice for the payment for any deviation.

7.DW: Quantity variance when GR quantity = zero

Definition:

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.

System behavior:

This tolerance key works only for PO based invoice verification because GR based invoice verification will not allow IR without GR.

DW absolute upper limit as 100:

PO quantity = 100 EA

PO price       = 10 USD

No GRN posted

     a)If the IR quantity is 10 then system calculates variance as below

     Variance = Net order price * (quantity invoiced + total quantity invoiced so far)

                    = 10 *(10+0) = 100

     This value is equal to DW limit hence there is no warning message and system will not block the invoice.


     b)If the IR quantity is 11 then system calculates variance as below and block the invoice.

     Variance = 10 *(11+0) = 110

DQ3.png

This value is more than DW tolerance absolute upper limit hence invoice got blocked.

It updates tables as below

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

DW

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRM = X

(Quantity block )

Yes

Automatic release possible if the blocking reason RSEG- SPGRM is deleted when we post GRN for the balance quantity or credit memo for the excess invoiced quantity

DW absolute upper limit as “Do not check”:

PO quantity = 100 EA

PO price       = 10 USD

No GRN posted

If the IR quantity is 112 then also system would not block even though this is beyond the DQ tolerance since it has been maintained as “Do not check” and there is no GR has been done.

“One should be very careful to use this option as this would by-pass quantity variance DQ block if there is no GR posted where GR has been planned”

DW tolerance key is not maintained:

If this key is not maintained for a company code it would always blocks the invoice for PO based invoice verification when there is no GR has been posted.

Please refer Part-2 for remaining tolerance keys

Reference:

* SAP IMG documentation


To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

    1. Dalapathy Sankar

      Nice Blog. Could you please guide me for the below scenario. PO Qty = 100 with unlimited over delivery check box, GR = 140 Qty. GR checked but No GR based IV, MIRO should post for 140 Qty by blocking invoice with Tolerance key DQ as 1% (warning message). Currently system is not checking DQ tolerance as its two way match (PO based invoice) and ignores the tolerance % as its unlimited delivery check box in PO

      (0) 
  1. Pravin Bakrania

    Hello Raja Ramasamy – This is very useful document and would appreciate if you can also post “Part -2” of this “Tolerance Keys – An Insight” – I am more interested in  examples of “KW” “ST” “PP”.

     

    Thanks once again !

    (0) 
  2. Danny Roussel

    very usefull blog, thanks!

     

    I was wandering if we can block an invoice if the received quantity > ordererd quantity.

     

    So we want to do the goods receipt, but the related invoice should get blocked.

     

    Any idea please?

     

    Danny

    (0) 
  3. Dalapathy Sankar

    Nice Blog. Could you please guide me for the below scenario.

     

    PO Qty = 100 with unlimited over delivery check box, GR = 140 Qty. GR checked but No GR based IV, MIRO should post for 140 Qty by blocking invoice with Tolerance key DQ as 1% (warning message). Currently system is not checking DQ tolerance as its two way match (PO based invoice) and ignores the tolerance % as its unlimited delivery check box in PO

    (0) 
  4. Gerald Brosch

    Hi Raja, this is a very helpful explanation of tolerance keys. I would apreciate very much if you would deliver the missing 2nd part of your explanations.

     

    Thanks,

    Gerald

    (0) 
  5. Martin Neethling

    One question; I read somewhere once that should you not have defined any tolerances the system will not allow any price or quantity variance. The purpose of defining invoice tolerances is actually to make the system less restrictive by turning off this functionality entirely or setting a tolerance to ensure that not ALL invoices with the slightest variance is blocked. Is this correct?

    (0) 

Leave a Reply