How I Would Redesign Invoice Processing If We Started From Zero

Direct Answer

An AI-native invoice processing system is a coordination layer that reads every incoming invoice the moment it arrives, matches it against the purchase order and the delivery record automatically, and routes only the disagreements to a person. The default state flips from “a human checks every invoice” to “a human checks the ones that disagree.” Three-way matching does not disappear. The manual act of holding three documents next to each other does.

Key Takeaways

• The 1995 route survives because three-way matching was built as a paper control. Email, PDF, and a spreadsheet are the closest thing most companies ever built to replace the paper.
• The bottleneck is not reading the invoice. Extraction software has done that reliably for a decade. The bottleneck is deciding who is allowed to approve a mismatch, and today that decision goes to whoever checks their inbox first.
• An AI-native route keeps three-way matching. It removes the clerk work of finding the purchase order, finding the goods-receipt note, and eyeballing whether three numbers agree.
• Approval above a set threshold, any new vendor banking detail, and every mismatch investigation stay human — that is where segregation-of-duties controls and fraud liability actually sit, not in the matching itself.
• Best-in-class AP teams already process an invoice for under three dollars in about a day, against an industry average closer to nine dollars and ten days. That gap is the business case. AI is the mechanism, not the pitch.
• This is a designed model, not a system I have shipped for this exact process. It stays a model until someone running real AP volume tells me where it actually breaks.

What problem does this system actually own?

Accounts payable exists to answer one question before money leaves the company: is this a legitimate charge for something we ordered and received, and should we pay it now. Everything else — the inbox, the PDF, the spreadsheet, the approval email — is scaffolding built to answer that one question with enough evidence to survive an audit.

The scaffolding is expensive. Ardent Partners’ benchmark work, reported by WEX, puts the average cost to process a single invoice at around nine dollars and ten days, while best-in-class teams do it for under three dollars in about a day. Same question, same three documents, an order of magnitude apart in cost. The difference is not the decision. It is how much human motion it takes to reach the decision.

That is the problem an AI-native system owns: shrink the motion, keep the decision where it belongs.

The existing workflow I would map first

Here is the route I would go trace inside a real company before touching anything, because a version of it runs almost everywhere invoices exist:

A purchase order gets issued, sometimes from a procurement system, often from an email or a verbal agreement that never becomes a document at all. Goods or services arrive. The supplier emails a PDF invoice to a shared inbox, or to whichever person they last dealt with. Someone in accounts payable opens the PDF and keys the header fields — vendor, invoice number, amount, due date, line items — into accounting software or, in a lot of smaller companies, directly into a spreadsheet.

That person then has to go find the other two documents. The purchase order might be in the procurement system, or it might be a different email thread. The goods-receipt note, if one exists, might be a signed paper slip sitting in a warehouse office. Three-way matching is the name for lining these three documents up and confirming the quantities and prices agree. Manually, that means thumbing through printouts or switching between browser tabs and visually comparing numbers.

If the numbers agree, the invoice goes into an approval queue — usually another email, or a message to whoever has signing authority, who may be traveling, in meetings, or simply slow to check. If the numbers disagree, it becomes a written back-and-forth with the vendor and whoever placed the original order, often taking days to resolve because nobody owns the exception until someone notices it is stuck.

Once approved, someone schedules the payment in a banking portal. Someone else — sometimes the same person, sometimes not — has to know the payment happened in order to reconcile the books later. Each handoff is a place the invoice can sit untouched for a day, a week, or long enough that the company pays late fees on a legitimate bill it verified in the first hour and then lost in a queue.

How the system would run

The route I would design does not remove three-way matching. It removes the six separate human motions currently required to perform it.

An invoice arrives — by email, a vendor portal, or an API feed, it does not matter which. The system parses it on arrival using field extraction that identifies vendor, amount, invoice number, due date, and line items by their semantic role on the page, not by a template tuned to one vendor’s layout. That is the same extraction technology invoice software has used for years; it was never the hard part.

The system then pulls the referenced purchase order and the goods-receipt record directly from procurement and inventory systems, instead of a person going to find them. It runs the three-way match automatically. If the invoice, PO, and receipt agree within a set tolerance, the invoice moves straight to a single approval click for the person who holds signing authority, with all three documents already lined up in front of them.

If they disagree, the system does not just flag “mismatch.” It surfaces the specific disagreement — quantity off by four units, unit price twelve percent above the PO, a line item that never appears on the receipt — to the person who can actually resolve it, with the documents attached and the discrepancy already isolated. That is the difference between a two-minute decision and a three-day email thread.

Once approved, the payment is scheduled and the accounting system updates in the same motion, so reconciliation stops being a second pass over data someone already touched once.

None of that is the hard part of accounts payable. It is information moving between people who each hold one piece of it — the PO from procurement, the receipt from the warehouse, the invoice from the vendor, the approval from finance. That coordination layer is the product, the same pattern behind how I would build a bookkeeping system that hides the ledger and an AI-native insurance claims system: matching three numbers was never the bottleneck; finding them was.

What stays under human control?

Three things stay behind a person, deliberately, regardless of how good the matching gets.

Approvals above a defined dollar threshold stay human, because that is a documented control, not a formality — segregation of duties exists specifically so no single actor, human or automated, can create, approve, and release a payment alone. Committing fraud should require collusion, and a fully automated approval chain quietly removes that requirement.

Any change to a vendor’s banking details stays human, with out-of-band verification. This is the single most common vector for business email compromise fraud: an attacker impersonates a known vendor, requests a routing-number change, and a system that trusts incoming data without a human callback will happily “match” the new fraudulent details against a legitimate invoice.

Every mismatch stays human. The system’s job is to isolate the disagreement and hand it over with the evidence already assembled — not to decide on its own that a twelve percent price variance is fine because it looks similar to past variances it has seen. That judgment call, and the willingness to say no to a vendor, belongs to someone who can be asked why later.

When this is the wrong build

Low invoice volume is the first kill condition. If a company processes a few dozen invoices a month, the manual route already costs less than building or buying a matching system, and the return never clears.

No purchase order discipline is the second. If most spend never generates a PO — services bought on a handshake, recurring subscriptions, expense-style purchases — there is nothing for the invoice to match against. What looks like an invoice-automation problem is actually a procurement-discipline problem, and building a three-way matcher on top of two-way or no-way spend just automates the eyeballing of a single document, which is a smaller, different build.

Heavily bespoke service invoices are the third. Retainers, consulting hours, and professional services rarely map cleanly to a PO with fixed quantities. Confirming “did this work actually happen at this level” is a judgment call no matching engine can verify from an inbox, and forcing it into a matching workflow just adds friction without adding certainty.

How this connects to the engagement

This is the same shape of build I described in the freight booking system that hides the freight and the AI sales follow-up system inside a CRM: an owned, supervised system inside tools the finance team already uses, not a new inbox for them to check. The engagement is mapping the real route first — where the PO actually lives, who currently resolves a mismatch, what the approval threshold really is — before any matching logic gets built.

Summary

The invoice did not get harder to read. Extraction software solved that years ago. What stayed expensive was the coordination — a clerk finding two other documents, a queue with no owner, an approval that depends on someone checking email at the right moment. Building this well means keeping the three-way match and the human judgment calls exactly where they are, and deleting the six steps in between that exist only because nobody had connected the systems that already hold the answer.

Sources

• What Does It Cost to Process an Invoice? AP Benchmarks Every Finance Team Should Know — WEX Inc.
• Segregation of Duties in Accounts Payable Explained — Ramp
• 3-Way Invoice Matching in Accounts Payable — DocuWare