Most AP automation projects fail on approach, not technology. The fact is you don't need to replace your ERP to fix invoice processing. This guide breaks down five proven adoption patterns for finance teams at manufacturers and distributors, each a different way to build trust in AI before scaling it. Pick the one that fits your team's risk tolerance and resources, prove it on one process, and expand from there.
A controller at a billion-dollar parts distributor recently described the moment AP automation got real for her team. For years the work had run the same way: tens of thousands of invoices a year arriving as PDFs from vendors who never adopted EDI, keyed in by hand against an ERP built in the early 1980s that still shows a green screen. Her situation is an extreme example, but the shape is common: an untouchable system that runs the whole operation, predates half the team, and nobody wants to risk disturbing.
Then her team automated invoice intake and exception handling without touching the ERP at all. A layer of intelligence converted those non-EDI PDFs into the 810 EDI documents the ERP already expected, and delivered them the way it already accepts.
Nothing migrated. Nobody re-trained on a new platform.
Most finance teams are working from an outdated assumption: fixing invoice processing means replacing the entire system in a long, expensive, IT-led migration. So the project stays off the table. But while the migration model made sense for rigid systems where every case had to be mapped before go-live, it's the wrong model for AI. Agents are built to learn and improve through iteration instead of upfront specification.
The right approach is more modest and durable: pick a proven adoption pattern, start with a process you already understand, and build confidence in stages. Here are five approaches to adopting AI that we've seen work in manufacturing and distribution companies.
Crawl, walk, run
Build trust one phase at a time.
When an automation project kicks off, the pressure is to automate everything fast. Crawl, walk, run flips it: start with low-risk wins that prove the system is safe, then expand as confidence grows.
Quickly improving a low-stakes, high-volume task builds credibility and reduces skepticism when you venture into more complex processes.
Order entry automation
A manufacturing company is following the crawl-walk-run model on an order entry project, securing wins and compounding learnings quickly. Their phases:
The agent reads incoming POs and emails, checks details against master data, and drops a draft order into the ERP for a person to review. Nothing posts without a human.
The agent handles the back-and-forth itself, reaching out to the customer (with a rep copied) whenever an order arrives incomplete or with the wrong pricing.
The agent weighs current machine capacity and delivery schedules to tell a customer up front when a requested date can't be met.
Once it's holding a 99% approval rate on the drafts it creates, the agent starts submitting clean orders on its own, automating the process end to end for good orders.
The payoff shows up immediately: the data entry disappears while existing controls stay where they are, giving the team a clear, low-risk path toward full automation.
Set explicit thresholds before advancing: extraction accuracy above 95% before walk, error rates below 2% before run. Don't move on until you hit them.
Crawl, walk, run lets you prove ROI in stages without putting existing controls at risk. Each phase has a measurable checkpoint before more volume or autonomy changes hands.
Copilot first
Earn trust through assistance.
Handing invoice decisions to an agent on day one is a big ask, and most teams aren't there yet. The copilot approach has AI working in the open and showing its reasoning on every call, earning trust before it runs on its own.
Working alongside the AI, your team learns where it's strong and where their judgment still matters. That paves the way for easier and more effective long-term adoption.
Price-mismatch exceptions
An invoice comes in at a price that doesn't match the PO, or a vendor's part number doesn't line up with the one in your ERP. These aren't edge cases. They're the daily reality of messy, drifting master data, and exactly what a copilot agent is built to work with rather than choke on.
The agent suggests, the specialist decides. For each mismatch, the agent gathers the PO, the receipt, the vendor's pricing history, and how similar cases were resolved before, then proposes a disposition with its reasoning shown. The specialist spends two minutes confirming instead of fifteen assembling context.
The agent decides, the specialist reviews. Once its recommendations consistently match what the specialist would have done, the agent dispositions mismatches inside an agreed tolerance and routes decisions for a quick after-the-fact check instead of upfront approval.
The agent acts on the routine, escalates the rest. Clean, in-tolerance variances clear on their own. Only genuinely ambiguous cases, a large discrepancy or a vendor with a history of disputes, come to a person, who now spends their time on the exceptions that actually need judgment.
Early on, expect plenty of overrides and treat that as healthy. The signal you're watching for is the day your team starts asking you to automate more. It means they've come to trust it.
Copilot-first earns trust through collaboration. That trust pays off fastest when you point it at one team and one process instead of spreading pilots thin.
One team, one use case
Depth beats breadth.
AI pilots spread across several teams at once tend to disappoint, because none goes deep enough to prove real value. Instead, concentrate on one team and one process, prove it completely, and let that win become the template.
A single team that masters one workflow is worth more than five teams dabbling. The learnings compound, and that team turns into your most credible advocate for AI everywhere else in the business. A focused win gives other teams a story they can follow; scattered pilots with shallow impact don't.
A single team that masters one workflow is worth more than five teams dabbling.
Invoice exceptions
The most familiar complexity sink in AP is the invoice exception: an invoice that fails the three-way match because a part number doesn’t line up or a dash is missing, which today lands on the AP manager to chase down across ERP screens, email threads, and spreadsheets.
Pick the one process. AP commits to invoice exception handling as its single focus, with a clear owner and one metric leadership cares about: straight-through processing rate.
Point a targeted agent at it. Instead of waiting for a system overhaul, the team deploys an agent on that one workflow. It pulls the scattered context together: the PO, the receipt, the vendor history, prior resolutions. Then it proposes the resolution path, so what took hours of toggling now takes minutes.
Prove it completely. The team drives that single process to a high straight-through rate and real, demonstrable ROI before touching anything else, building genuine expertise as they go.
Let the win become the template. With one workflow proven, the team expands to adjacent AP processes on familiar ground, and becomes the internal proof point that makes the next team's adoption easier.
Pick a starting team with a leader who'll champion the win, not just tolerate the pilot. The point of going deep is to create an advocate the rest of the org will listen to.
Once one team has proven value, scaling gets easier, as long as the work doesn't have to be rebuilt from scratch each time. That's where a library comes in.
Build a library
Reuse what works.
The first time your team automates an AP workflow, they solve a dozen small problems along the way: how to extract data from a messy invoice, which validation rules catch real errors, when to escalate. A library is just the discipline of saving those answers so the next project doesn’t start from zero.
The payoff compounds. What took months to figure out the first time takes weeks the third, because each project draws on the components the last one left behind, and results get more consistent as the library grows.
From invoice matching to cash application
First project: invoice matching. The team refines extraction prompts for messy vendor invoices and a set of three-way-match rules, and saves both once they're working reliably.
Capture what's reusable. They pull out the pieces that aren't specific to invoice matching: the messy-data extraction approach, the validation logic, the way they measured accuracy.
Second project: cash application. When they tackle remittance matching months later, the messy-vendor-data problem is one they've already solved, so they stand it up in a fraction of the time by drawing on what's already in the library.
For a team automating its first AP process, don't over-invest here yet. Just capture what works so you're not rebuilding it later. The payoff comes once you're several use cases deep.
A reusable library makes each new project faster. The next question is how you decide what to build first, which is where experimentation comes in.
We'll map your highest-volume, lowest-risk AP processes to the right pattern, on the ERP you already run.
Run safe experiments
Short cycles beat long plans.
Long planning cycles kill AP automation the same way they made the last ERP project painful: months designing a roadmap that's obsolete by the time it ships. The faster path forward isn't another eighteen-month transformation. It's small, targeted projects that prove value in weeks.
Short cycles keep you grounded in reality, so instead of betting everything on a perfect plan, you adapt as you go. Every experiment teaches you something, even when it doesn't scale.
Stale PO write-offs
Closing out stale purchase orders makes a near-perfect first experiment: it's low-stakes, high-volume work that's safe to test on because nothing sensitive sits downstream of it. Here's how a team runs it as a single 90-day cycle:
They point an agent at one batch of stale POs and check every write-off by hand, confirming it gets them right before trusting it with volume.
They hand it the full backlog, keeping the cases it flags as uncertain for a person to handle, and the manual hours start to drop.
They document what worked, bank the hours they got back as the proof point, and reuse the same playbook to scope the next experiment.
Give each experiment a hypothesis, a success metric, and a resource limit up front, so it stays disciplined without turning into another multi-quarter commitment.
How to choose the right adoption pattern
No two finance teams start from the same place. Match the pattern to your situation:
Start with crawl, walk, run and document every phase for audit readiness.
Pick one team, one use case, and let a library build as you go.
Run safe experiments with crawl, walk, run underneath for structure.
The one rule: don't try all five at once. Pick the pattern that fits your reality today, prove value on one process, and expand from there.