Automating purchase order, invoice and delivery note matching, commonly called three-way matching, with AI works by extracting structured data from all three document types using OCR or a vision-language model, then comparing them on shared fields like item, quantity, unit price and vendor to confirm the invoice reflects what was ordered and received before approving payment. AI improves on rule-based three-way matching mainly at the extraction stage, since purchase orders, invoices and delivery notes from different vendors arrive in wildly different formats, and a vision-language model or well-tuned OCR pipeline handles that variety far better than a template-based system that breaks whenever a new vendor format appears. Matching logic should tolerate reasonable variance, such as a small quantity difference from a partial delivery or a minor price rounding difference, while flagging genuine mismatches like a missing delivery note or a price beyond an acceptable tolerance. This reduces the manual effort of an accounts payable team checking each invoice line by line, and catches pricing errors or duplicate invoices before payment goes out rather than after. Integration with the company's ERP, such as SAP, closes the loop from matching to automatic posting. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds three-way matching pipelines integrated directly into a customer's ERP and finance workflow.
Where three-way matching actually breaks down today
Rule-based three-way matching systems have existed for years, but they typically break whenever a new vendor's purchase order, invoice or delivery note arrives in a format the system's templates were not configured to handle, which is a frequent event given how many different vendors a typical accounts payable department deals with. AI changes the economics of this problem specifically at the extraction stage: a vision-language model or well-tuned OCR pipeline reads the wide variety of vendor document formats far more reliably than a template-based system that requires manual configuration for every new layout.
AI's main contribution to three-way matching is handling document format variety at the extraction stage, not the matching logic itself, which was already largely solved by rule-based systems.
Matching types and tolerance design
| Match type | Documents compared | Typical use |
|---|---|---|
| Two-way match | PO and invoice | Simpler purchases without a separate delivery confirmation |
| Three-way match | PO, invoice and delivery note | Standard for physical goods purchases |
| Four-way match | PO, invoice, delivery note and inspection report | High-value or quality-critical purchases |
Matching logic needs to tolerate reasonable, expected variance rather than requiring exact agreement across every field: a small quantity difference from a partial delivery, or a minor price difference from rounding, should not block payment the way a genuine mismatch, such as a missing delivery note entirely or a price beyond an acceptable tolerance band, should.
Matching tolerance should be calibrated to distinguish normal business variance, like a partial delivery, from a genuine discrepancy worth flagging.
Designing the pipeline stages
- Extract structured data (item, quantity, unit price, vendor, dates) from the purchase order, invoice and delivery note independently, using AI extraction tuned to each document's typical format variety.
- Normalize extracted values (unit conversions, vendor name variants, currency) so comparisons are apples-to-apples across documents that may describe the same item differently.
- Apply matching logic across shared fields, using configurable tolerance thresholds per field type.
- Flag genuine mismatches (missing document, out-of-tolerance price or quantity, duplicate invoice) for accounts payable review rather than auto-approving or auto-rejecting.
- Post matched, approved invoices automatically to the ERP for payment processing.
Automating the extraction and normalization stages, while keeping genuine mismatches routed to a human reviewer, captures most of the efficiency gain without removing oversight on real discrepancies.
Catching pricing errors and duplicate invoices before payment
Beyond confirming that an order was fulfilled correctly, automated matching is well-suited to catching two specific problems before money leaves the company: a pricing error where an invoiced price does not match the agreed purchase order price, and a duplicate invoice submission, whether accidental or fraudulent, for goods already paid. Both checks are mechanical comparisons well within reach of a properly extracted and normalized dataset, and catching them before payment is both cheaper and simpler than the after-the-fact recovery process a missed instance requires.
Catching pricing errors and duplicate invoices before payment goes out is cheaper and simpler than recovering an incorrect payment after the fact.
Closing the loop with ERP integration
The value of automated matching is realized fully only when it connects directly to the company's ERP system, such as SAP, so a successfully matched and approved invoice posts automatically rather than requiring a person to manually re-key data the matching pipeline already extracted and verified. Without this integration, the pipeline still saves review time but leaves a manual data entry step in place that reintroduces both delay and transcription error risk into the process it was meant to streamline.
Integration with the ERP for automatic posting is what converts matching automation into a genuine reduction in accounts payable manual effort, not just a faster review step.
Frequently asked questions
How much manual review time does automated matching typically save?
It depends on invoice volume and vendor format variety, but the largest time savings come from documents that would otherwise require line-by-line manual comparison across all three documents; straightforward matches that pass automatically free reviewers to focus only on genuine exceptions.
What tolerance level should be used for quantity and price variance?
There is no universal answer; it should reflect the company's own business rules and risk tolerance, often set differently by vendor category, item type or purchase value, with tighter tolerances applied to high-value purchases and more flexibility allowed for routine, lower-risk categories where small variance is expected.
Can this system detect a fraudulent invoice, not just a mismatched one?
Cross-referencing extracted invoice data against purchase order and delivery records does catch a category of fraud, such as invoicing for goods never delivered, though a dedicated fraud detection layer combining forensic and pattern analysis catches additional forgery types matching logic alone would miss.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, builds three-way matching pipelines integrated directly into a customer's ERP and finance workflow, combining AI extraction with tolerance-aware matching logic and ERP posting as described above. This connects to our answer on automating invoice processing to post directly to SAP and our approach to detecting forged or tampered documents.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.