Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
o
3 way match: Invoice line item is checked against corresponding purchase order and
good receipt documents item for price & quantity matching
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:
o
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
Stochastically blocked
Item level:
Table: RSEG
Fields:
SPGRP
Blocking reason
price
SPGRM
Blocking reason
quantity
SPGRT
SPGRG
SPGRV
Blocking reason
Project
SPGRQ
Manual blocking
Value = X
reason
SPGRS
Blocking reason
amount
SPGRC
Blocking reason:
Quality
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_BLOCK
ED
RSEG
Auto
release
AN
No blocking
indicator
update(ZLSP
R)
AAuto
block
No update
Not
possible
(item
amount
block)
Item amount check must allowed for item category and GR indicator OMRI
System behavior:
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
Tolerance
Key
RBKP
RBKP_BLOCK
ED
RSEG
Auto
release
AP
No blocking
indicator
update(ZLSP
R)
A-Auto block
RSEGSPGRS = X
Not
possible
(item
amount
block)
AP invoice processor enters the invoice amount as per the vendors 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
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.
RBKP MAKZN (net amount accepted manually) field will get updated with small diff.
amount : 3.00
Toleranc
e Key
Toleranc
e
RBKP
RBKP_
BLOCK
ED
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)
No
update
No
blocking
reason
update
NA
MAKZN field
updated with diff.
amount
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.
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:
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.
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
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
RBKP
RBKP_BLOCK
RSEG
Auto
Key
BR
ED
No blocking
indicator
update(ZLSP
R)
A- Auto block
relea
se
RSEG- SPGRS
=X
Not
possi
ble
(item amount
block)
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
Tolerance
Key
RBKP
RBKP_BLOCK
ED
RSEG
Auto
relea
se
BR
No blocking
indicator
update(ZLSP
R)
A- Auto block
RSEG- SPGRS
=X
Not
possi
ble
(item amount
block)
When we post invoice with above variance it will get blocked for payment.
It updates tables as below
Tolerance
Key
RBKP
RBKP_BLOCKE
D
RSEG
Auto
release
DQ
No blocking
indicator
update
(ZLSPR)
A- Auto block
RSEG- SPGRM =
X
Yes
(Quantity
block )
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.
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
This value is more than DW tolerance absolute upper limit hence invoice got blocked.
It updates tables as below
Tolerance
Key
RBKP
RBKP_BLOCKE
D
RSEG
Auto
release
DW
No blocking
indicator
update
(ZLSPR)
A- Auto block
RSEG- SPGRM
=X
Yes
(Quantity block
)
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
System Behavior:
PO Qty = 100 EA
FRB1 = 100 SGD
GRN Qty = 100 EA
IR Qty = 100 EA
Planned delivery cost = 110 SGD
Variance (KW) = 100 * (110/100) = 110 which is 10 SGD more than PO but within the
tolerance hence No warning message.
If planned delivery cost is 111 SGD
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
KW
RBKP
No blocking
indicator
update
(ZLSPR)
RBKP_BLOCKE
D
A- Auto block
RSEG
RSEG- SPGRP =
X
(Price block for
Delivery cost
line)
Auto
release
NO
System Behavior:
PO Limit = 1000 SGD
GR not applicable
IR1 Value = 500 SGD
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.
Tolerance
Key
RBKP
RBKP_BLOCKE
D
RSEG
LA
No blocking
indicator
update
A- Auto block
RSEGSPGRP = X
Auto release
A. Yes. If we
adjust the PO
(ZLSPR)
overall limit
System behavior:
Scenario 1:
PO Validity end date: 03/12/2015
Posting date : 13/12/2015
No warning message because (13-03)= 10 days is within tolerance
Scenario 2:
PO Validity end date: 03/12/2015
Posting date : 14/12/2015
Warning message as below since variance is above tolerance (14-3) = 11 days. It will be
blocked for payment .
Tolerance
Key
RBKP
RBKP_BLOCKE
D
RSEG
LD
No blocking
indicator
update
(ZLSPR)
A- Auto block
RSEGSPGRT = X
Auto release
A. Yes. If we
adjust the
PO Validity
end date
System behavior:
Scenario 1:
PO Price :100 SGD / Item
PO Qty -:100 EA
PO Total value : 10000 SGD
IR Total amount: 10010 SGD
IR 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 Price :100 SGD / Item
PO Qty -:100 EA
PO Total value : 10000 SGD
IR Total amount: 10011 SGD
IR Qty 100 EA
System would pop-up below message. Since the variance is (10010 10000) = 11 SGD
which is above the tolerance and it will be blocked for payment.
Scenario 3:
Tolerance
Key
RBKP
RBKP_BLOCKE
D
RSEG
PP
No blocking
indicator
update
(ZLSPR)
A- Auto block
RSEGSPGRP = X
Auto release
A. Yes. If we
adjust the
PO Price
PS:
Price
Tolerance
Key
RBKP
RBKP_BLOCK
ED
RSEG
PS
No blocking
indicator
update
(ZLSPR)
A- Auto block
RSEGSPGRP = X
Auto
release
A. Yes.
If
we
adj
ust
the
PO
Pric
e
ST: Date
variance
(value x days)
Definition:
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 item value: 100 SGD Per item
PO Qty = 10 EA
PO Value = 1000 SGD
PO Delivery date: 03/12/2015
IR Value = 1000 SGD
IR Qty = 10 EA
Invoice entering date = 02/12/2015
Variance = PO item amount * ( PO delivery date Invoice entry date)
= 100 (3- 2) = 100 *1 = 100 SGD
This is within tolerance hence no warning message.
RBKP
RBKP_BLOCK
ED
RSEG
ST
No blocking
indicator
update
(ZLSPR)
A- Auto block
RSEGSPGRT = X
Auto
release
A. Ye
s.
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:
Material master MAP price: 100 SGD
PO Price = 100 SGD , Quantity = 10 EA and Value = 1000 SGD
Invoice value = 1060 SGD
New MAP after invoice posting = 1060/10= 106 SGD
Variance = (106 100 )/100 = 6%
Within PP tolerance limit but above the VP tolerance limit.
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.