n8n Accounts Payable Automation: 3-Way Match and Approval Routing

Most accounts payable content shows you the easy half. A vendor emails an invoice, an AI node reads the amount, you match it against a purchase order, you pay. The n8n.io invoice-PO matching template that ranks does exactly this, and it does it well. It also pays for things you ordered but may never have received, because a 2-way match never checks whether the goods actually arrived.

Real n8n accounts payable automation does a 3-way match. The purchase order says what you agreed to buy. The invoice says what the vendor billed. The goods receipt says what showed up on the dock. Pay only when all three agree, and route everything else to a human. That's the difference between an AP demo and an AP control.

This is the upstream half of finance, by the way. Chasing money owed to you is accounts receivable, a different job covered elsewhere. This post is about paying out without paying wrong.

What You Can Automate in Accounts Payable

The AP steps that automate cleanly:

• Capturing invoices from an AP inbox or a Drive folder
• Extracting vendor, amount, line items, and PO number with an AI node
• Pulling the matching PO and goods receipt from your records
• Running a 3-way match on totals and line items
• Auto-approving matched invoices under a low threshold
• Routing matched invoices over a threshold to a manager
• Sending unmatched or mismatched invoices to procurement
• Logging every decision with who approved it and when

The match decides the path. The threshold decides how much human attention each invoice gets. The log makes the whole thing auditable.

The Accounts Payable Pipeline

The shape that keeps a bad invoice from becoming a bad payment:

Capture → Extract → Match (3-way) → Route by threshold → Approve → Pay → Log

A concrete run:

Gmail Trigger v2 / Google Drive Trigger: new invoice arrives
  → AI extraction (openAi v2.1): vendor, amount, line items, PO number
  → Google Sheets v4: fetch matching PO + goods receipt
  → Code v2 (jsCode): 3-way match on totals + line items
  → Switch v3: matched-low | matched-high | unmatched
  → matched-low: mark approved
  → matched-high: Slack v2 approval request → Wait v1.1
  → unmatched: email procurement with the discrepancy
  → Google Sheets v4: append AP decision log

Notice the unmatched path never reaches payment. An invoice with no PO, a missing receipt, or a total that doesn't tie out is an exception, and exceptions go to people, not to the bank.

Step-by-Step Breakdown

1. Capture the invoice

Watch an AP inbox or a dedicated Drive folder. The moment an invoice lands, the workflow fires. Don't make someone forward it manually — that's the bottleneck you're trying to remove.

2. Extract the structured fields

An AI node reads the PDF and returns vendor, total, line items, and the PO number as structured data. The @n8n/n8n-nodes-langchain.openAi v2.1 node returns its output at $json.output[0].content[0].text; a Code node parses that JSON into fields the matcher can use.

3. Pull the other two documents

With the PO number in hand, fetch the purchase order and the goods receipt. If either is missing, that's already an exception — you can't 3-way match against documents that don't exist.

4. Run the 3-way match

One Code node compares totals and line items across PO, invoice, and receipt. Exact agreement on all three is a clean match. Anything else is a candidate for human eyes, not for payment.

5. Route by threshold and exception

A Switch node sends matched-and-small straight to approved, matched-and-large to a manager for sign-off, and any mismatch to procurement. Three paths, three owners. The threshold is a number you set, not a guess the workflow makes.

Implementation Patterns That Hold Up

Pattern 1: The 3-way match in one node. Compare the three documents on the fields that matter.

Code v2 (jsCode):
  const poOk  = Math.abs(invoice.total - po.total) < 0.01;
  const rcvOk = receipt.lineItems.every(li =>
    invoice.lineItems.find(x => x.sku === li.sku && x.qty === li.qty));
  if (poOk && rcvOk) return [{ json: { result: 'matched' } }];
  return [{ json: { result: 'exception', poOk, rcvOk } }];

The receipt check is the leg the 2-way templates omit. It confirms the quantities billed match the quantities received, SKU by SKU, which is where over-billing hides.

Pattern 2: Threshold routing that doesn't stall. A matched invoice under, say, a few hundred dollars carries little risk and auto-approves. Above that, it routes to a manager. The trap is approvals that sit in a travelling approver's inbox. Add a timeout: if the Wait node doesn't get a response in a set window, escalate to a backup approver or a Slack channel, so a quiet manager never becomes an overdue vendor.

Pattern 3: A tamper-evident audit trail. Every decision appends a row: invoice ID, match result, amount, who approved, timestamp. Don't update rows in place. Append-only logging means the history of an approval can't be quietly rewritten, which is exactly what an auditor wants to see.

n8n Nodes You'll Use Most

The Code node doing the match is the one to get right. Everything upstream feeds it three documents; everything downstream acts on its verdict. Test it against a deliberately over-billed invoice and confirm the receipt leg catches it.

Getting Started

1. Get all three documents into the workflow. PO, invoice, and receipt as named branches. You can't 3-way match what you can't see.
2. Build the extraction and confirm the parse. The AI node returns text; a Code node turns it into fields. Test on a few real invoices before trusting it.
3. Write the 3-way match and break it on purpose. Feed it a partial-shipment invoice and confirm the receipt leg flags it.
4. Set your thresholds explicitly. Auto-approve under X, escalate over X, exception otherwise. Write the numbers down in the Config node.
5. Add the approval timeout. A pending approval that never resolves is an overdue invoice waiting to happen. Escalate on a clock.
6. Append every decision. Invoice ID, result, approver, timestamp, append-only. That log is your audit trail.

One honest limitation: AI extraction from invoice PDFs is good, not perfect. A smudged scan or an unusual vendor layout will occasionally misread a total. Treat the extracted amount as a claim to verify against the PO and receipt, not as ground truth. The 3-way match is what protects you when the extraction slips.

If AP is one piece of your finance stack, the n8n finance automation guide covers the receivable side, and the n8n bank reconciliation workflow shows how the payments you make here get matched back against the bank feed later.

Build the 3-way match first, with the receipt leg. The approval routing is configuration on top of it. The match is the control that actually saves money.