MM: procurement, GR/IR and inventory — Root-cause case, remediation and assessment
Full lesson currently free to read · AI practice limits apply separately
Training simulation: All sample identifiers, logs, requests, transactions, values and cases are fictional. Tools and permissions vary by SAP release; perform any changes only in approved DEV/QA environments. MM: procurement, GR/IR and inventory — Root-cause case, remediation and assessment Incident: Purchase order approval, GR posting or invoice matching fails.
Visual overview
Explanation
Training simulation: All sample identifiers, logs, requests, transactions, values and cases are fictional. Tools and permissions vary by SAP release; perform any changes only in approved DEV/QA environments.
MM: procurement, GR/IR and inventory — Root-cause case, remediation and assessment
Incident: Purchase order approval, GR posting or invoice matching fails.
Landscape: MM/Inventory/Invoice Verification in ECC and S/4HANA with MATDOC-led reporting; public cloud uses corresponding apps.
Fictional incident dossier
PO DEMO-MM-204: 10 EA at 100 EUR; GR 10 EA postedInvoice IR DEMO-204: 8 EA at 100 EURGR/IR quantity open = 2 EA | amount example 200 EURMIGO material doc and MIRO invoice both existNo failed posting dump in this sampleEvidence observations
- PO History shows GR 10 EA and IR 8 EA, which explains a two-unit open quantity.
- Both accounting and material documents exist; no evidence shows a missing background commit.
- A second invoice could be valid or the supplier may need a correction; business agreement is required.
Three hypotheses
- Two units remain legitimately uninvoiced at the agreed price.
- An invoice is blocked by tolerance even when receipt quantity matches.
- An account determination error prevented GR or invoice posting entirely.
Supported: 1.
Evidence-backed root cause
The sample deliberately has an invoiced quantity lower than the received quantity. The residual GR/IR amount is a traceable business timing difference, not an ABAP or FI ledger defect.
Safe remediation
Confirm with procurement and AP whether the missing quantity will be invoiced, credited or returned. Complete the approved process and reconcile resulting FI balances; do not force clearing to make a dashboard green.
Diagnostic runbook
- Open PO history, compare GR and IR item-level quantities, units, prices, dates, reversals and posting documents.
- Check whether the open amount is a legitimate pending invoice, quantity mismatch or price/FX/tax variance.
- Review movement and invoice documents using authorized display tools; avoid using direct table edits as a correction.
- For unexpected rejection, inspect tolerance, valuation/account determination, posting period, workflow and authorization in that order.
- Only if standard rules are satisfied, isolate custom BAdI/exit with a reproducible sample and technical ownership.
- Confirm reconciliation with FI: open balance, invoice block status, subsequent credit/debit and approved clearing path.
Confirm resolution
- Positive: Matched GR/IR quantities reconcile to expected open items under the business process.
- Negative: Price/quantity/tax mismatch cases receive their designated tolerance handling.
- Cross-process: Duplicate invoice reference is detected or reviewed before any repeat posting.
Assessment
Question: A PO shows GR 10 units, IR 8 units and a remaining GR/IR balance. What does the evidence suggest?
A. The difference may be legitimate pending invoice quantity; reconcile source documents.
B. The database must be corrupted.
C. Post a dummy invoice in production to zero the balance.
Correct: A. Document quantity difference explains the open item until other evidence proves an error.
Safety: GR/IR clearing, invoice reposting or stock movements are financial actions requiring business authorization, not debugging shortcuts.
Real project scenario
Synthetic case: Purchase order approval, GR posting or invoice matching fails.
The sample deliberately has an invoiced quantity lower than the received quantity. The residual GR/IR amount is a traceable business timing difference, not an ABAP or FI ledger defect.
Common mistakes
- An open GR/IR item can be an expected business timing mismatch.
- A MIRO tolerance block isn't the same as a missing PO approval.
- S/4HANA's MATDOC-based inventory data model changes how diagnostic queries should be designed.
Best practices
Confirm with procurement and AP whether the missing quantity will be invoiced, credited or returned. Complete the approved process and reconcile resulting FI balances; do not force clearing to make a dashboard green.
- Positive: Matched GR/IR quantities reconcile to expected open items under the business process.
- Negative: Price/quantity/tax mismatch cases receive their designated tolerance handling.
- Cross-process: Duplicate invoice reference is detected or reviewed before any repeat posting.
GR/IR clearing, invoice reposting or stock movements are financial actions requiring business authorization, not debugging shortcuts.
Interview angle
Procure-to-pay debugging: purchase order history, account determination for goods receipt (OBYC transaction keys), invoice verification blocks and tolerances, GR/IR balances and their clearing, and source determination issues.
Practice this lesson
Original educational case studies for SAP consultants, not official SAP certification exam questions. Verify product edition and implementation details against the current SAP documentation.
Quick check
0 of 4 questions attempted
1. A PO shows GR 10 units, IR 8 units and a remaining GR/IR balance. What does the evidence suggest?
2. A goods receipt posts to the wrong G/L account. Which area do you analyse?
3. An invoice is blocked for payment due to a price difference. What is the cause?
4. Where can you see goods receipts and invoices posted for a PO item?
Interview questions
1. How do you investigate a GR/IR account balance that doesn't clear?
Answer it in your own words first, then compare.
2. A purchase requisition doesn't convert to a PO automatically. What do you check?
Answer it in your own words first, then compare.
Check before use: lesson examples are educational, not a guarantee of correctness for your SAP edition or release. Sample code has not been executed on your SAP system. Confirm API availability, syntax, authorizations and business impact in an approved development or test environment.