Part of an ongoing series on ordinary workspace friction, and what happens when you point an agent at it.
Somewhere in a finance inbox there are eighty invoices waiting to be matched against purchase orders. Most of them will match cleanly. A handful won't, and finding which handful is the whole job.
So someone opens the PDF, finds the PO number, pulls up the PO in the ERP, compares line items, checks whether the quantities shipped match the quantities billed, checks whether the price on the invoice matches the price that was agreed, and moves on to the next one. Seventy-two times out of eighty, nothing is wrong. That's several hours of a skilled person's week spent confirming that things are fine.
The eight that don't match are the ones that matter, and by the time you reach them you've been reading PDFs for two hours.
The work is high volume and low judgment, until suddenly it isn't
Reconciliation has a strange profile. Ninety percent of it requires no judgment at all: two numbers either agree or they don't. The remaining ten percent requires real expertise: is this a partial shipment or a short ship, is this a legitimate price escalation covered by the contract, is this vendor double-billing or did we genuinely order twice?
The problem is that you can't get to the ten percent without going through the ninety. There's no way to know which invoices are the interesting ones except by checking all of them. So the expert spends most of their time doing clerical work in order to surface the small number of cases where their expertise actually matters.
And because it's tedious, it slips. Invoices sit longer than they should. Early payment discounts get missed. Duplicate payments go out because nobody caught that the same invoice came in twice under slightly different numbers. Every one of those is a real dollar cost, and none of them show up on a report labeled "reconciliation is behind."
The kind of system we'd build
This one passes the test easily: the task repeats, the rules are describable, the data lives in systems you already run, and a person can say precisely what a correct result looks like. That's what we look for before recommending AI agent development at all.
Here's what an agent for this looks like. It reads the invoice, whether that's a structured EDI feed, a PDF attachment, or a scan someone emailed in. It pulls the matching purchase order and the receiving record. It compares them line by line: quantity, unit price, extended total, tax treatment, payment terms.
When everything agrees within your tolerance, it marks the invoice matched and queues it for payment. No human touches it. When something doesn't agree, it doesn't just flag "mismatch." It says what's different, by how much, against which line, and what the likely explanation is: partial shipment, price variance outside contract terms, quantity over-billed, possible duplicate of an invoice received last week.
The finance person opens a queue of eight exceptions with the discrepancy already isolated, instead of a queue of eighty PDFs.
The agent matches. A person still decides
The agent should never approve a payment on a discrepancy. That line matters, and we'd draw it hard in the design.
A price variance might be a vendor overcharging or a contract amendment nobody logged. A short ship might be a supply problem worth a phone call or a normal partial delivery. A possible duplicate might be a real duplicate or two legitimate invoices for two legitimate deliveries. Telling those apart takes context about the vendor relationship, the contract, and what's normal for this account, and it belongs to a person.
What changes is the ratio. Instead of two hours of clerical checking to find eight cases, it's twenty minutes of judgment on eight cases that were handed over pre-analyzed. The expert spends their time being an expert.
Where the accuracy actually comes from
The instinct is to think a language model reads the invoice and figures it out. That's the wrong architecture, and it's how these projects fail.
Document extraction should be deterministic wherever it can be. Structured feeds get parsed as structured data. PDFs with consistent layouts get templated extraction. The model handles the messy tail: unfamiliar vendor formats, scans, line item descriptions that don't map cleanly to PO lines. Every extracted field carries a confidence score, and anything below threshold goes to a human rather than into the matching logic.
The matching itself is business rules, not inference. Tolerances, contract terms, and approval thresholds are configuration you can read and audit, because a finance team needs to be able to explain why a given invoice was approved. Then you need an evaluation set: a few hundred historical invoices with known correct outcomes, run against the system on every change, so accuracy is a number you can see rather than a feeling. Building that harness is usually where the backend development effort concentrates, and skipping it is the most common reason these systems get quietly turned off six months in.
A question worth sitting with
Pull the last month of invoices and count two things: how many required no correction at all, and how many hours your team spent to determine that.
If most of them were clean and the checking still took real time, that's not a diligence problem. It's a coverage problem, and it's the same shape as the churn signals nobody is watching or the Friday status update: information that already exists, in systems you already own, with nobody positioned to reconcile it continuously.
If you want to talk through whether a workflow like this is worth automating, that's what our AI development work is for, and Polarity is a good look at how we handle systems where money moves and being wrong is expensive.