Get a personalized demo of Stuut and see how it can help with AR automation.
Three-way matching runs inside your customers' AP departments, but when it breaks, your AR team absorbs the impact. Partial shipments, unstructured PDF invoices, and bulk wire payments with emailed remittance details cause AP holds that stall payment on your invoices, leaving your team to chase resolution across email threads, customer portals, and AP contacts. Manual cash application and reconciliation consume substantial analyst time just linking payments to email remittances and managing the month-end close process.
Understanding how three-way match works, where it fails, and how AI handles the exceptions makes the difference between a team buried in spreadsheets and one focused on disputes, relationships, and complex decisions.
A three-way match is an accounts payable control that compares three documents to confirm a payment request is legitimate and accurate before funds leave the company. By requiring evidence of an approved order and a confirmed delivery, the process is designed to protect against fraudulent invoices and overpayments.
Three documents must align before payment is approved:
Three-way matching is designed to protect cash flow in three specific ways. First, it aims to block fraudulent invoices by requiring documented proof of both an approved order and a confirmed delivery. Second, it seeks to ensure payment amounts align with contracted terms, catching pricing errors before they leave your account. Third, it produces audit-ready documentation that finance teams rely on during close.
For your AR team, a failed match inside your customer's AP department means your invoice sits unpaid. That delay shows up in your aging buckets and DSO every day the exception goes unresolved.
The procurement team creates a PO specifying the goods or services required, agreed quantities, unit prices, and delivery dates, then sends it to the vendor. This document serves as a key reference for subsequent verification steps in the matching process.
When the shipment arrives, the receiving department inspects the delivery and records quantities, condition, and any variances from the PO in a receiving report (also called a goods receipt note). This step is a key distinguishing factor of a three-way match and provides protection against paying for goods that never arrived.
The supplier sends an invoice to accounts payable after fulfilling the order. AP logs the invoice and pulls the corresponding PO and receiving report for comparison. Formatting inconsistencies, missing PO references, or unstructured PDF data create friction at this stage before the match even begins.
AP cross-references all three documents, checking that items, quantities, unit prices, and totals align. If everything matches within approved tolerance thresholds (tolerance levels vary by organization), payment is released. If not, AP flags the discrepancy for manual research. The same unstructured-data problem that breaks this match (PDF invoices, emailed remittance, bulk wires) is exactly what breaks cash application on the AR side, where your team applies incoming payments to open invoices.
Most match failures come from four clerical sources, not disputes or bad faith.
The unit price on the invoice doesn't match the agreed price in the PO. This can occur when pricing updates are not synchronized between systems, creating variances that trigger exception flags and block automated matching.
A supplier ships a partial order but invoices for the full quantity, or ships more than ordered. The receiving report captures the actual quantity delivered, creating conflicting numbers that break the match. These mismatches occur frequently in manufacturing and distribution where split shipments are common.
If the receiving report is delayed or never entered into the ERP, AP may lack the documentation needed to complete the match. Payment can get held waiting for proof of delivery (POD) that may exist physically but hasn't been digitized, stalling cash application indefinitely.
An invoice that references an incorrect item code or no PO number at all creates significant matching challenges. Without a valid PO reference, the entire verification chain breaks and the exception requires manual research to trace the originating order.
When a three-way match fails inside your customer's AP department, their team holds the invoice pending resolution. Your AR analyst then contacts your customer's AP contact, logs into procurement portals like Ariba or Coupa to check invoice status, and coordinates with your own sales or shipping teams to provide missing documentation. This detective work is AP's process to complete, but your AR team drives it from the supplier side. The AR-side matching problem your team owns is cash application: when a customer sends a bulk wire covering multiple invoices with remittance detail by email, your analyst must parse the bank file against the email to apply each payment to the correct open invoice. A single misread remittance leaves cash unapplied for days, which pushes DSO higher and delays month-end close.
Delayed cash application also pushes DSO higher and impacts working capital reporting, creating an effect on cash flow that AR Directors flag in board-level reporting.
Resolving exceptions may require AR to coordinate with other departments such as sales, shipping, or procurement to validate pricing, delivery, or PO details. This cross-functional coordination slows resolution further and delays DSO reduction even when the root cause is a minor clerical error.
Three-way matching mechanics work smoothly when you have clean, structured data. The problem is that most of it isn't.
ERPs typically expect structured data entry fields, not flat PDF images. When a supplier sends an invoice as a scanned PDF, rule-based extraction systems may struggle with varying layouts across a multi-supplier portfolio, requiring manual entry that slows the entire matching process. Modern AI tools using large language models handle diverse formats without fixed templates, but most legacy AR workflows haven't adopted them.
When a customer pays a bulk wire covering multiple invoices and sends remittance detail by email, your team faces a matching problem that can be difficult to solve. Parsing bank files against email text to identify which invoices a payment covers often runs manually for teams, and a single misread remittance leaves a payment in unapplied cash for days.
Some large buyers require suppliers to submit invoices through procurement portals like Ariba or Coupa rather than by email. These portals often enforce specific formatting requirements, and invoices may be rejected when line item codes or PO references don't match the buyer's system exactly. This creates a second queue of manual work that collections teams handle daily, on top of the standard cash application process.
A primary cause of cash application delays is unstructured input data. AI-native platforms address this at the source by reading documents the way humans do, not the way rule engines require.
Stuut reads remittance data from bank accounts, lockboxes, and digital payment rails. While rule-based systems require a structured field map for every supplier format, machine learning models can extract information from diverse layouts by learning patterns across documents. When a payment arrives with no remittance detail, Stuut contacts the customer directly to request it, automating a step that typically requires manual follow-up. For AR teams processing high payment volumes, that means fewer unapplied cash items sitting in the queue and a shorter path to month-end close.
For AR teams, the equivalent matching problem is applying incoming payments to the right open invoices. Stuut's proprietary three-way matching algorithm handles exact matches, partial payments, overpayments, and bulk deposits. It can break a single large deposit covering many payments into individual sub-payments and match each one to the correct invoice, targeting a 95%+ automated cash application rate across standard deployments. Rule-based systems require a structured field map for every supplier and remittance format, which is where they stall. Stuut's learning approach avoids that per-format setup, reducing the manual backlog your team carries into month-end close.
When Stuut encounters a complex payment that requires additional verification, it flags the exception for human review rather than processing it automatically. Your team sees a dashboard showing only the matches that require judgment, shifting the role from data entry to decision-making. That shift means your analysts spend time on payment plans, complex disputes, and strategic relationships rather than moving line items between columns.
Every payment Stuut processes can train the system. It stores metadata beyond what ERPs typically capture, including bank transaction identifiers, originating company numbers, and remittance parsing patterns, so future payments from the same source can match more quickly. In practice, a payment source that required manual research in week one typically matches automatically within a few weeks as the system builds pattern confidence on that customer.
Bishop Lifting, an industrial equipment company, reduced overdue receivables by 35% and unlocked $3M in working capital after deploying Stuut. Stuut automated 91% of Bishop Lifting's outbound communications and their team now manages significantly more accounts without adding headcount.
Stuut connects via API to SAP, Oracle, NetSuite, and Dynamics in 3 to 4 days for standard environments without modifying your chart of accounts or GL configuration. Complex multi-entity payments may still need human review, but most customers see a significant reduction in manual workload within the first weeks of deployment.
Book a demo with the team to see how Stuut matches payments in a live environment, or review how Bishop Lifting reduced overdue receivables by 35% with autonomous collections and cash application.
A two-way match typically compares the purchase order and the vendor invoice, verifying quantities and prices. A three-way match adds the receiving report as a third document, providing evidence of actual receipt before payment is approved, which is designed to be more reliable for preventing overpayments and fraud in physical goods industries.
When a customer's AP department holds an invoice due to a PO, receiving report, or price discrepancy, your AR team contacts the customer's AP contact, provides supporting documentation, and coordinates internally with sales or shipping to resolve the mismatch. The AR-side equivalent is cash application, which means applying incoming payments to the correct open invoices. AR analysts handle cash application exceptions by cross-referencing bank files and email remittance. AI-native platforms like Stuut handle structured cash application exceptions autonomously and route only complex cases to human review, reducing the manual research load that consumes most of an analyst's day.
Manual exception research can take considerable time depending on complexity and how many parties need to be contacted. Stuut's self-learning AI matches payments automatically and can proactively contact customers when remittance is missing, and Razvan Bratu, Head of Quote to Cash at Honeywell, reported collecting faster from in-scope customers as the platform freed his team to focus on high-value account management while autonomous collections handled routine follow-up.
A three-way match compares item descriptions, quantities, unit prices, and totals across the purchase order, receiving report, and supplier invoice. All three documents must agree within your organization's approved tolerance before payment is authorized.
ERPs expect structured data entry fields, not flat PDF images or email text. When invoices arrive as scanned PDFs, rule-based systems fail to extract the data needed for automated matching, forcing manual entry and creating the reconciliation backlog that delays cash application. AI-powered extraction handles variable formats without templates.
Purchase order (PO): A buyer-generated document sent to a supplier specifying goods or services requested, agreed quantities, unit prices, and payment terms. It serves as the contractual baseline for the three-way match.
Remittance: Payment detail information that accompanies a payment, identifying which invoices the funds should be applied to. Remittance data arrives through bank files, email, lockboxes, or digital payment platforms and is the primary input for cash application.
Cash application: The process of matching incoming payments to open invoices and posting entries to the AR subledger and general ledger. When cash application is delayed or inaccurate, DSO rises and working capital reporting becomes unreliable.
Subledger: The detailed AR record that tracks individual customer balances and invoice-level transactions. The subledger typically feeds into the general ledger (GL) and must be reconciled accurately before month-end close can complete.
Days Sales Outstanding (DSO): A measure of how long it takes to collect payment after a sale. A high DSO signals cash trapped in the AR process, often caused by unresolved match exceptions and slow cash application.
Exception: Any payment or invoice that fails automated matching and requires manual investigation. Price variances, quantity mismatches, missing PO numbers, or unstructured remittance data generate exceptions and drive the primary workload for AR analysts managing cash application queues.
