The purchase order is for ten items. Six arrive, but the supplier invoices all ten. The order number is correct and the unit price agrees. That still doesn't tell the finance team whether the invoice is ready to approve.
Matching invoices to purchase orders should make that difference visible. For a UK SME, a useful first workflow brings the agreed order, recorded receipt and invoice together, then gives the right person the question that needs answering. It should not turn a matching reference into permission to pay.
The example below is fictional. It explains a possible control design, rather than reporting a completed WeekFound customer result or a ready-made integration.
What is the difference between two-way and three-way matching?
Two-way matching compares invoice price information with the purchase order. Three-way matching also compares the invoiced quantity with recorded receipt evidence. A receipt might be a goods-received record; a service purchase needs its own agreed evidence of acceptance.
The exact rules depend on the system and the business's purchasing policy. Microsoft's invoice-matching documentation describes price, quantity and tolerance checks in Dynamics 365 Finance. It is a useful explanation of those distinctions, not evidence that every accounting package offers the same features.
Choose the evidence your team needs for each purchase type before choosing an automation. A PDF extraction can prepare values for checking; it cannot establish that goods arrived or that a service was accepted.
Worked example: ten ordered, six received, ten invoiced
Imagine a purchase order for ten identical units at £40 each, excluding VAT and any delivery charge. The approved order value is £400. The receiving record shows six units, worth £240 at that agreed unit price. The supplier invoice is for ten units at the same price: £400.
The £160 difference represents four units invoiced beyond the six recorded as received. A matching workflow should show the three quantities and the original documents together. It should flag the quantity difference even though the supplier, order reference and unit price agree.
That is a request for investigation, not an automatic instruction to deduct £160 or pay £240. The buyer may be waiting for another delivery, the receiving record may be incomplete, or the supplier may need to correct the invoice. Your authorised team decides the next step under the agreed purchasing terms.
Order: 10 units × £40 = £400 net.
Recorded receipt: 6 units × £40 = £240 net.
Invoice: 10 units × £40 = £400 net; quantity difference requires review.
How should the workflow handle a later delivery or another invoice?
Keep the invoice linked to the relevant order lines and receipt records. When a later receipt arrives, recheck the outstanding difference against the updated evidence. Preserve the earlier decision and the reason it was held, rather than silently overwriting them.
For split invoices, review what has already been invoiced and matched against that order. Comparing every new invoice with the original order in isolation can hide an over-allocation. A repeated upload should point to the existing invoice record, not create a second posting opportunity.
An invoice number alone may be insufficient for duplicate checks. Agree how the supplier identity, document reference and source record distinguish a repeat from a corrected invoice or credit note. An ambiguous case belongs in the review queue.
What if the price, pack size or extra charge is different?
Make the comparison like for like. Ten boxes and ten individual items may use the same description but represent different quantities. Keep the unit of measure, currency, line price, discount and separately agreed charges visible beside the original source.
The finance or purchasing owner should define any allowed rounding or price tolerance. An illustrative tolerance in a software manual is not your company's approval policy. Show the actual difference and which rule was applied so a reviewer can understand a pass as well as a failure.
Treat missing information as missing. A blank receipt is not proof of delivery, and an unreadable amount should not become zero. The same principle applies when an export is stale or a connection fails: record the check as incomplete and route it for attention.
What should a person see before approving anything?
Give the reviewer the supplier, invoice, order line, relevant receipt evidence, any previous allocation and the precise reason for the hold. Name an owner and keep a visible queue of unresolved cases. A generic 'match failed' email just moves the searching to another person.
The next action should be clear: confirm a receipt, ask the buyer about a price change, request a corrected document or approve a documented exception. Record who decided, when, and which evidence they used. Do not treat a match status as permission to change supplier bank details or release payment.
This is one part of finance workflow automation. Document preparation, review, accounting entry and payment authority need their own agreed boundaries.
Can we do this around the accounting tools we already use?
Start by checking the actual invoice, purchasing and receiving records your systems can provide. Supported exports may be enough for a first comparison; live updates or accounting writes need verified access and permission. A familiar software logo is not proof that every required field or action is available.
WeekFound's purchase invoice and PO matching study sets out a proposed end-to-end workflow. This guide focuses on the narrower decision inside it: what happens when the invoice and recorded delivery disagree. The study is a proposal, not a measured customer result.
Keep the current manual process available while testing. If the automation is paused or a source is unavailable, a person should be able to inspect the same documents, complete the check and record what they did without creating a duplicate entry later.
What should a first test prove?
Use a small set of synthetic or anonymised examples, including a clean match and awkward cases. Agree the expected outcome with the finance owner before running the workflow. Test a partial delivery, a repeated invoice, a corrected document, a price difference, missing receipt evidence and an unavailable source.
Check that each case reaches the right queue with a useful explanation. If an approved accounting entry is in scope, test an uncertain response from the accounting system and reconcile whether the entry already exists before any retry. A timed-out screen is not proof that nothing was saved.
Measure the full work: preparation, review, document chasing and corrections, plus incorrect matches and unresolved exceptions. The aim is less repeated searching with the right controls preserved. The first automation checklist can help define a manageable starting scope.