Two-way matching automation for the invoice-to-PO checks AP keeps rebuilding.

Two-way matching sounds simple: compare the vendor invoice with the purchase order and decide whether the invoice can move forward. In practice, AP teams still spend time rebuilding context because the invoice, PO, vendor record, approval history, policy notes, and ERP status often live in different places. A purchase order may exist but be closed, changed, partially used, assigned to the wrong entity, or missing the line context AP needs to evaluate the invoice.

The workflow becomes slower when exceptions are not separated early. A clean invoice-to-PO match should not sit in the same queue as a missing-PO invoice, a duplicate-looking invoice, a vendor record conflict, or a policy exception. When those cases are mixed together, AP has to inspect every invoice like it might be risky, and procurement or requester follow-up starts from scratch each time.

The useful automation target is not blind straight-through posting. It is the repeatable evidence work before a finance decision: collect the invoice and PO context, check whether the packet satisfies the approved rule, identify the specific mismatch reason when it does not, and route the packet to the owner who can resolve the gap.

• The invoice references a PO, but the PO status, amount, line, vendor, or entity context does not line up cleanly.
• The PO exists in procurement or ERP, but AP still has to chase context from requesters, approvers, or vendor-facing owners.
• A tolerance rule may apply, but the source evidence needed to apply it is scattered across systems.
• A mismatch should become a structured packet, not another email thread with copied invoice screenshots.

Bring a small set of real examples rather than a polished process diagram. Useful evidence includes invoice samples, matching purchase orders, missing-PO cases, changed or closed PO cases, vendor record issues, amount variance examples, duplicate-looking invoices, and the current notes AP uses to decide whether an invoice can move.

The strongest audit examples include both clean and blocked paths. Clean paths show which fields and evidence make AP comfortable. Blocked paths show the exception categories that need routing: missing PO, wrong PO, amount variance, vendor mismatch, entity issue, duplicate concern, unclear requester, or policy question. Those categories become the first workflow map.

The audit should leave the team with a concrete decision: whether two-way matching is the right first workflow, whether the bottleneck is actually broader PO matching, or whether invoice exceptions, approvals, or upstream purchase-order hygiene should come first. That decision matters because it keeps the first automation narrow enough to launch and review.

If the pilot moves forward, the same audit map becomes the implementation boundary. It defines the systems to read, the packets to prepare, the exceptions to route, the decisions humans keep, and the completed unit that makes outcome pricing measurable.

It also gives finance a cleaner way to compare work before and after launch. Instead of debating whether matching feels better, the team can inspect how many packets were prepared, where exceptions went, and which unresolved categories still consume human time across vendors, entities, invoice streams, and recurring requester handoffs during later close and payment preparation reviews.

• Bring current matching rules, tolerance notes, and the situations AP refuses to automate.
• Bring examples from the systems AP actually opens while matching, not only the ERP record.
• Bring owner rules for procurement, requester, vendor-facing, finance, and controller review.
• Bring the downstream handoff AP expects after a clean match or unresolved mismatch.