Purchase Order Matching: Automate Three-Way Match

Three-way match is one of those processes every accounts payable team knows they should tighten up — and almost nobody has fully automated. The gap between a purchase order, an invoice, and a goods receipt note lives in three separate documents, often in three different formats, and reconciling them by hand is exactly the kind of work that breaks at scale. This post walks through how purchase order matching automation actually works, where the friction lives, and how to use Papersnap to extract the right fields from all three documents so comparison becomes a spreadsheet formula, not a manual hunt.

What three-way match actually checks

The concept is straightforward: before you pay an invoice, you verify that three documents agree.

1. Purchase Order (PO) — what you agreed to buy, at what price, in what quantity.
2. Supplier Invoice — what the supplier says you owe.
3. Goods Receipt Note (GRN) or delivery confirmation — what you actually received.

If all three match on item, quantity, and price, the invoice is cleared for payment. If they don't, it goes into a dispute queue. The logic is simple. The execution is not — because each document arrives in a different format, from a different party, at a different time.

A PO might be a PDF exported from your ERP. The invoice arrives as a supplier-generated PDF with a completely different layout. The GRN might be a scanned paper receipt, a CSV from a warehouse system, or a delivery email with an attached image. Extracting consistent, comparable fields from all three is the actual problem.

Where manual matching breaks down

The failure mode isn't that people don't know what to compare. It's that the comparison step requires a human to open three documents, read across them, and mentally (or physically) check six or more field pairs per line item. For a 20-line-item invoice, that'sundefinedcomparisons. Multiply by invoice volume and the error rate becomes structural, not individual.

Common breakdowns:

• Unit price drift: the invoice uses a per-unit price, the PO uses a bulk rate. Both are technically correct but the math doesn't surface without careful reading.
• Partial deliveries: the GRN showsundefinedunits received; the invoice bills for 100. Both documents are accurate — the mismatch is real and needs flagging.
• Field label inconsistency: "Item No.", "SKU", "Product Code", and "Part #" all mean the same thing across four different supplier templates.
• Date mismatches: invoice date precedes the PO date, which is either a data entry error or a red flag.

None of these are hard to catch once you have structured data. They're hard to catch when the data is still locked inside PDFs.

Extracting the right fields with Papersnap

The first step in automating three-way match is getting consistent, structured output from all three document types. Upload your documents to Papersnap and define a field schema that applies across all three. The fields you need for a basic three-way match are:

Core extraction schema

Field	PO	Invoice	GRN
Document number	PO number	Invoice number	GRN / receipt number
Supplier name	✓	✓	✓ (if present)
Line item description	✓	✓	✓
SKU / item code	✓	✓	✓
Quantity ordered / billed / received	Ordered qty	Billed qty	Received qty
Unit price	✓	✓	—
Line total	✓	✓	—
Currency	✓	✓	—
Delivery / invoice date	Expected date	Invoice date	Receipt date

Once Papersnap extracts these fields into JSON or CSV, the matching logic is arithmetic and string comparison — something any spreadsheet or lightweight script handles without touching the original documents again.

A worked example

Say you receive this scenario:

• PO-4471 ordersundefinedunits of "Industrial Filter Cartridge, Model FC-9" at $18.40 per unit from Hartwell Supplies. Total: $920.00.
• Invoice INV-88203 from Hartwell Supplies bills forundefinedunits at $19.10 per unit. Total: $955.00.
• GRN-2026-0831 confirms receipt ofundefinedunits of "FC-9 Filter Cartridge" onundefinedAugust 2026.

Quantity matches across all three. Description matches (with minor label variation Papersnap normalises). But unit price on the invoice ($19.10) doesn't match the PO ($18.40). The $35.00 discrepancy goes to dispute — automatically flagged, not manually spotted.

Without structured extraction, a reviewer reading three PDFs might miss the $0.70 per-unit difference. With extracted fields, a single formula catches it.

Building the matching workflow

Once you have structured output from Papersnap, the matching workflow has four stages:

1. Normalise identifiers Supplier names, SKU codes, and item descriptions often vary slightly across documents. Build a simple lookup table that maps known variants to a canonical form ("FC-9", "FC9", "Filter Cart FC-9" → FC-9). This is a one-time setup cost that pays back on every future invoice.

2. Join on document reference Link the three documents by PO number. Most invoices and GRNs reference the originating PO. If they don't, supplier name + approximate date is usually enough to join them.

3. Compare at line-item level For each line item, check: quantity billed = quantity ordered (or quantity received if partial delivery is expected), and unit price billed = unit price on PO. Flag any variance above your tolerance threshold (commonly 1–2%).

4. Route exceptions Matched invoices move to payment approval. Mismatched invoices route to a dispute queue with the specific field mismatch noted — not just "something's wrong."

If you want to connect this workflow to other tools or trigger it programmatically, Papersnap's MCP integration lets you call extraction from within your existing automation stack.

Choosing the right tolerance rules

Not every mismatch is a real dispute. Rounding differences, currency conversion fluctuations, and agreed price escalation clauses all produce technical mismatches that are legitimate. Before you automate, define your tolerance rules explicitly:

• Hard stop: quantity received < quantity billed (always flag, no exceptions).
• Soft flag: price variance ≤ 2% (flag for review, but don't block payment automatically).
• Auto-approve: price variance < $1.00 on invoices under $500 (your finance team decides this threshold).

Document these rules before you build the workflow. Automation enforces whatever rules you give it — vague rules produce vague results.

If you're evaluating whether Papersnap fits your document volume and team size before committing, the pricing page breaks down what's included at each tier.

Key takeaways

• Three-way match fails in practice not because the logic is complex, but because extracting comparable fields from three different document formats is slow and error-prone by hand.
• A consistent extraction schema — document number, supplier, SKU, quantity, unit price, line total, dates — applied across POs, invoices, and GRNs is the foundation of any matching workflow.
• Papersnap extracts structured fields from all three document types, turning comparison into arithmetic rather than document reading.
• Normalising item descriptions and SKU variants is a one-time setup step that makes every subsequent match more reliable.
• Tolerance rules need to be defined explicitly before automation — the system enforces whatever you configure.
• Partial deliveries, date mismatches, and unit price drift are the three most common mismatch patterns worth building specific checks for.

If you're building out the broader financial operations stack around this workflow, Craftmyflow is worth a look for designing the routing and approval logic that sits downstream of your matching step.

Upload your first PO, invoice, or GRN to Papersnap and see what structured extraction looks like before you commit to a full workflow build.