MIRO — Enter a supplier invoice
MIRO enters an incoming supplier invoice with reference to a purchasing document. The invoice is matched against the purchase order and the goods receipt, tolerances decide whether a difference is accepted or blocked, and posting creates the accounting document that clears GR/IR and opens the payable to the supplier.
Logistics invoice verification: three-way matching, tolerances and blocks, and the reasons an invoice will not post.
Published 20 Sept 2026· 727 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
What MIRO is for
MIRO is where a supplier invoice is checked against what was ordered and what was received before any money is owed. Entering the invoice with reference to the purchasing document lets the system compare quantity and value against the order and the goods receipt, which is the three-way match. Posting clears the GR/IR account created by the receipt and opens the payable in accounts payable. Because it sits on the boundary between logistics and finance, an invoice that will not post is usually explained by purchasing data, receipt data or configuration rather than by the invoice itself.
When it is used in procure-to-pay
Invoice verification is the last step of procure-to-pay for purchased materials and services. In a goods-receipt-based design the invoice can only be posted for quantities already received, so timing problems in receiving become invoice problems here. Accounts payable teams work through invoices daily, often with automation handling the clean ones and users handling exceptions, which means the invoices reaching this transaction manually are disproportionately the difficult ones. Consultants also use it in every test cycle, because a posted invoice proves that purchasing, receiving, tax and account determination all agree.
How it is used in practice
You enter the invoice date, the reference from the supplier document, the amount as billed and the tax information, then the purchase order or delivery note the invoice relates to. The system proposes items from the order and the receipt, and you confirm or correct quantity and value per line. The balance indicator is the discipline of this screen: the invoice can only be posted when the entered amount and the allocated items agree. Delivery costs, unplanned costs and subsequent debits are entered as separate item types rather than by inflating a line. Before posting, review any payment or price block that the tolerance check has applied.
Fields and objects that matter
- Invoice date, posting date and supplier reference, which drive the period, due date and duplicate check
- Amount and tax code, which must reconcile with the allocated items
- Purchase order or delivery note reference, the basis for the three-way match
- Quantity and value per item, where the actual variance against order or receipt becomes visible
- Payment block and price block, which the tolerance configuration applies automatically
- Invoice document header RBKP and items RSEG, plus the accounting document produced on posting
How to prove it in the data
For a posted supplier invoice, reconcile RBKP/RSEG with the purchase-order history in EKBE and the generated accounting document in BKPF/BSEG and ACDOCA. Confirm PO quantity/value, goods receipts, tax and GR/IR clearing using the same company code, fiscal year and currency context. Parked or held documents must be distinguished from posted invoices.
ECC vs S/4HANA
MIRO remains available in S/4HANA as the advanced supplier-invoice transaction, while SAP also provides the Create Supplier Invoice Fiori app. Logistics Invoice Verification still uses RBKP/RSEG for the invoice document and integrates the resulting accounting posting with the Universal Journal.
Common pitfalls and how they show up
- A balance that will not clear because delivery or unplanned costs were pushed into a material line
- Posting an invoice before the goods receipt in a receipt-based design, which the system refuses
- Price or quantity differences outside tolerance, which post but block payment, so the supplier chases an invoice that is already in the system
- A wrong tax code, which breaks reconciliation between the invoice value and the tax reporting
- Duplicate invoices posted because the supplier reference was left blank or entered inconsistently
- Correcting a variance by editing the invoice when the purchase order price or the receipt quantity is what is actually wrong
- GR/IR balances that persist because quantities were invoiced against a line that was received differently
Whose problem this is
Primary ownership is MM Logistics Invoice Verification with Accounts Payable/Finance. Purchasing and warehouse teams own PO and GR discrepancies; Tax owns tax configuration; integration or ABAP teams join only when inbound invoice mapping or custom logic is evidenced.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
Source: ERPClimb — https://erpclimb.com/sap-tcodes/miroERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.