Vendor Invoice Intake & 3-Way Match: Stop Overpaying Vendors
Import invoices, POs, and receipts; let AI 3-way match each invoice within your tolerances and flag every price and quantity variance — then a human approves before anything is marked ready-to-pay.
An internal web tool where you import invoices, purchase orders, and goods receipts; AI 3-way matches each invoice within your tolerances, flags variances and missing-PO exceptions, your AP lead approves or holds each one, and you export a clean approved-to-pay file plus an exceptions list.
Before you start
- A Supabase account (free)
- A Vercel account (free)
- Exports you already have: an invoices CSV (or invoice PDFs), a purchase-orders CSV, and a goods-receipts CSV
- Your match tolerances (the price and quantity wiggle room you allow)
- Claude Code or any AI coding agent
The problem this kills
A vendor invoice lands. Somebody on your AP team has to prove three things before it gets paid: that you actually ordered it (the purchase order), that you actually received it (the goods receipt), and that the price and quantity on the invoice match what was ordered and received. That's the three-way match — and most teams do it by eye, flipping between an ERP screen, a receiving printout, and a PDF.
So the small leaks happen. A unit price creeps up two cents and nobody catches it. A vendor bills for 100 when the dock only signed for 90. The same invoice gets emailed twice and paid twice. A PO number is missing entirely and the invoice sails through on trust. Each one is small. Across a year of thousands of invoices, it's real money walking out the door — and at month-end, when the pile is highest and the pressure is worst, it's exactly when the eyeballing gets sloppiest.
You don't need a six-figure AP automation suite to fix this. You can build the matcher yourself, this weekend.
What you'll build
An internal web tool your AP team logs into. You import three things — your invoices, your open purchase orders, and your goods receipts (the CSV exports you already pull, or uploaded invoice PDFs). The tool lines each invoice up against its PO and its receipt and does the math: is the price within tolerance, is the quantity within tolerance, has this much of the PO already been billed, is this a duplicate, is there even a PO at all?
Everything that matches cleanly lands in one bucket. Everything that doesn't — over-price, over-receipt, no PO, duplicate, no approved vendor — lands in an exceptions list with the reason spelled out. Your AP lead works the screen, approves the clean ones, holds the questionable ones, and clicks once to export an approved-to-pay file in the exact column layout your payment system wants, plus a tidy exceptions report. It even handles the awkward real-world cases: partial receipts, several invoices against one PO, and a two-way match mode for service invoices that never have a receipt.
What's inside the Implementation Plan
The downloadable plan is a single markdown file you paste into an AI coding agent. It opens by interviewing you about your own AP process — your invoice and PO field names, how a line links to its PO, your real price and quantity tolerances, your approval thresholds, and your messiest exceptions — and then it reads a short spec back for your thumbs-up before it builds a thing. That's the difference between a tool shaped to your chart of accounts and a generic template you have to fight.
From there it walks the agent through the data model (vendors, POs, receipts, invoices, and match results), the importers, the duplicate guard, the match-and-tolerance engine, the two-way service-invoice mode, the partial-receipt and multiple-invoices-per-PO logic, the review-and-approve screen, and the final export. Every step ends with a ready-to-copy prompt. There's a full "No API yet?" path: import from CSV, export a clean approved-to-pay CSV, and you never have to touch your ERP's API to ship.
The governance it includes (this is the point)
This is AP — the controls are the product. The plan builds them in: a login so only your team can use it; row-level security so each organization only ever sees its own invoices; a complete audit trail of who matched, approved, held, and exported, and when; a hard human-approval gate so nothing becomes "ready-to-pay" until a person signs off; and duplicate guards (on vendor + invoice number) so the same bill can't be processed twice. Out-of-tolerance variances physically cannot be exported until someone with authority approves the exception. That's the audit story your controller wants.
Who it's for
AP clerks, AP leads, and controllers who own the invoice-to-pay process and are tired of catching overcharges by luck. If you can explain to a new hire how an invoice gets matched and what makes one worth holding, you can build this — no developer required.
You've got this — open the plan, paste the first prompt, answer a few questions about how your AP actually runs, and you'll watch your first batch of invoices match itself.