Two-Way, Three-Way, and Four-Way Matching in Oracle Procurement: What Each Actually Checks

A supplier goes live on four-way match for a new equipment category. Two weeks later, invoices for that supplier are stuck in the queue, aging, and nobody in AP knows why. The PO looks fine. The receipt posted. The invoice matches on price and quantity. It still won't validate.

The missing piece was inspection acceptance. Four-way match doesn't stop at receipt, it waits for a documented acceptance transaction, and nobody had set up a receiving routing that generates one. This is the most common gap I see between what a team assumes matching does and what it actually checks.

What each match level actually validates

Two-way match compares the invoice against the purchase order only, on price and quantity, with no receipt required. It's built for services, non-tracked items, or categories where a receipt would just be a rubber stamp with no real control behind it.

Three-way match adds the receipt into the comparison. The invoice has to agree with both the PO and what was actually received. This is the default for anything physical that moves through inventory, where "what was ordered" and "what showed up" can legitimately diverge.

Four-way match adds one more checkpoint: a formal inspection or acceptance transaction, separate from the receipt itself. Receiving the box isn't enough, someone has to confirm the contents meet spec before the invoice can clear. This is the level teams reach for with capital equipment, regulated items, or anything where "it arrived" and "it's acceptable" are genuinely different questions.

Where this gets misconfigured

The match option lives at the purchase order schedule, and it typically inherits from the purchasing agreement or the item's default matching setup. Teams often set the match level correctly, then forget the dependency underneath it: four-way match needs a receiving routing on that item or category that actually produces an inspection step, rather than a standard or direct-delivery routing. Without that routing, there's no inspection transaction for the match to find, and the invoice sits in limbo with no error that points back to the real cause.

The second common miss is tolerances. Matching isn't binary. Price and quantity tolerances, set on the invoice matching options and receiving parameters, decide how much variance gets auto-approved versus routed to a hold. A tight tolerance on a category with routine unit-of-measure rounding will generate holds every single cycle, and the team ends up "fixing" it by loosening tolerances everywhere instead of loosening them only where the variance is genuinely expected.

A healthcare example

Loaner surgical trays are a good stress test for this. The PO comes in, the tray is received into inventory, and the temptation is to three-way match it and move on. But a loaner tray missing an instrument, or arriving non-sterile, is a real problem that a receipt alone won't catch. Four-way match, tied to a documented inspection or count-back step, is the control that actually protects the OR schedule and the AP function at the same time.

Exact task names and routing options have shifted across Oracle Fusion releases, so treat the setup described here as the shape of the process, not a click-by-click guide. Confirm the current screen against your release's Oracle documentation before changing a live configuration.

The takeaway

Before changing a match level, ask what document is supposed to prove the match, not just what document is supposed to trigger it. Two-way proves a PO exists. Three-way proves something arrived. Four-way proves something arrived and was actually acceptable. Pick the level based on which of those three questions your business genuinely needs answered, not on habit.