SAP Invoice verification

When a vendor invoice arrives, invoice verification matches it to the PO (price, terms) and the goods receipt (quantity), the three-way match. If it matches within tolerance, it posts the vendor liability (FI-AP) and clears the GR/IR account. If not, it blocks the invoice for review.

• Three-way match: PO vs GR vs invoice.
• Tolerances: allowed price/quantity variances.
• GR/IR clearing: cleared by the invoice posting.
• Blocking & release: invoices held for discrepancies (MRBR).

One mechanism worth naming: the invoice can be posted against the purchase order or against the goods receipt, and which is allowed is the goods receipt based invoice verification flag on the order item. With it off, an invoice for ten units matches an order for ten regardless of how many arrived. With it on, it must match a specific receipt, which is what makes partial deliveries controllable rather than a running total.

The control is described everywhere as a three-way match and the value is in what each leg independently establishes.

The purchase order says what was agreed: the item, the quantity, the price, the terms. Somebody with authority to commit money approved it, possibly through a release strategy.

The goods receipt says what arrived, posted by somebody who saw it. This is the leg that cannot be faked from a desk, which is why it is the strongest of the three.

The invoice says what the supplier wants paid.

Matching them answers two separate questions. Did we order this at this price, and did we actually receive it. An invoice matching the order but not a receipt means paying for goods nobody has seen. One matching a receipt but not the order means paying a price nobody agreed.

When they disagree, invoice verification posts the document and blocks it for payment. That distinction matters: the liability is recorded, so the accounts are complete, and the money does not move. A blocked invoice is a working control rather than a failure.

The block reason tells you who owns it. A price block is procurement. A quantity block is usually receiving. Finance sees the blocked item and can resolve neither.

Half an hour, and it covers the control the whole cycle exists for.

1. Post a goods receipt against a purchase order for ten units.
2. Post an invoice with MIRO for ten units at the order price. It posts and is payable, and the goods receipt clearing account nets to zero for that line.
3. Now do it again on another order, entering a price ten per cent higher than the order.
4. The document posts and blocks. Read the reason on the invoice.
5. Look at the vendor line item list. The liability is there and it is blocked, so a payment run will skip it.
6. Release it with MRBR, or correct the order price and let the block clear, depending on which was actually wrong.

Step six is the decision that matters: was the invoice wrong or was the order. Releasing the block without answering that is how price creep gets paid.

Invoice verification is the finance-facing end of MM: it creates the AP liability that AP then pays and clears GR/IR. The three-way match and tolerances are a core control against overpaying or paying for goods not received, a key audit and cash-control point.

The account mechanics are worth holding. The goods receipt debited stock and credited the goods receipt and invoice receipt clearing account. The invoice debits that clearing account and credits the vendor. When quantity and value agree, the clearing account nets to zero per purchase order line, which is why an aged balance there means receipts and invoices are not matching. See inventory for the receipt half.

• Tolerances. How much price and quantity variance passes without a block. Too tight and everything blocks and nobody looks; too loose and the control is decorative.
• Goods receipt based invoice verification. On, and the invoice must match a specific receipt rather than the order overall, which is much stronger for partial deliveries.
• Automatic settlement. Evaluated receipt settlement pays from the receipt with no invoice at all, which removes an entire class of mismatch and requires real trust in the prices.
• Who releases blocks. Named, with authority, or blocked items age for months.

Most invoices are not one invoice for one receipt, and the variations are where invoice verification gets interesting.

Planned delivery costs were on the order: freight, duty, insurance. They are accrued at goods receipt and settled when the carrier's invoice arrives, which is often separate from the supplier's.

Unplanned delivery costs arrive on the invoice with nothing anticipating them, and they have to be assigned: onto the material's value, or to a separate account.

Subsequent debit and credit adjust the value of something already invoiced without changing quantity, which is how a price correction is handled after the fact.

Invoices without reference are entered directly, which is legitimate for services and is the case with the weakest control.

Evaluated receipt settlement reverses the whole idea: no invoice at all. The system pays from the goods receipt at the order price, which removes every mismatch and requires complete confidence in the agreed prices.

Each behaves differently at posting, and the item category or the entry route decides which applies. When an invoice does something the standard match does not explain, the question is which of these it actually is.

An invoice that cannot be posted still needs recording, and parking is how that is done without committing anything.

Parking saves the invoice with a document number, visible to others, updating nothing. It is how an accounts payable team gets a day's post into the system before the queries are resolved, and it is what makes the "have you received my invoice" question answerable.

Holding is the personal draft equivalent: incomplete, private, no number.

Parked invoices matter at period end because they represent a known liability that is not in the ledger. A team that parks routinely and never reviews the parked list is understating payables, which is an accrual question at close.

The related control is invoice approval: parking plus a release step means one person enters and another posts, which is a segregation of duties that costs almost nothing to implement.

The discipline that makes it work is a parked invoice list reviewed on a schedule, with an age at which something has to happen, because the failure mode is invoices parked and forgotten rather than parked and resolved.

• Loose tolerances letting through wrong invoices.
• Not resolving blocked invoices (payments delayed).
• GR/IR not clearing due to quantity/price mismatches.

• Releasing blocks to clear a report. The block was information; clearing it without resolving the cause pays the difference.
• An aged goods receipt clearing balance nobody analyses. It is where unmatched receipts and invoices accumulate, and it is a year-end question.
• Invoicing without a receipt as routine. See procurement, vendor master and release strategies for the controls before this one.

• Tolerances copied from another client without thought. They encode somebody else's risk appetite and somebody else's supplier behaviour.

Posting an invoice is straightforward, and setting tolerances and blocking rules so the match catches what it should is the part you do in the course.

The account to watch is goods receipt and invoice receipt clearing. It should net to zero per purchase order line, and an ageing balance there is the honest measure of whether the three-way match is working.