Manufacturing /Decisioning live field guide · 9 min

Supplier-Invoice Reconciler

Matches each supplier invoice against its purchase order and goods-receipt note, flags price variances, quantity mismatches, and missing credits, and routes the exceptions for a person to clear — never posting to the ledger itself.

Open the live demo

theater/demos/manufacturing_supplier-invoice-reconciler.html · sandbox · read-only

Open

FIG. 1

The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.

How it would work

Reads each supplier invoice at the line level, matches it against the matching purchase order and goods-receipt note, flags every variance with the source line cited, and holds the exceptions for accounts payable to clear and approve before anything is posted.

Input 01

The invoice + the PO + the GRN

The supplier invoice — from the AP inbox, a vendor portal, or an EDI feed — plus the matching purchase order and goods-receipt note pulled from the ERP, and any contracted rates or agreed credits.

Agent 02

Runs the three-way match

Extracts each invoice line — part, quantity, unit price, total — retrieves the matching PO and goods-receipt line, and compares the three deterministically: price against the PO rate, quantity against goods received, and any missing credit, citing the source line on each flag.

Output 03

A cleared queue, exceptions held

Clean invoices pre-approved for posting and an exception queue — overcharge, short delivery, missing credit, no PO — each with the documents and a drafted query attached. The AP officer clears each one and approves before anything posts or pays.

Where it works well

It runs the full line-by-line three-way match on every invoice, every time, and shows the variance with its source.

Done by hand it is 20–30 minutes an invoice, and the small variances — a rate above the PO, a short delivery billed in full, an agreed credit not applied — are exactly what a rushed check misses.
Best for an AP team or finance manager processing real volume: 200-plus supplier invoices a month against POs and goods receipts, across suppliers with varying invoice formats.
At that volume the recaptured hours go back into supplier queries and the genuine disputes, not line-by-line ticking — and posted-invoice errors fall toward zero.

The slow, invisible cost of accounts payable is the cross-check — tracing every invoice line back to a PO rate and a goods-receipt quantity, the work that gets skipped first when the AP queue backs up at month-end.

Where it works badly

It is confidently wrong when the PO or goods-receipt data is stale or missing — and a clean-looking match can hide a bad reference.

Weak where there is no PO or no goods-receipt note to match against — a service invoice, a one-off, an emergency buy — it should block and route to the buyer, not invent a match.
The extraction reads a scanned or PDF invoice and carries a confidence; a low-confidence read of a part or price should be checked, not trusted as fact.
If most of your spend is non-PO or your goods receipts aren't booked against the right line, the match has nothing solid to check against and gives you less than your own eyes already do.

The honest test

If you cannot say, right now, that the PO and goods-receipt note this invoice is matched against are the current, booked-in versions — this tool makes your wrong answer faster, not safer.

Match an invoice against a superseded PO, a goods receipt that was never booked in, or a contract rate nobody updated, and it produces a tidy "verified" result built on the wrong number. That is the trap.

What it doesn't do — and shouldn't

It flags. A person clears the exception and approves. That boundary is deliberate.

WHAT IT DOES

Surfaces each variance — price, quantity, missing credit — with the invoice line and the PO or GRN line it checked against

Drafts a supplier query or credit-note request for the exceptions, ready to send

Blocks an invoice with no matching PO and routes it to the buyer rather than guessing a match

WHAT IT WON’T

Post the invoice to the ledger or release a payment

Decide whether to accept a variance, query the supplier, or amend the PO

Approve the invoice for payment on its own say-so

A posted supplier invoice carries a GST input-tax-credit claim that must rest on a valid tax invoice, and the AP records have to be kept for the ATO. A wrong rate paid or a credit missed lands on the business, not the tool — so the accountable person stays on the decision, because the consequence does too.

What your data has to look like

Each invoice needs a real PO and a booked-in goods-receipt note to match against, with rates and credits the tool can read.

Typical readiness

across orgs we see, before the first job

A purchase order for every invoice

Usual weak point

Goods-receipt notes booked against the PO line

Needs shaping

Contracted rates and agreed credits, machine-readable

Needs shaping

Invoices captured in a readable form

Usual weak point

A supplier and ABN on the tax invoice

Usually ready

The real first job

The weak point is almost always the goods receipt and the PO discipline: invoices arriving with no PO, or goods receipts that were never booked in against the right line. Getting POs raised and receipts booked consistently is usually the real first job — an operational-discipline exercise larger and more valuable than the matching layer on top. Fix that, and every invoice after matches faster and right by default.

Right fit if…

You process real invoice volume — 200-plus a month — against POs and goods receipts

Most spend runs through a PO, with goods receipts booked against the line

You hold contracted rates and agreed credits the tool can check against

Varying supplier invoice formats make the manual three-way match the AP bottleneck

Walk away if…

Most of your spend is non-PO, services, or one-off emergency buys

Goods receipts aren't booked, or aren't booked against the right PO line

Your contracted rates live in PDFs nobody keeps current

You want a tool that posts and pays invoices without a person clearing the exception

Open questions

The worried-buyer questions, answered straight

No — it flags variances, it doesn’t approve or pay. For each exception it shows the invoice line, the PO or goods-receipt line it checked against, and the exact variance, and it blocks any invoice with no matching purchase order rather than guessing. An accounts payable officer clears each flag — accept, query the supplier, or route to the buyer — and approves before anything is posted to the ledger or released to a payment run. The tool surfaces the numbers; the person stands behind the payment.

It works from structured references — the PO line, the goods-receipt note, the contracted rate. It can read a scanned invoice and carries a confidence on each figure it lifts, but if there is no PO or the goods receipt was never booked in, there is nothing solid to match against and it should block, not invent a result. Getting POs raised and goods receipts booked against the right line is usually the first piece of work — and the piece that pays off across every invoice after.

No. It removes the line-by-line cross-check — the 20–30 minutes an invoice of tracing each line to a PO rate and a goods-receipt quantity — so the AP officer spends their time on the genuine exceptions and supplier relationships, not ticking. The clearing decision and the approval stay theirs. The capacity it frees goes back into the queries and disputes that actually need a person.

Current to what is in force when you run it. It matches against whatever PO, goods-receipt note and contracted rate are in the ERP at that moment — so a superseded PO, an unbooked receipt, or a rate nobody updated produces a clean result built on the wrong number. The honest test: do you know, right now, that the PO and goods receipt this invoice is matched against are the current, booked-in versions?

It runs inside your own ERP and AP systems via API — not a public chatbot — and supplier pricing and invoice data are not used to train third-party models. Access is role-based and every match is auditable line by line. Supplier tax invoices and the AP records behind a GST credit claim are kept the way the ATO requires. The demo here runs entirely on fabricated data; BlueScope Distribution’s INV-4471 is not a real invoice.

It checks the commercial match — price, quantity, credits — and shows its working, but it does not certify a GST position. A GST input-tax-credit claim has to rest on a valid tax invoice that identifies the supplier and its ABN and shows the GST, and those records must be kept for the ATO. The tool surfaces whether the invoice and its documents agree; a person confirms the tax position and approves the claim.

What it takes to build

3–4 weeks · 4 phases

Reused from template~65%

Bespoke to this skin~35%

stack · Claude · OCR/extraction · ERP API · rules engine · review UI

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

Embedded support

Scale on proof

Considering this for your AP team?

The honest place to start is a bite-sized first piece — one supplier, one month of invoices, low risk. Tell us where the AP queue actually backs up; we'll play it back, scope it, and show you what's possible.

Book a call How we work