Supplier Invoice Matching

A bill is a supplier's claim, not proof that the buyer ordered or accepted everything listed, so invoice matching tests the claim against other records and helps prevent overpayment, duplicate payment and payment for undelivered items. Two-way matching compares the invoice with the purchase order or contract: supplier, item, price, quantity and terms.

Three-way matching adds evidence of receipt or accepted service, and some workflows also consider inspection or quality acceptance. Microsoft's three-way-matching guidance describes policies and tolerances in its finance product, and Oracle's matching guidance distinguishes two-, three- and four-way checks; these are implementations, not a single universal rule.

Confirm the supplier identity and payment destination through approved controls, because a convincing invoice can carry changed bank details or a look-alike vendor name, and a fictional AP clerk who sees new remittance details on a familiar vendor bill follows the independent change-control process before paying. Check invoice number, dates, tax fields, currency and reference to an authorised order, and look at underlying deliveries too, since duplicate invoices can have a new number or different formatting; price matching needs like-for-like terms, as discounts, freight, duties, tax and exchange rates may explain a difference, so when a fictional invoice lists $11 per unit rather than an agreed $10, AP checks whether the new price was approved before allowing the variance.

Quantity matching depends on unit of measure and partial deliveries, since a case of twelve is not one individual item and a supplier may bill only shipped units or, under agreed terms, bill milestones differently. A receipt should reflect what was actually accepted, because receiving staff may record damage, shortages or rejected goods and a delivery signature alone may not establish final acceptance.

Service invoices need evidence suited to the work, such as approved time sheets, completed milestones or service logs, and a goods-received note should not be invented for intangible work; a fictional facilities vendor bills ten visits, and the site manager verifies logs showing only nine completed visits before approval. Tolerances allow small authorised differences without blocking every invoice, and they should be set by value, percentage, tax and risk as appropriate.

An exception beyond tolerance should route to someone with authority rather than being silently overridden, while a fictional invoice that differs by a minor rounding amount passes under a documented policy with the approval recorded. Matching can be automated, but bad master data creates false passes or false rejects, so keep vendor, price, item and tax records current and review rules and exception trends.

An unmatched invoice can be placed on hold pending clarification, with the reason and owner communicated so suppliers do not keep resending it; a hold is not a final finding of wrongdoing. A fictional AP team asks the buyer whether an extra delivery was authorised and records the answer before release, and a fictional valid bill due Friday prompts AP to seek same-day receiving confirmation rather than letting the discrepancy sit for weeks.

Segregate responsibilities where practical, since the person requesting goods should not alone create the supplier, confirm receipt and approve payment, though smaller teams may use compensating reviews such as a fictional controller reviewing unusual vendor changes independently of the buyer who approved the order. After approval, verify what was actually paid, because a matched invoice can still be duplicated in a payment run or settled to the wrong account, so reconcile payment records and supplier statements.

A fictional finance team spots two payments against one invoice reference and investigates the bank and ledger records. Matching is a control, not a guarantee, since collusion, falsified receipts and weak approvals can defeat it, so pair it with vendor verification, audit trails and review of unusual patterns, as a fictional manager does when reviewing frequent overrides for one supplier to check whether the underlying purchase process is broken.