Why AP Transformation Fails Without Change Management
by Hannah Khouri
Six months after go-live, the AP manager at a 200-employee food distributor pulled up the usage dashboard and felt her stomach sink. Adoption was sitting at 40 percent. Half of her team was still printing invoices and marking them up by hand. One clerk kept a spreadsheet “just in case” the new system lost something. The controller had stopped asking about it in their one-on-ones, which somehow felt worse than if he’d complained.
The software worked fine. The vendor had delivered what was promised. The implementation team had checked every box on their go-live checklist. And yet, here was a company paying for automation while, in practice, running two parallel AP processes — one digital and one paper — both inefficient in their own way.
This story repeats itself across mid-market finance teams more often than any vendor wants to admit. The invoice volume is high, habits are deeply ingrained, and the software is blamed for a failure that has almost nothing to do with it.
Why AP automation projects stall after go-live
AP automation projects fail when the organization treats implementation as a technical event instead of an operational change. The system goes live, but the people who have to use it every day were never given a reason to change how they work. So, they don’t.
A few patterns show up again and again:
The team reverts to old habits. Month-end close, an unusually high invoice volume, a vacation that leaves the team short-staffed – any of these will send people back to whatever workflow feels fastest and most familiar, even if that means working around the new system rather than through it.
No one owns adoption internally. Plenty of implementations have a project manager during the rollout phase, but no one is designated to own adoption afterward. Without a champion who’s accountable for usage rates, exception handling, and answering questions, the system drifts.
Training happens once and never again. New hires join with no formal onboarding to the AP software. Existing staff forget features they didn’t use in their first week. Nobody revisits training as the team’s needs change.
Approval workflows were never mapped before implementation. The software is configured to match whatever process existed on paper, including the bottlenecks, the redundant sign-offs, and the approvers who were never clear on what they were actually supposed to check. Automating a broken workflow just makes the breakage faster and more visible.
None of this is a software problem. It’s what happens when a company buys a new system and assumes the system will do the work of changing behavior on its own.
It’s also worth noting that the old manual process was slow and carried real exposure. Inconsistent approval trails, easily forged invoices, and a lack of audit visibility mean manual processes don’t just create inefficiency; they create risk that often goes unnoticed until something goes wrong.
The change management piece most teams skip
Change management in accounts payable is the structured plan for how AP work will change, who is responsible for each part of that change, and how the organization measures whether the change has actually taken hold.
Most AP implementations have a technical project plan. Few have an equivalent adoption plan. That gap is usually where the ROI disappears.
A real change management plan for AP transformation covers four things:
- Stakeholder mapping. Before the system is configured, identify everyone who touches an invoice, including AP clerks, department approvers, the controller, the people in operations who code expenses, and even AP’s contacts in vendor relations. Each group has different concerns and different reasons to resist change. Mapping them out before launch means you can address resistance early.
- Role-based training. An AP clerk needs to know how to process exceptions and match invoices to POs. A department approver needs thirty seconds of training on how to approve from their inbox, not a full system walkthrough. A controller needs to understand reporting and audit trails. Training everyone the same way wastes time and signals that the rollout wasn’t really planned for them specifically.
- A 30/60/90 day adoption framework. The first 30 days should focus on ensuring everyone is actually in the system rather than working around it. Days 30-60 shift to refining workflows and catching the exceptions that only surface once real volume runs through the process. Days 60-90 should show measurable movement on processing time and exception rates. Without checkpoints like these, “we’ll get to full adoption eventually” becomes the plan, and rarely ever arrives.
- An empowered internal champion. This is usually the AP manager, sometimes a senior clerk who’s bought in early. They need real authority to flag problems to leadership, not just a title. If the champion has to fight for attention every time adoption slows, the role doesn’t function.
What good adoption actually looks like
Most teams know when they’re not getting full value from their AP software. Few can say what full value looks like in measurable terms, making it nearly impossible to hold anyone accountable for closing the gap.
Invoice processing time
Manual AP processes often take several days or more per invoice, once you account for routing, approvals, and exceptions. Teams that adopt automation well typically see that number cut dramatically within the first quarter. Heritage Grocers Group, an Ottimate customer, saw a 50-70% reduction in invoice processing time by implementing a deliberate software rollout.
Exception rate trends
A high exception rate in week one is normal. That’s the system surfacing mismatches and errors that the old process never caught. What matters is whether that rate trends downward over 90 days as workflows are refined and staff become more fluent with the tool. A flat or rising exception rate for three months is a sign that adoption, not the software, is the problem.
Early payment discount capture
Capturing early payment discounts requires processing invoices fast enough to act on them, which only happens when the team has actually stopped batching invoices for end-of-week processing the old way. A rising discount capture rate is indirect proof that the new process is the real process, not a parallel one running alongside the old habits.
How to build your internal case for change
If you’re the AP manager who can see the gap between what the software should be doing and what’s actually happening, the challenge is to get leadership to treat it as a priority.
A CFO will engage with real numbers far more readily than vague descriptions of adoption struggles. Frame the conversation around the metrics leadership already tracks, like:
- Cash flow visibility
- Early payment discount capture
- Days payable outstanding
- Audit readiness
These are the levers that connect AP performance to the broader financial picture.
It also helps to name the cost of inaction specifically. A stalled implementation is an ongoing expense. The company is paying for software it isn’t using to capacity, plus the labor cost of maintaining a shadow manual process, plus the missed discounts and audit exposure that comes with inconsistent approval workflows. Quantify that gap so lagging adoption becomes something the CFO can (and wants to) act on.
When to bring in outside support
Some organizations have the internal bandwidth to manage a structured adoption plan on their own, but many don’t, particularly in mid-market finance teams where the AP manager is already stretched thin.
There’s no failure in recognizing that gap. Implementation support exists because rollout and adoption take a different kind of attention than day-to-day work. Ottimate’s approach to implementation is built to support both technical configuration and change management. You can see how Ottimate supports implementation and what the onboarding process looks like before deciding whether to handle adoption internally or with help.
Reframe your AP transformation
AP transformation is an operational change that happens to involve software. Focusing only on system deployment and neglecting to address how that deployment will change the way people work often results in a lack of adoption.
Don’t assume a new tool will change behavior on its own. Building a plan for the platform and a plan for the people is what will ensure the software delivers.
Want to see Ottimate in action?
See how Ottimate can improve your day-to-day with AI-powered AP solutions.
Get a Demo
