Professional Documents
Culture Documents
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 blocks 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.
o 3 way match:
Invoice line item is checked against corresponding purchase order and good receipt
documents item for price & quantity matching
o 2 way match:
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:
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
Invoice can be blocked always with a particular payment term even if there is no variance
4. Stochastic blocking:
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:
Possible values:
Fields:
System behavior:
If only the invoice line item is greater than absolute upper limit the invoice would be blocked.
“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 behaviour:
Let us understand with below example
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 RBKP RBKP_BLOCKED RSEG Auto
Key release
AP No blocking A-Auto block RSEG- Not
indicator SPGRS = X possible
update(ZLSPR)
(item
amount
block)
System behavior:
Let us understand with below example
AP invoice processor enters the invoice amount as per the vendor’s invoice copy which is 2
USD higher than PO price.
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
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.
The system calculates the percentage variance using below formula and compares the
variance with the upper and lower percentage tolerance limits.
Tolerance:
Material master:
PO Details:
PO has been created with CRT as Order unit and EA as Order price unit
Po quantity: 2 CRT = 24 EA
Invoice details:
Scenario 1:
Difference is 100 – 91.6 = 8.9 % which is within the BR tolerance limit 10% maintained
Scenario 2:
PO Details:
GR Details:
GR quantity in order unit – 2 CRT
IR Details:
Scenario 1:
= 90.9%
Difference is 100 – 90.9 = 9.1 % which is within the BR tolerance limit 10% maintained
Scenario 2:
= 86.4%
Difference is 100 – 86.4 = 13.6 % which is more than the BR tolerance limit 10% and invoice
posted with payment block.
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”.
PO quantity = 100 EA
GR quantity = 50 EA
= 100 * (1)
= 100
Variance 100 is equal to upper limit 100 and there will not be any warning message.
= 100 * (2)
= 200
Variance 200 is more than upper limit 100 and there will be a warning message as below.
When we post invoice with above variance it will get blocked for payment.
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.
PO quantity = 100 EA
GR not possible
= 100 * (1)
= 100
Variance 100 is equal to upper limit 100 and there will not be any warning message.
= 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.
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”.
PO quantity = 100 EA
GR quantity = 50 EA
= (55-50)/50 * 100 %
= (5/50)*100 %
= 10 %
Variance 10% is equal to upper limit 10 % and there will not be any warning message.
= (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.
If both absolute & percentage variance are active the system would block which ever
tolerance is first breached.
The system also carries out a quantity variance check for planned delivery costs when we
post only planned delivery cost.
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.
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.
PO price = 10 USD
No GRN posted
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.
This value is more than DW tolerance absolute upper limit hence invoice got blocked.
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
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.
System Behavior:
PO Qty = 100 EA
IR Qty = 100 EA
Variance (KW) = 100 * (110/100) = 110 which is 10 SGD more than PO but within the tolerance hence No
warning message.
Variance (KW) = 100 * (111/100) = 111 which is 11 SGD more than PO value above the tolerance hence
below warning message will be issued and invoice will be blocked for payment.
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release
KW No blocking A- Auto block RSEG- SPGRP NO
indicator update =X
(ZLSPR)
(Price block for
Delivery cost
line)
System Behavior:
GR not applicable
IR2 Value = 510 SGD system allows without any warning message as the variance = (500 +510)=1010 is
compared with PO limit 1000 SGD which is within the tolerance.
If we try to post the invoice for 511 then system would throw below pop-up message. Still we can post the
invoice which will be blocked for payment.
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 absolute upper limit defined.
System behavior:
Scenario 1:
Scenario 2:
Warning message as below since variance is above tolerance (14-3) = 11 days. It will be
blocked for payment .
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release
LD No blocking A- Auto block RSEG- SPGRT A. Yes. If
indicator update =X we
(ZLSPR) adjust
the PO
Validity
end
date
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).
System behavior:
Scenario 1:
PO Qty -:100 EA
System would allow without any message. Since the variance is (10010 – 10000) = 10 SGD
which is within the tolerance.
Scenario 2:
PO Qty -:100 EA
IR Qty – 100 EA
System would pop-up below message. Since the variance is (10011 – 10000) = 11 SGD
which is above the tolerance and it will be blocked for payment.
Scenario 3:
IR Qty = 100 EA
Then
Subsequent debit as
Qty = 100 EA
Value = 10 SGD
No warning message since the variance (already invoiced value+ current subquent debit value
– PO amount ) = ( 10000+ 10 – 10000) = 10 is within tolerance.
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).
This works same as ‘PP’ tolerance key when the PO price is flagged as
Estimate price.
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release
PS No blocking A- Auto block RSEG- SPGRP A. Yes. If
indicator update =X we
(ZLSPR) adjust
the PO
Price
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
javascript:;
System behavior:
Scenario 1:
PO Qty = 10 EA
IR Qty = 10 EA
This is above the tolerance limit hence invoice would get blocked for payment.
There won’t be any warning message for date discrepancies before posting the
invoice
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release
ST No blocking A- Auto block RSEG- SPGRT A. Yes.
indicator update =X
(ZLSPR)
VP: Moving average price variance
Definition:
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.
System behavior:
Below information message will pop-up and Invoice will not be blocked for payment. Based
on this tolerance key we can make the below info message as Warning or error before
posting.
With this I have completed all the tolerance keys relevant for Invoice Posting.