Price variance, payment block R, and the clerk with a workaround
Purchase order 4500012345 covers 100 PC of material 4711 at 100.00 EUR, plant 1010, no account assignment, goods-receipt-based invoice verification not flagged. The goods receipt for 100 PC has been posted. The vendor invoice arrives for 100 PC at 105.00 EUR net, plus 19% input tax, total 12,495.00 EUR. Company code tolerances: upper price variance (PP) 2%, upper quantity variance (DQ) 5%, small difference (PD) 50 EUR. The invoice is saved and the system sets payment block R. The AP clerk asks whether she can simply delete the payment block in the vendor master so that the next payment run pays the vendor.
1. Show why the invoice was blocked, then evaluate the clerk's proposed workaround and list the acceptable ways to resolve it.
Read the worked answer
Tolerance check: price variance = (105.00 - 100.00) x 100 = 500.00 EUR. Permitted upper PP variance = 2% of 10,000.00 = 200.00 EUR. 500.00 > 200.00, and 500.00 is also above the 50.00 EUR small-difference limit, so the invoice is blocked with the configured blocking reason (payment block R).
The workaround must be rejected on two grounds. First, it does not work: the block sits on the invoice document (RBKP, payment block field), not on the vendor master. The payment run excludes blocked items regardless of the vendor's payment block. Second, even if it did work it would bypass the approval the tolerance is there to enforce.
Acceptable resolutions, depending on the business fact:
- Price increase is legitimate and permanent: change the purchase order condition (ME22N) so future receipts and invoices match, and release the blocked invoice via MRBR with the authorized release code. Purchase-order history then shows an accepted price change.
- Price increase is one-off: release the invoice via MRBR (the differences post normally), or post a subsequent debit against a separate PO if the amount relates to a different service.
- Price was simply wrong: ask the vendor for a corrected invoice and park/reject the current one; do not post it. Raising the PP tolerance to 5% would automate every future case of this size and is a policy decision, not a bookkeeping fix - it needs the controller's sign-off and a note in the tolerance documentation.
2. Assume the invoice is released and posted. Show the accounting entries and explain how the 500.00 EUR is treated for a standard-price material versus a moving-average material.
Read the worked answer
Invoice posting (gross 12,495.00):
| Line | Account | Debit | Credit |
|---|---|---|---|
| 1 | GR/IR clearing (WRX) | 10,000.00 | |
| 2 | Price difference | 500.00 | |
| 3 | Input tax (19%) | 1,995.00 | |
| 4 | Vendor | 12,495.00 |
The GR/IR line is exactly the valuated receipt, so the GR/IR account clears to zero for this item once the invoice is posted.
The 500.00 EUR: for a standard price material it can never change the material price; it is posted to a price difference account (transaction key PRD / FR1 depending on the configuration) as an expense. For a moving average material, classic MM posts the difference to the stock account as long as stock coverage exists, so the MAP rises slightly; only the part not covered by stock goes to the price difference account. Note that in S/4HANA with Material Ledger always active, the difference is recorded as a price difference and revalued into inventory through periodic actual costing - the same economic outcome, different mechanics.
Check the 'stock coverage' assumption before answering a variant of this question: if the 100 PC had already been consumed, there is no stock to capitalize into.
3. A second invoice from the same vendor, 100 PC at 100.00 EUR, arrives two days before the goods receipt is posted. What happens, and what would change if goods-receipt-based invoice verification were flagged on the purchase order item?
Read the worked answer
Without GR-based IV, the invoice is not blocked for the missing receipt: the system posts it, debiting GR/IR clearing for 10,000.00 and crediting the vendor, and the GR posted later also hits GR/IR. The account shows a debit balance (invoice) against a credit (receipt) and clears when both exist; the interim risk is that you have paid for goods you have not received, which is a business control question, not a system one.
With GR-based IV flagged on the item, the invoice is tied to specific receipt documents. An invoice with no receipt behind it is blocked (blocking reason for missing goods receipt) and the block cannot be released in MRBR until the receipt is posted; MRBR will refuse with a message pointing at the missing assignment. The item's GR/IR is then managed per goods-receipt document, which also enables Evaluated Receipt Settlement and makes the GR/IR balance traceable to individual receipts.
Judgement: flag GR-based IV where the vendor is paid only after receipt and where per-receipt reconciliation matters. Do not switch it on for an item with open invoices and open GR/IR - the existing balances are tied to the old logic and will not reconcile cleanly.