What Is Three-Way Matching? A Definitional Guide for AP Teams (and How to Automate It)

Three-way matching is an accounts payable control that verifies a vendor invoice against the corresponding purchase order (PO) and goods receipt note (GRN) before payment is released. The point is simple. Pay only for goods or services the company actually ordered, received, and agreed to pay for. It's also one of the strongest defenses AP teams have against duplicate payments, phantom-vendor schemes, and billing fraud, which together account for a meaningful share of every occupational fraud study published in the last decade.

Key Takeaways

• Three-way matching compares three documents (the purchase order, the goods receipt note (GRN), and the vendor invoice) and only releases payment when they agree within tolerance.

• It is primarily a fraud and overpayment control, not a process-efficiency play. The financial-risk avoidance is where it earns its cost.

• Two-way matching skips the GRN; four-way adds an inspection step. Three-way is the practical sweet spot for most mid-market and enterprise AP teams handling physical goods.

• Tolerance configuration is where this control gets opinionated. Set thresholds too tight and you choke on legitimate variances; too loose and the control becomes theatrical.

• The integration that matters isn't the matching engine. What separates working implementations is how the platform handles missing POs, partial receipts, and price variances across your specific ERP environment.

What is three-way matching in accounts payable?

Three-way matching in accounts payable is the verification step that compares a vendor invoice against the original purchase order and the proof of receipt (the GRN) before AP releases payment. The control predates AP automation by decades. Buyers used to do it on paper, stapling the three documents together in a folder and checking that they agreed before cutting the check. The mechanics haven't changed; the speed and accuracy have.

The point of the control is to prevent payment for anything that wasn't ordered, wasn't received, or wasn't priced as agreed. Each of those failure modes shows up in real AP operations regularly. About 8.5% of received invoices are duplicates in OpenEnvoy's industry study, a rate high enough that catching them at the matching step pays for the AP platform on its own.

What are the three documents in three-way matching?

