MM: procurement, GR/IR and inventory — Guided debugger and evidence walkthrough

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 — Guided debugger and evidence walkthrough

Outcome: Follow PO, goods movement and invoice evidence before blaming enhancements.

Prerequisites: MM/Inventory/Invoice Verification in ECC and S/4HANA with MATDOC-led reporting; public cloud uses corresponding apps. Work only in approved test systems.

Sample evidence

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 sample

Six-stage walkthrough

1. Open PO history, compare GR and IR item-level quantities, units, prices, dates, reversals and posting documents.
2. Check whether the open amount is a legitimate pending invoice, quantity mismatch or price/FX/tax variance.
3. Review movement and invoice documents using authorized display tools; avoid using direct table edits as a correction.
4. For unexpected rejection, inspect tolerance, valuation/account determination, posting period, workflow and authorization in that order.
5. Only if standard rules are satisfied, isolate custom BAdI/exit with a reproducible sample and technical ownership.
6. Confirm reconciliation with FI: open balance, invoice block status, subsequent credit/debit and approved clearing path.

Evidence observations

1. PO History shows GR 10 EA and IR 8 EA, which explains a two-unit open quantity.
2. Both accounting and material documents exist; no evidence shows a missing background commit.
3. A second invoice could be valid or the supplier may need a correction; business agreement is required.

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

Regression checks

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

Check your diagnosis

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.

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.

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

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.

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.