Three-way match automation

Three-way match automation compares a purchase order (PO), a goods receipt (GR), and a supplier invoice before accounts payable (AP) releases payment. The model reconciles line items, quantities, unit prices, taxes, and totals across those three sources, then surfaces mismatches for human review.

For an AP controller, the job stays familiar: confirm that what was ordered was received and that the invoice reflects both. Automation shortens the time spent lining up PDFs, ERP screens, and email attachments. It does not replace the approval step. The model flags discrepancies and proposes a disposition; AP still decides whether payment can proceed.

The workflow typically starts once all three documents are available in the procurement or ERP stack (for example Coupa or SAP). Structured records from the PO and GR often sit in system tables. Invoices may arrive as EDI, PDF, scanned paper, or portal uploads. Related preprocessing such as invoice data extraction can normalize invoice fields before matching runs.

Matching is field-level and line-level, not a single total check. The model aligns PO lines to GR lines (what was received against what was ordered), then aligns those results to invoice lines (what the supplier billed). Common comparison points include SKU or material number, description, quantity, unit of measure, unit price, currency, tax, freight or other charges, and invoice total versus PO remaining balance.

Structured sources are usually reliable for identifiers and quantities. Unstructured invoices introduce OCR and layout risk: misread decimals, wrong currency symbols, or charges buried in free-text notes. The model should treat extracted invoice values as candidate fields with confidence signals, not as authoritative ERP truth. When confidence is low on a material field, the safer path is an exception, not a silent pass.

Tolerance rules belong to finance policy, not to the model. Many organizations allow small quantity or price variances within defined thresholds, and treat tax or freight differences separately from merchandise lines. Automation applies those rules consistently: within tolerance can pass with a clear audit note; outside tolerance becomes a flagged exception with the delta, the fields involved, and links to the source documents.

Cross-format matching also means handling partial receipts and multi-invoice POs. A single PO may have several GRs and invoices over time. The model should match against open quantities and remaining amounts, not assume a one-to-one document set. Duplicate invoice detection (same supplier invoice number, amount, and date against an already-posted document) belongs in the same control path.

When documents disagree, the model should classify the exception rather than dump a generic “mismatch” queue. Useful categories for AP include quantity short or over versus GR, unit price variance versus PO, tax or VAT discrepancy, missing or unexpected freight, wrong PO or vendor reference, unit-of-measure conversion issues, and duplicate invoice suspects.

Routing follows ownership. Price disputes often go to procurement or the buyer. Quantity issues go to receiving or the warehouse. Tax questions go to tax or AP specialists. Duplicate or reference errors stay with AP. Each routed item should carry the three document IDs, the mismatched fields, the computed deltas, and a short plain-language summary so the assignee does not reopen three systems to understand the problem.

Human-in-the-loop is mandatory for payment release. The model proposes a match status (matched, matched within tolerance, or exception) and may suggest a next action, such as request credit memo, wait for remaining receipt, or correct coding. An AP controller or designated approver confirms or overrides that proposal before the invoice moves to payment scheduling. Nothing in this flow should auto-pay, auto-post a payment run, or bypass approval workflows already configured in Coupa, SAP, or the AP payment system.

Auditability matters as much as speed. Retain which fields were compared, which tolerance rules applied, who approved the exception outcome, and timestamps for match, flag, and approval. That trail supports month-end review and vendor disputes without reconstructing the logic from chatty model output.

Empty output is a control, not a failure mode to paper over. If the PO is missing, the goods receipt is missing, or the invoice is missing (or cannot be resolved to a usable record), the model should return no match result and no suggested payment disposition. Partial evidence is not a three-way match.

Missing PO: do not invent a PO from invoice free text. Hold for procurement to provide the correct order reference or to handle a non-PO invoice under a separate policy. Missing GR: do not treat invoice quantity as proof of receipt. Hold until receiving posts the receipt or AP confirms a documented exception process for services or receipts-not-required cases. Missing or unreadable invoice: do not match against a stub or a best-guess OCR blob; request a clean invoice or a successful re-extraction first.

The same empty-output rule applies when identity resolution fails: invoice vendor does not map to the PO vendor, PO number on the invoice does not exist, or GR cannot be tied to the PO lines claimed. Guessing the “closest” document set creates false positives that are harder to unwind than a clear incomplete status.

Downstream systems should treat empty output as “not ready for match,” not as “matched with zero variance.” Payment systems must not interpret silence as approval.

Day-to-day, the queue should skew toward exceptions that need judgment: freight disputes, partial deliveries, blanket PO draws, and tax coding edge cases. Clean three-way matches should pass through with a visible matched status and still require the normal AP approval step before payment. Controllers should spot-check samples of auto-flagged “within tolerance” items to confirm tolerances still match policy.

Integration expectations are practical. In Coupa or SAP landscapes, PO and GR data usually come from the system of record via API, IDoc, or approved export. Invoices may enter through the same suite’s invoice module or from an upstream capture step. The matching job should write status and exception codes back to that system so buyers and receivers work in tools they already use, not in a parallel spreadsheet.

Success looks like fewer hours spent on line-by-line spreadsheet reconciliations, faster cycle time on clean invoices, and a smaller, better-labeled exception queue. Success does not look like unsupervised payment. Keep the model’s role to comparison, discrepancy detection, and routing. Keep AP’s role to approval, vendor communication, and final payment authorization.