Preventing duplicate and incorrect payments is one of the most overlooked tasks in construction finance. Every project runs hundreds of purchase orders, deliveries and supplier invoices at once, often across multiple sites and multiple subcontract tiers. When these three records are not checked against each other before payment, money leaves the business for work that was never delivered, delivered twice on paper, or billed at the wrong price.
Three-way matching is the control that closes this gap. It compares the purchase order, the goods receipt note and the supplier invoice and holds payment until all three agree.
What Three-way Matching Checks before a Payment goes out
Three-way matching works on a simple principle. A payment should only be released when three separate records confirm the same transaction: what was ordered, what was received and what was billed.
Purchase order: the price, quantity and cost code agreed with the supplier at the point of commitment.
Goods receipt note: confirmation from site or store that the material or service was received, in the quantity stated.
Supplier invoice: the amount the supplier is billing, checked line by line against the purchase order and the goods receipt note.
When all three align, payment proceeds without manual intervention. When they do not, the invoice is held and routed for review before a single payment leaves the account. This is the core discipline behind preventing duplicate and incorrect payments, and it depends on procurement, site and finance data sitting in one place rather than three, the same principle covered in our construction accounting software.
Where Duplicate and Incorrect Payments happen in Construction
The failure points generally build from ordinary gaps in a manual or semi-digital process.
- Same delivery, two invoices: a supplier resends an invoice after a delay, and the finance team, working from an inbox rather than a system, pays it twice because no record shows the first payment against that specific goods receipt note.
- Invoice ahead of delivery: an invoice is processed before the goods receipt note is logged, so payment goes out for materials that have not yet reached site, or that arrived in a lower quantity than billed.
- Split invoicing across packages: large orders get invoiced in parts and without a running match against the purchase order balance, cumulative billing quietly exceeds the agreed contract value.
- Price mismatch at line level: the invoice price differs from the agreed rate, often by a small margin per unit, and across thousands of units that difference becomes material.
- Manual override under time pressure: a finance user marks an invoice for payment without querying a mismatch, because chasing the site team for confirmation takes longer than approving.
None of these needs intent to cause a loss. They are the ordinary outcome of running purchase orders, deliveries and invoices as three disconnected records instead of one matched transaction.
With material costs and margins both under pressure across the industry, as noted in Deloitte's 2026 engineering and construction industry outlook, a payment error that once went unnoticed now eats into margin that is not there to spare.
Take a typical example:
A contractor orders 500 cubic metres of concrete at an agreed rate, delivered across four weeks in staggered loads. Two supervisors on rotating shifts each log a goods receipt note for the same Friday delivery, once on paper and once in the system, days apart. The supplier's invoice references the paper docket. Finance approves it because the total looks right against the purchase order balance, and the system copy of the same delivery sits unmatched, waiting to be billed again next month. The gap did the damage on its own.
Preventing duplicate and incorrect payments here means catching the second goods receipt note the moment it is logged, not after two invoices have already cleared the bank.
Key Steps in a Three-way Matching Process
A working three-way match follows a consistent sequence, whatever the project size or geography.
- Purchase order raised against budget: every order carries an agreed price, quantity and cost code, checked against the available project budget before issue.
- Delivery confirmed and goods receipt note logged: site or store records what was received, including partial deliveries, rejected quantities and any variance from the order.
- Invoice received and matched line by line: the supplier invoice is checked against both the purchase order and the goods receipt note, item by item, not just at the total value.
- Discrepancy identified and routed: any mismatch on price, quantity or cost code is flagged and sent to the right approver, rather than sitting in an inbox.
- Payment released only on a clean match: the invoice moves to payment once all three records agree, and the resolution of any flagged item is recorded for audit.
Skipping or manually approximating any one of these steps reopens the gap that preventing duplicate and incorrect payments is meant to close, and it is the same gap covered in our piece on cash flow management as a procurement problem.
Contractual and Practical Considerations
Three-way matching in construction has to work within how contracts and site operations run, not around them.
Partial deliveries and phased billing
Construction rarely delivers in one shipment. The matching process has to handle partial goods receipt notes against a single purchase order and reconcile them against invoices that may also arrive in parts.
Retention and certified payments
On subcontract packages, a portion of each certified payment is withheld as retention. Matching has to account for this net position, not the gross invoice value, or retention gets released by mistake.
Multi-tier subcontracts
On larger packages, a main contractor may be matching invoices from a subcontractor who is in turn matching invoices from a supplier. Each tier needs its own clean match, not a single check applied only at the top.
Tax and compliance requirements
VAT, GST and CIS deductions all change the net payable amount. A match that only checks the gross invoice value against the purchase order will approve payments that are correct on quantity and price but wrong on the amount payable.
Approval authority
Contracts often set who can approve a variance, and by how much, before an invoice can proceed despite a mismatch. This threshold needs to sit in the workflow itself, not in individual judgement.
Credit notes and corrections
When a supplier issues a credit note for an earlier overbilling, that adjustment has to flow back into the match, or the original error stays uncorrected in the ledger.
These considerations are why three-way matching cannot be treated as a simple total-value comparison. Preventing duplicate and incorrect payments at scale means matching at line-item level, across every contractual variation construction brings.
Prevention Strategies for Duplicate and Incorrect Payments
The strongest strategy for preventing duplicate and incorrect payments is structural. Remove the manual re-entry points where duplication and error creep in.
- Match automatically, not on request: build the purchase order, goods receipt note and invoice comparison into the workflow itself, so every invoice is checked by default rather than only when someone remembers to check.
- Use one linked record, not three separate ones: when the purchase order, goods receipt note and invoice all reference the same transaction inside one system, a duplicate invoice against an already-matched receipt is rejected before it reaches an approver.
- Set tolerance thresholds, not blanket blocks: small, expected variances such as rounding or minor quantity adjustments should pass automatically, while anything outside the threshold is held for review. This keeps the process fast without giving up control.
- Reconcile supplier statements on a schedule: a periodic statement reconciliation catches any invoice that slipped through outside the matching workflow, such as one submitted directly for manual payment.
- Restrict manual override permissions: only a limited, senior group should be able to approve a payment against a flagged mismatch, and every override should leave a record of who approved it and why.
- Keep an audit trail on every match and every exception: when a payment is questioned later, the record should show the purchase order, the goods receipt note, the invoice and the resolution of any variance, without anyone reconstructing it from email.
How Xpedeon Flags Duplicate and Incorrect Payments
Xpedeon’s construction accounting software enforces three-way matching between the purchase order, the goods receipt note and the supplier invoice before any payment can proceed. Any mismatch on price, quantity or cost code is flagged and routed for clarification, so an invoice never moves to payment on the strength of a manual assumption. Preventing duplicate and incorrect payments becomes a system default rather than a task someone has to remember to do at month-end.
The GRN Workbench consolidates every delivery across projects into a single view, so store teams log receipts against the correct purchase order as they happen, not days later from memory, closing the exact gap covered by construction inventory management software.
The Supply Chain Portal lets suppliers submit invoices directly against the order, reducing the chance of a duplicate invoice reaching finance through a separate channel. Every match, exception and resolution sits in one audit trail, linked to the project and cost code, so finance teams can answer a payment query in minutes rather than reconstructing it from spreadsheets and inboxes.
This works because the match happens inside the same system that raised the purchase order and recorded the budget in the first place, the model set out in our construction procurement process guide. There is no handoff between procurement and finance where a duplicate or incorrect payment can slip through unseen. For contractors managing high transaction volumes across multiple entities and geographies, this single point of control keeps cash flow forecasts and supplier relationships aligned to what has happened on site, not what a spreadsheet assumes has happened.