SAP transaction codeObjectMIR6ModuleMM_P2P

MIR6 — MIR6 Invoice Overview List

MIR6 is the list/report transaction for logistics invoice verification. It displays all invoice documents created through MIRO, MIR7, or MIRA for a given selection, showing their status - parked, held, posted, or blocked for payment - and lets the user drill down into the individual document. It changes nothing on its own; it is a monitoring screen over RBKP and RSEG.

This page covers MIR6, the invoice overview report used to monitor the status of vendor invoices entered through logistics invoice verification. It focuses on why the list appears empty or wrong when documents exist, and how to read the status flags correctly before escalating.

Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,058 words

Purpose

MIR6 lists invoice documents created in logistics invoice verification - the objects that live in RBKP and RSEG rather than pure FI documents entered through FB60. It shows the invoice's current state: held, parked, posted, or blocked for payment, and whether it has been reversed. The structural fact that causes most confusion is that MIR6 only surfaces documents that went through the MM invoice verification path. Invoices entered directly in FI, or credit memos posted with a different transaction, will not appear here even though they affect the same vendor and the same open items in FI. A user comparing an FI vendor line-item report against MIR6 and finding a discrepancy is usually not looking at a data error, just two different populations of documents.

When it is used

MIR6 is reached for during periodic monitoring rather than during a single transaction. AP teams run it before period close to find parked or held invoices that still need action, to check for invoices blocked by quantity or price variance, or to see which invoices were reversed and why. MM consultants use it when a business user reports 'the invoice disappeared' or 'the invoice is stuck' - MIR6 confirms whether the document exists and what state it is actually in before anyone opens MIR4 or MIR7 to work on it individually. In an S/4HANA landscape the Fiori app for managing supplier invoices covers the same ground with a friendlier UI and is generally preferred for day-to-day work, but MIR6 remains the fast way to run a broad selection and export it.

How to use it in practice

  • Call MIR6.
  • Enter selection criteria: company code, vendor, invoice document number range, posting date, fiscal year, and optionally invoice status (held, parked, posted, blocked).
  • Execute the selection.
  • Review the resulting list, checking the status column and any variance or block indicators.
  • Double-click a line to jump into MIR4 for display, or into MIR7 if the document is still parked and needs completion.

Key data objects

  • RBKP - invoice document header, holding the invoice status, reference to the reversal document if any, and vendor and amount data.
  • RSEG - invoice line items, holding quantity, amount, and reference back to the purchase order and PO line.
  • BKPF and BSEG - the FI documents generated once the invoice is actually posted; parked or held invoices in RBKP have no counterpart here yet.
  • EKBE - purchase order history, used to reconcile the invoice quantity and value against goods receipt for the same PO line.

How to prove it in the data

In SE16, open RBKP filtered on company code, fiscal year, and the invoice status field (RBSTAT) to confirm whether a document is genuinely held, parked, or posted rather than trusting the list screen's rendering. Cross-check the reversal fields (STBLG and STJAH) on the same record before assuming a duplicate posting. If the FI document should exist, look up BKPF using the belnr stored in RBKP's linked document reference and confirm it actually posted; a blank reference confirms the invoice never left parked status.

ECC vs S/4HANA

MIR6 runs on S/4HANA largely unchanged, over the same RBKP and RSEG tables used in ECC; logistics invoice verification was not restructured the way goods movement and material master data were. The Fiori app for managing supplier invoices is the recommended entry point for interactive daily monitoring and offers filtering and status views closer to how AP teams actually work, but MIR6 remains valid for broad selections, batch checks, and situations where the classic list format is easier to export or compare against a legacy report.

Common pitfalls and how to diagnose them

  • Empty result list: the most common cause is a fiscal year mismatch, since RBKP is a year-dependent key and a selection that only specifies posting date without fiscal year, or the wrong fiscal year, returns nothing even though the invoice exists. The second most common cause is that the document was posted through FB60 or FB65 rather than MIRO, so it is a pure FI document and simply will not appear in this MM-specific list.
  • Status confusion: held and parked look similar to a casual reader but behave differently downstream - held invoices have not passed any consistency check and can be freely edited or deleted, parked invoices have been checked and are waiting for completion or approval. Read the status field directly in RBKP rather than relying on a remembered icon meaning.
  • Apparent duplicate invoice: before treating two lines for the same vendor and amount as a double posting, check the reversal indicator on both documents. A reversed-and-reentered invoice shows up as two rows and looks like a duplicate at a glance.
  • Invoice visible but never posted to FI: a parked or blocked invoice has no BKPF counterpart. Investigate why it is blocked - price variance beyond tolerance, quantity variance against goods receipt, or a missing release - before assuming a technical fault.
  • Incomplete-looking list due to authorization: a user restricted by company code or purchasing organization authorization sees a shorter list than the actual document population and may wrongly report missing invoices.

Whose problem this is

This is an AP/MM functional problem, not an ABAP or Basis one, unless the issue is authorization scoping or a performance timeout on a very wide selection. A good handover to functional includes the exact selection criteria used, the vendor and document number if known, the status shown, and whether the expectation was that the invoice should already be posted to FI.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tcodes/mir6ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.