AP Automation Patterns — A Field Guide

Accounts payable automation has a well-worn shape by now: capture the invoice, extract structured data from it, match it against a PO and receipt, route it for approval, and post it — with humans only touching the exceptions. The interesting engineering is almost entirely in the exception path; the happy path where an invoice matches perfectly is the easy 60% of the problem.

Capture and extraction: OCR is the easy part now

Document AI (Google's Document AI, AWS Textract, Azure Document Intelligence) has made raw text and field extraction from PDF/image invoices commodity-level accurate. The harder problem is structured extraction — reliably mapping "Net 30" or a vendor's inconsistent line-item layout into a normalized schema the downstream matching engine can consume. Most production systems combine a general OCR/layout model with a lightweight, vendor-specific template or fine-tuned extraction step for high-volume suppliers, since a generic model's accuracy on a novel invoice layout is meaningfully lower than on a template it's seen before.

Two-way and three-way matching

Two-way match compares the invoice against the purchase order (price and quantity). Three-way match adds the goods receipt, confirming the quantity invoiced actually arrived before payment is approved — the standard control for preventing payment on goods never received. The automation design question is tolerance: an exact match requirement on price or quantity will kick almost every invoice to manual review, because rounding, partial shipments, and freight surcharges are the norm, not the exception.

def three_way_match(invoice, po, receipt):
    qty_variance = abs(invoice.qty - receipt.qty_received) / receipt.qty_received
    price_variance = abs(invoice.unit_price - po.unit_price) / po.unit_price

    if qty_variance > 0.02:   # 2% quantity tolerance
        return "review", "quantity_variance"
    if price_variance > 0.05:  # 5% price tolerance
        return "review", "price_variance"
    if invoice.qty > receipt.qty_received:
        return "review", "over_invoiced"  # never auto-approve over-billing

    return "auto_approve", None

Duplicate invoice detection

Duplicate payment is one of the most common and expensive AP failure modes, and vendors resubmitting a slightly reformatted copy of the same invoice defeats naive exact-match duplicate checks. Effective duplicate detection fuzzy-matches on vendor ID, invoice amount, and a normalized invoice date/number, and flags near-duplicates for review rather than either auto-rejecting (which can incorrectly block a legitimately resubmitted invoice) or silently paying twice.

Approval routing that reflects real authority limits

Routing rules should encode actual delegation of authority — dollar thresholds per approver role, category-based routing (a marketing invoice and a capex invoice shouldn't hit the same approver), and escalation timers so an invoice doesn't sit unapproved past a vendor's payment terms. The failure mode to avoid is a routing tree so granular that finding the right approver becomes its own bottleneck; most systems degrade gracefully with 3-4 threshold tiers rather than a rule per department.

Measuring straight-through processing rate

The single metric that tells you whether AP automation is actually working is straight-through processing (STP) rate — the percentage of invoices that go from capture to posting with zero human touches. Segment it by vendor and invoice source; a low blended STP rate usually hides a handful of problem vendors (inconsistent formats, frequent PO mismatches) dragging down an otherwise healthy rate, and fixing those few vendors moves the number more than tuning the matching engine further.

Wrapping up

AP automation succeeds or fails on the exception path, not the extraction model. Per-vendor tolerances, duplicate checks that cover paid history, and routing rules that mirror real approval authority move straight-through processing rate more reliably than a better OCR model. Track STP by vendor, not as a single blended number, and fix the worst few vendors before tuning the matching logic further.