Invoice Verification
MM / P2Pbeginner

Understanding Invoice Verification and the Three-Way Match

Introduces the business purpose of Invoice Verification, the three-way match concept, and how MIRO fits into the Procure-to-Pay cycle.

Explanation

Invoice Verification, commonly called Logistics Invoice Verification (LIV) in SAP MM, is the process by which a vendor's invoice is checked, matched and posted against the purchasing documents that preceded it. It sits at the end of the Procure-to-Pay (P2P) chain: a purchase requisition leads to a purchase order (PO), the PO triggers a goods receipt (GR) when material or service is delivered, and finally the vendor's invoice is verified against both the PO and the GR before payment is released. This is often called the three-way match: PO quantity/price, GR quantity, and invoice quantity/price are compared automatically by the system. Why this matters commercially: without a controlled matching process, a company risks paying for goods never received, paying incorrect prices, or duplicating payments. Invoice Verification enforces financial control by only allowing automatic payment when quantities and values are within tolerance, and by routing exceptions to accounts payable or purchasing staff for review. It also creates the accounting entries that clear the GR/IR (goods receipt/invoice receipt) clearing account, which is a temporary holding account bridging the timing gap between when goods are received (debiting inventory/expense, crediting GR/IR) and when the invoice arrives (debiting GR/IR, crediting vendor payable). The primary transaction for entering a vendor invoice is MIRO (Enter Incoming Invoice), which replaced the older MR01/MR1M-style transactions in modern SAP releases. In MIRO, a user selects the PO reference, the system proposes the quantities and amounts based on the goods receipt already posted, and the user compares this to what is stated on the physical or electronic vendor invoice document. If everything matches within configured tolerances, the invoice posts without a block. If there is a mismatch, SAP can set a payment block automatically depending on tolerance key configuration, preventing the vendor from being paid until the discrepancy is resolved. Invoice Verification can also be performed without a goods receipt reference in specific scenarios (for example, when the PO is flagged for invoice-based evaluated receipt or for service/planned delivery cost items), but the standard and most controlled scenario for materials is the PO + GR + Invoice three-way match. There are also invoices without PO reference (FI-oriented, using transactions outside pure LIV, though not covered in depth here), and credit memos, which reverse quantities or values previously invoiced. Key master data and documents involved: the purchase order (with price, quantity, tax code, and account assignment), the material document created by the goods receipt (which carries the quantity received and the moving average or standard price impact), and the vendor master (which holds payment terms, banking details, and withholding tax indicators where relevant). The invoice document itself, once posted, creates both a logistics invoice document (in the MM document number range) and an accounting document (FI document) simultaneously, linking the two worlds. For a beginner, the most important mental model is: goods receipt says 'we got the stuff and this is what we owe provisionally,' and invoice verification says 'here is what the vendor actually billed us, let's compare and settle the account.' Everything else in the topic, tolerance keys, blocking reasons, GR/IR reconciliation, variance postings, builds on this foundational three-way match idea.

Real project scenario

A mid-size manufacturing client processes several hundred vendor invoices weekly through MIRO. A new accounts payable clerk receives training on how to reference the PO number in MIRO, review the system-proposed quantity and value from the goods receipt, and identify when the invoice amount from the vendor's PDF does not match what SAP proposes. During the first week, several invoices are blocked automatically because the vendor billed a freight surcharge not present on the PO; the clerk learns to recognize this as a price variance requiring either PO amendment or tolerance-based release rather than forcing the posting.

Common mistakes

โ€ข Confusing the goods receipt document with the invoice document and assuming posting the GR alone settles the vendor's liability. โ€ข Attempting to force-post an invoice with a large variance by overriding the amount without investigating the root cause (wrong PO price, wrong GR quantity, or vendor billing error). โ€ข Not checking whether the PO is set for goods-receipt-based invoice verification before assuming a GR is mandatory. โ€ข Treating GR/IR clearing account balances as immaterial and not reconciling them periodically, leading to large unexplained balances at period-end. โ€ข Ignoring currency or unit-of-measure differences between the PO and the invoice, which can silently distort matching results.

Best practices

โ€ข Always reference the purchase order in MIRO rather than posting invoices as free-standing FI documents when goods or services were procured via PO. โ€ข Educate accounts payable staff to investigate root causes of variances rather than simply overriding blocked amounts. โ€ข Reconcile the GR/IR clearing account on a regular cadence (at least monthly) to catch quantity mismatches or un-invoiced receipts early. โ€ข Ensure goods receipts are posted promptly and accurately, since GR quantity is the primary reference point for invoice matching. โ€ข Document locally agreed tolerance thresholds so business users understand why some invoices post automatically and others are blocked.

Interview angle

Interviewers commonly ask candidates to explain the three-way match in their own words and to describe what happens in the system when quantities or prices do not match. Be ready to explain the role of the GR/IR clearing account, what a payment block versus a quantity/price block means practically, and how MIRO differs conceptually from a plain FI invoice posting (FB60) in terms of PO reference and account determination.