The three documents are the purchase order (issued by procurement to the vendor, establishing what's being bought, in what quantity, and at what price), the goods receipt note (captured by the receiving team when materials arrive, confirming quantity and condition), and the vendor invoice (sent by the supplier after delivery, requesting payment). When the line items on all three agree within tolerance, the invoice is approved automatically. When they disagree, AP routes the exception for review.

Who is responsible for performing the three-way match?

Ownership is distributed by design. Procurement issues the PO and owns its accuracy. The receiving team captures the GRN at delivery. AP captures the vendor invoice, runs the comparison, and routes exceptions. In automated environments, the matching itself happens in the platform; the human work shifts to exception handling. The cleanest implementations make exception ownership explicit at design time rather than letting it default to whoever's email the exception lands in.

How does 2-way vs. 3-way vs. 4-way matching compare?

The three matching depths trade control for cycle time. Two-way is fastest but weakest. Three-way is the practical default for any AP team handling physical goods. Four-way adds the slowest control with the strongest assurance for high-value or regulated purchases.

The honest answer to "which one should we use?" is "it depends on what you're buying." A SaaS subscription doesn't need a GRN. A pallet of stainless steel does. Most mid-market AP departments end up with a mixed-mode workflow: two-way for services, three-way for goods, four-way for the handful of capital purchases where the inspection layer earns its delay.

When should you use 2-way matching instead?

Two-way matching makes sense when the goods receipt isn't a meaningful control point. Service-only spend, recurring software subscriptions, professional services retainers, and utility bills don't benefit from a GRN check because there's nothing to physically receive. Forcing three-way matching on those categories creates exception noise without adding fraud protection.

When does 4-way matching make sense?

Four-way matching adds an inspection step between receipt and approval. The inspector confirms not just that the right quantity arrived but that what arrived meets specification. The control matters most in pharmaceutical manufacturing (where excipient identity testing is non-negotiable), aerospace (where capital equipment must meet engineering specs), and any regulated industry where post-payment defects are expensive. Most general-purpose AP operations do not need four-way matching, and adding it where it isn't required slows the cycle without buying meaningful additional fraud protection.

How does three-way matching work step by step?

The full sequence runs in six stages. In a manual environment, each stage is a separate human action. In an automated environment, most of the work happens inside the AP platform, and humans only touch the exceptions.

1. Procurement issues a purchase order to the vendor, establishing quantity, unit price, line items, delivery terms, and a PO reference number.

2. The vendor delivers the goods or services; the receiving team captures a GRN documenting what arrived and when.

3. The vendor submits the invoice referencing the PO number.

4. AP captures the invoice through OCR, vendor portal, or EDI feed, and the AP system extracts header and line-item data.

5. The platform matches line items across all three documents (vendor name, PO number, quantity, unit price, line total, delivery terms) against the configured tolerance.

6. If everything agrees within tolerance, the invoice routes for approval and payment. If anything mismatches outside tolerance, the invoice is flagged as an exception.

What data points actually get matched?

The platform looks at vendor name (matching against the master file, not just string equality), PO number, line-item description, quantity, unit price, extended line total, freight charges, taxes, and delivery terms. Quantity and unit price are the fields that matter most for fraud prevention. False-positive exceptions tend to come from freight and taxes — small variances driven by the carrier's rate card or local tax calculation. The match isn't a checksum on the documents. It's a field-level comparison.

The depth of three-way matching integration with the broader AP workflow is what determines whether the control adds or removes work. A platform that does field-level matching but can't reconcile partial receipts or change orders pushes that work back to AP staff, defeating the point. The platforms that work well in production handle those edge cases at the matching layer.

See how Corpay handles three-way matching exceptions. Schedule a demo with your real POs, your real receipts, and your real invoices. The exception handling is what separates working integrations from logo-wall claims.

How do you configure tolerances and handle common exceptions?

This is the practitioner H2 most vendor content skips. Tolerance configuration is where three-way matching either creates a clean exception queue or generates noise the AP team learns to ignore.

The common exception scenarios fall into a few patterns:

• Quantity variance. Invoice quantity doesn't equal received quantity. Could be overshipment, partial receipt waiting on a back-order, or a unit-of-measure mismatch (case vs. each).

• Price variance. Invoice unit price differs from PO unit price. Often legitimate, especially when a contract escalator, FX movement, or verbal price change wasn't captured as a formal change order.

• Missing PO reference. The invoice has no PO number, or references a PO that doesn't exist in the system. Could be fraud, could be a legitimate purchase that bypassed procurement.

• Multi-PO invoice. A single invoice covers line items from several POs. Most basic matching engines choke on this; mature platforms handle it natively.

• Partial receipt. GRN reflects a partial delivery; the invoice covers the whole quantity. Has to wait for the rest or get split into two invoices.

Tolerance configuration handles the variance cases. The two dimensions are absolute (a flat dollar amount) and percentage (a portion of the line). Most teams set both, with a tighter percentage on high-dollar lines and a looser absolute on low-dollar lines. Approval routing on exceptions is the next call. Do you auto-approve anything within tolerance, or always route to a human for high-dollar lines regardless? The right answer depends on volume, dollar exposure, and how much exception capacity AP has.

What is a tolerance setting in three-way matching?

A tolerance setting is the configurable threshold that determines when a variance triggers an exception versus auto-approves. Tolerances can be set as an absolute dollar amount, a percentage of the line, or both. They can apply at the line-item level or to the invoice total. Setting tolerances too tight produces an exception queue the AP team can't clear; setting them too loose defeats the control's purpose. The sweet spot is usually 2-5% or $50, whichever is greater, with separate handling for invoices above a configured dollar threshold.

Who should own exception resolution?

Exception ownership is the question Reddit threads on AP automation keep coming back to, and most vendor content avoids. The honest answer is that ownership depends on the exception type. Price variances usually belong to procurement (they negotiated the PO). Quantity variances belong to receiving (they captured the GRN). Missing-PO exceptions usually belong to the requisitioner (they're the one who needed the thing). AP's job is to route correctly and follow up, not to resolve every variance themselves. When ownership defaults to AP because no one else picks up the work, the queue grows until the control loses credibility.

How does three-way matching prevent fraud?

Three-way matching is the AP control that breaks several common fraud patterns at the same time. Looking at the accounts payable fraud guide or any of the ACFE annual reports, billing schemes appear in 86% of asset misappropriation fraud cases. Median loss per occupational fraud case sits around $145,000 per the Association of Certified Fraud Examiners' 2024 Report to the Nations. Typical organizations lose around 5% of revenue to fraud annually.

The mechanics of how three-way matching breaks the most common schemes:

• Phantom-vendor schemes require an invoice for goods that were never ordered. No PO exists, so a three-way match fails immediately at step 5.

• Duplicate invoice fraud submits the same invoice twice (or three times) hoping AP misses one. Duplicate detection at capture, layered on top of three-way matching, catches both the duplicate and the manipulation.

• Inflated invoice schemes charge more than the PO authorized. Price variance outside tolerance flags the exception.

• Quantity manipulation invoices for more units than were received. The GRN comparison catches this at step 5.

There's a fraud surface three-way matching does not catch: collusion between procurement and vendors, where the PO itself is inflated. That class of fraud needs upstream controls like vendor onboarding due diligence, separation of duties between requisition and approval, and periodic spend audits. Three-way matching plays well with those upstream controls but isn't a replacement for them.

You'll also see payments-fraud prevalence numbers cited from the Association for Financial Professionals (AFP) 2026 Payments Fraud and Control Survey: 76% of organizations reported attempted or actual payments fraud in 2025, up from 79% in 2024. The number's persistent, and it's the macro context that makes three-way matching worth getting right.

How does three-way matching work across NetSuite, Sage Intacct, and other ERPs?

This is the H2 most generic AP-automation content papers over. Every platform claims "ERP integration." The differences show up in how the matching engine actually behaves inside specific ERPs, particularly the vertical ERPs that handle construction, manufacturing, and project-based work.

The full list of finance and accounting systems Corpay supports, alphabetically:

• Acumatica

• CMiC

• Computer Guidance / eCMS

• Microsoft Dynamics 365 Business Central

• NetSuite

• Oracle

• QuickBooks

• Sage 100 Contractor

• Sage 300 CRE

• Sage Intacct

• SAP

• Viewpoint Vista

• Xero

That's 180+ ERP integrations in total. Acumatica, CMiC, and the construction-specific Sage editions are the systems where most competing AP platforms cut corners. They'll show the logo on a marketing page; they won't write line-item coding back into the ERP without manual re-keying.

How does three-way matching work in NetSuite?

NetSuite has native PO and GRN tables, and the basic matching workflow runs inside NetSuite itself. The limitation is exception handling. NetSuite's native matching is rigid on tolerances and weak on automated exception routing. AP automation platforms layer on top, ingesting POs and GRNs from NetSuite and handling the exception workflow externally before pushing approved invoices back. The full integration story for Corpay's NetSuite connector is detailed in the AP automation software guide.

How does three-way matching work in Sage Intacct?

Sage Intacct's matching depth depends on which edition and modules are deployed. The standard Sage Intacct edition handles two-way and three-way matching for invoices against POs and GRNs. The Construction edition adds AIA pay-app handling, retainage, and lien-waiver controls that bolt onto the matching workflow. Corpay's Sage Intacct AP automation integration covers both, with the exception layer running outside Intacct so the AP team doesn't get every variance back in their queue.

How does three-way matching work in Acumatica?

Acumatica's matching is solid out of the box, better than most generalist ERPs would suggest. The Construction Edition adds project-based PO handling, retainage tracking, and certified payroll integration. Acumatica is also where competing AP platforms most consistently fall short. Many claim integration but lack working line-item write-back. Corpay covers both the standard and construction editions with full ERP-native depth.

How does three-way matching work in Microsoft Dynamics 365 Business Central?

Dynamics 365 handles three-way matching natively, with configurable tolerances at the PO and item level. The integration question is whether your AP platform pushes coded invoices back to Dynamics with full cost-center allocation, or whether the AP clerk has to re-enter coding manually. Working integrations write back everything (exception routing, tolerance overrides, approval audit trail) without a clerk in the middle.

How do you automate three-way matching with Corpay?

Corpay's AP automation platform handles three-way matching across the full configurable surface area: 2-way and 3-way matching modes, line-item tolerance configuration, multi-PO invoice handling, partial-receipt support, and managed exception workflow. AI-OCR captures invoices with field-level accuracy modern AP analysts now expect. ERP integrations cover the full list, including Acumatica, NetSuite, Sage Intacct (standard and Construction), Microsoft Dynamics 365, SAP, and the construction-vertical ERPs (CMiC, eCMS, Viewpoint Vista) most AP platforms skip.

The differentiator most AP teams care about once they're past the pilot is the managed-service layer. Corpay handles supplier-side payment delivery, virtual card enablement, ACH remittance, and exception follow-up instead of handing those problems back to your team. For deeper coverage of the broader workflow, see the 4 most critical AP automation workflows and the AP automation best practices guides.

Corpay's AP automation platform is SOC 2 Type II compliant. Customers include 800,000+ businesses across mid-market and enterprise.

To see the platform, the Invoice Automation product page walks through capture, matching, and approval. The PO Automation page covers the upstream procurement integration. The AP Automation hub covers the broader managed-AP story. And the matching control connects directly to the AP request-for-proposal evaluation framework when you're building a vendor shortlist.

Ready to talk to a specialist? Schedule a consultation with the Corpay AP team to walk through your matching tolerances, exception workflow, and ERP integration depth. Those are the three places implementations actually stick or fail.

Frequently asked questions

What is three-way matching in accounts payable?

Three-way matching is an AP control that verifies a vendor invoice against the purchase order and goods receipt note before payment is released. The control prevents payment for anything that wasn't ordered, wasn't received, or wasn't priced as agreed.

What documents are required for a three-way match?

Three documents: the purchase order (PO) issued by procurement to the vendor, the goods receipt note (GRN) captured by receiving when goods arrive, and the vendor invoice submitted for payment. The match compares line-item data (quantity, unit price, line total) across all three.

What is the difference between two-way and three-way invoice matching?

Two-way matching compares the invoice against the PO only. Three-way adds the goods receipt note, which catches receiving-side discrepancies (under-shipments, partial receipts, quantity errors) that a two-way match misses. Three-way is the practical default for physical goods; two-way is appropriate for services and low-risk recurring spend.

Who is responsible for performing the three-way match?

Responsibility is shared by design. Procurement owns the PO and its accuracy. The receiving team captures the GRN. AP captures the invoice and runs the comparison. In manual environments, the AP clerk physically reconciles all three. In automated environments, the platform performs the match and AP handles exceptions.

How do you automate three-way matching?

Automated three-way matching requires three things: an AP capture layer (AI-OCR or vendor portal) that ingests invoices, an ERP integration that pulls PO and GRN data continuously, and a matching engine that compares line items within configured tolerances. Exceptions route to a human reviewer; matches auto-approve. The cleanest implementations integrate matching with the broader AP workflow detailed in the refreshed invoice processing automation guide.

What is a tolerance setting in three-way matching?

A tolerance setting is the configurable threshold that determines when a variance triggers an exception versus auto-approves. Tolerances can be absolute (a flat dollar amount), percentage-based, or both. Most teams configure tolerances per line and per invoice total, with tighter thresholds on high-dollar transactions.

What is four-way matching, and when do I need it?

Four-way matching adds an inspection step to three-way matching. The inspector confirms not just that the right quantity arrived but that the goods meet specification. Most general-purpose AP departments don't need four-way matching. Pharmaceutical manufacturing, aerospace, and other regulated industries with high-cost post-payment defect risk are where it earns its delay.

How does three-way matching work in SAP?

SAP handles three-way matching through the goods receipt / invoice receipt (GR/IR) account concept. POs generate commitments; GRNs post against the receipt side; invoices post against the invoice side. The match clears the GR/IR account when all three agree. AP automation platforms that integrate with SAP work alongside this native flow, handling exception routing and approval workflow externally before posting cleared invoices back. Corpay enables three-way matching across all 180+ ERP integrations, SAP included.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

AP Automation