AI accounts payable automation: what actually works in production

The four jobs AI actually does in AP

Accounts payable is a good fit for machine learning because it is high-volume, repetitive, and generates a labeled training set as a byproduct of normal operations: every invoice your team has ever coded and approved is an example of the correct answer. That is rarer than it sounds, and it is why AP automation produces measurable results faster than most enterprise AI projects.

But 'AI for AP' is marketed as one product when it is really four distinct capabilities with very different maturity levels. Confusing them is the most common reason an implementation disappoints.

• Invoice capture and extraction — Reading vendor name, invoice number, dates, line items, tax, and totals from a PDF, scan, or email body. Modern vision-language models handle layouts they have never seen, which is the real break from template-based OCR. This capability is mature.
• GL coding prediction — Predicting the cost center, GL account, and department from the vendor, line-item text, and your historical postings. Accuracy depends almost entirely on how consistent your past coding was — a model trained on inconsistent history will reproduce the inconsistency.
• Two- and three-way matching — Reconciling invoice to purchase order to goods receipt, including the hard cases: partial deliveries, unit-of-measure mismatches, price tolerances, and consolidated invoices covering several POs. This is where rules-based systems break and where ML adds the most value.
• Duplicate and fraud detection — Catching the same invoice submitted twice in a different format, vendor bank-detail changes, invoices just under an approval threshold, and vendors that match employee addresses. This is anomaly detection, and it is the capability with the clearest dollar return.

What accuracy to expect, honestly

Vendors quote accuracy without saying what they measured, which makes the numbers useless for comparison. Insist on field-level accuracy — the percentage of individual extracted fields that are correct — rather than document-level or character-level accuracy, which inflate the figure dramatically. A document with nine correct fields and one wrong total is a failure in AP, but it scores 90% on field accuracy and near-100% on character accuracy.

The number that actually governs your headcount is straight-through processing rate: the share of invoices that post without a human touching them. That figure depends on your confidence threshold, and it is a business decision, not a technical one. Set the threshold high and STP drops while errors approach zero; set it low and STP rises while errors reach the ledger.

Build vs buy: a straight answer

Most companies should buy. If your AP process is broadly standard — invoices arrive by email and mail, you match against POs in a mainstream ERP, and your approval rules are expressible as thresholds and cost centers — then an established AP automation platform will get you 85% of the value for a fraction of the cost and time. We will tell you that on the call rather than quote you a build.

Building makes sense in a narrower set of cases: when your matching logic encodes genuine business complexity a platform cannot express, when AP is embedded in a product you sell rather than an internal back office, when data residency or regulatory constraints rule out sending invoices to a third-party cloud, or when you are integrating AP intelligence into a system of record you already own.

• Buy when — Standard process, mainstream ERP, approval rules expressible as configuration, and no requirement to own the model or the data pipeline.
• Build when — Matching rules that no platform supports, AP capability inside a product you sell, hard data-residency limits, or an existing internal platform that must own the workflow.
• Hybrid, most often — Buy the platform for capture and workflow, build the thin layer that encodes your specific matching, coding, and exception logic on top of its API. This is the most common outcome of an honest evaluation.

What an AP automation build actually costs

For a custom build, the cost driver is integration surface, not the model. Connecting to one ERP with a documented API and a single invoice intake channel is a materially different project from reconciling three ERPs after an acquisition, and the model work is nearly identical in both cases.

Where implementations fail

• No human-in-the-loop design — Teams build the model and treat the review queue as an afterthought. The review interface determines whether your AP clerks trust the system, and trust determines adoption. Design it first.
• Optimizing accuracy instead of throughput — Going from 94% to 96% extraction accuracy is expensive and often changes nothing operationally. Reducing the exception-handling time per flagged invoice usually saves more hours.
• Training on inconsistent history — If three clerks coded the same vendor three different ways for four years, the model learns the ambiguity. Clean the taxonomy before training, not after.
• No drift monitoring — Vendors change invoice layouts, your chart of accounts changes, and accuracy decays quietly. Without monitoring you find out from a controller, months late.
• Ignoring the fraud case — Automation removes the human eyes that used to catch anomalies incidentally. If you automate approval without adding anomaly detection, you have increased fraud exposure, not reduced it.

How NextGen approaches AP engagements

We start with a data audit, not a demo. Give us a representative sample of your invoice volume and your last 12–24 months of posting history, and we will produce a measured accuracy baseline for extraction and coding on your actual documents — before you commit to a build. That baseline is frequently the deliverable that tells a client to buy a platform instead, and we consider that a successful engagement.

Where a build is right, everything ships with a review interface, a confidence threshold you control, evaluation harnesses that re-score accuracy on every model change, and monitoring that alerts on drift. All work is performed by senior US-based engineers, which matters for AP because the data is financial and the process is auditable.