The 3 way matching process, described, takes a paragraph: compare the invoice with the order and the receipt, and pay if they agree within tolerance. Run day to day, almost all of the effort goes on the invoices that do not agree, and how well a team copes is determined by how deliberately that side was designed rather than by the comparison itself.
The comparison, and the tolerance around it
Supplier, unit price, quantity and total, at line level. Within tolerance, the invoice clears. Tolerance should be a percentage with an absolute cap so a small proportional difference on a large invoice does not pass unnoticed, and it should be reviewed after a month against the exceptions it actually produced rather than left at a default.
What a good exception carries
The reason it failed, the two numbers that disagree, the line it happened on, an owner who can resolve it and an age. That is a short conversation with a specific person. An exception carrying only the fact of failure is a research task, and a queue of those is what makes payables teams feel they are drowning.
The weekly and monthly rhythm
Weekly, look at the oldest items in each exception category and chase those specifically. Monthly, look at the distribution of reasons and act on the largest, which is nearly always upstream. Clearing the queue repeatedly is work; changing what generates it is improvement, and only the monthly look shows you which is which.
Questions people ask about 3 way matching process
Who should resolve each exception type?
Price to purchasing, quantity and missing receipts to whoever takes deliveries, supplier problems to whoever maintains records, disputes to a named owner.
Should payables be able to override?
Within tolerance and with the reason recorded. Unrecorded overrides turn the control into a formality nobody can audit.
What if exceptions keep growing?
That is an upstream signal, usually falling purchase-order coverage or receipts not being recorded. Report the reason mix rather than the total.