Four Problems With Letting Your ERP Vendor Set Your AI Agenda
A 300-employee distributor we'll call Kessler Supply got an email in March: their ERP vendor was retiring the current release in fourteen months and replacing it with a new tier that bundled "AI-powered demand forecasting" into the core license. The finance team hadn't asked for forecasting help. The warehouse team, who actually needed better cycle-count tools, got nothing. The upgrade was mandatory anyway, because the old tier was being sunset.
That sequence repeats across the ERP market right now. Vendors are under pressure to show AI revenue on earnings calls, and the fastest way to do that is to attach an AI label to existing modules and push it through the renewal cycle. For the customer, that creates four specific problems, each with a workaround.
1. The roadmap reflects the vendor's sales calendar, not your operations
Vendor AI features get built for the broadest possible customer base, which means they solve generic problems: summarizing a support ticket, drafting a PO description, flagging an "anomalous" invoice using a threshold nobody tuned for your business. Meanwhile the actual bottleneck at Kessler Supply was a three-person AP team keying in 40% of vendor invoices by hand because their scanning tool couldn't handle non-standard formats. No AI roadmap slide addressed that.
The fix isn't to reject AI features outright. It's to stop treating the vendor's roadmap as your roadmap. Before a renewal or upgrade conversation, write down your own top three operational bottlenecks with a rough cost estimate for each (hours per week, error rate, headcount). Bring that list into the vendor meeting and ask them to map their AI features against it directly. If nothing maps, say so, and ask what's on the roadmap for your actual problems — not next year's, this year's.
2. Data governance terms are vague or missing entirely
Most ERP contracts written before 2023 say nothing about whether your transactional data can be used to train models, whether that training is customer-specific or pooled across the vendor's full customer base, or whether you can opt out without losing the AI feature entirely. When Kessler's IT lead asked directly, the vendor's answer was "we don't share data between customers" — which is not the same as "we don't use your data to train a shared model," and the sales rep didn't seem to know the difference.
Get this in writing as a contract addendum, not a verbal assurance: specify whether model training uses your data, whether it's isolated per tenant, how long inference logs are retained, and what happens to that data if you cancel. If the vendor won't put it in writing, treat that as the answer. This matters most for anyone in a regulated industry — healthcare, financial services, government contracting — where a data handling gap isn't just an inconvenience, it's an audit finding.
3. AI features are used to force an edition upgrade
The forecasting module Kessler got wasn't available on their existing tier at any price — it only shipped bundled into the next license tier up, at 22% higher per-user cost. This is a common packaging move: instead of selling AI as an add-on module you can decline, vendors tie it to a new edition so declining the AI feature means declining the whole upgrade, which usually isn't an option once the old edition is sunset.
When you hit this, ask two direct questions: can the AI feature be licensed standalone without the edition bump, and if not, what specifically in the new edition (beyond the AI label) justifies the price increase. Sometimes there's real value in the underlying platform changes — better API access, faster reporting — and the AI feature is genuinely incidental. Sometimes it's just repackaging. Running the numbers through a TCO calculator before you sign helps separate "this upgrade pays for itself" from "we're paying more for a feature we won't use."
4. Nobody budgeted for adoption
The most avoidable failure: Kessler turned on the AI purchase-order recommendation feature the week it shipped, with zero training. Buyers who'd approved POs the same way for six years suddenly saw a system-generated recommendation next to every line item, with no explanation of the model's confidence level or what data it used. Two buyers ignored it entirely. One followed it blindly into a $14,000 duplicate order because the recommendation engine hadn't accounted for a rush order placed outside the normal cycle.
Vendor AI rollouts almost never include a training budget line, because the vendor's job ends at "feature is live." Yours doesn't. Before any AI feature goes live for end users, run it in shadow mode for 30-60 days — visible to a pilot group, not driving decisions — and use that window to document where it's reliable and where it isn't. Budget actual training time for the team that will use it daily, not a five-minute release-notes email.
Not everything the vendor calls "AI" actually is
A second, quieter dynamic is worth naming: a meaningful share of "AI-powered" features shipping in ERP release notes right now are relabeled automation that's existed for years, given a new name to fit the marketing moment. When Kessler's IT lead pushed the vendor for specifics on the PO recommendation engine, it turned out to be a threshold-based reorder calculation nearly identical to a feature the same vendor had shipped three versions earlier under the name "smart reorder points" — same logic, new label, no actual model behind it.
There's a simple test for this: ask the vendor directly whether the feature is a trained model that improves with more data and use, or a fixed rule set that behaves identically on day one and day 500. Ask what data it was trained on, whether it's retrained periodically, and how you'd know if its accuracy changed. A vendor who can answer specifically is describing real machine learning. A vendor who answers with "it uses advanced algorithms to optimize your workflow" is describing a rules engine with a new coat of paint — which isn't necessarily bad, but it changes what you should expect from it, and it means budgeting for "the AI will get smarter over time" is budgeting for something that isn't actually going to happen.
Mid-contract leverage most customers don't use
None of this has to wait for the next renewal cycle. If an AI feature ships broken, underperforms what was promised in the sales pitch, or causes a documented incident like Kessler's $14,000 duplicate order, that's leverage you can use immediately, not twelve months from now. Vendor account managers, particularly ones carrying a retention quota, often have more discretion than they let on to adjust fees, extend a lower-tier price, or waive an upgrade cost outside the formal renewal window, especially in the weeks right after a rocky feature launch when the vendor's own product team is watching adoption and complaint metrics closely.
The mechanism that works best isn't a vague complaint call, it's a short written summary: what was promised, what actually happened, the dollar cost of the incident, and a specific ask. Kessler's team sent exactly that after the duplicate order — three paragraphs, one number, one request — and got a waived upgrade fee and a commitment to a dedicated onboarding session for the recommendation feature, months before their renewal date. Vendors respond to specificity. A general complaint that "the AI feature isn't working well" gets a form-letter apology; a documented incident with a dollar figure attached gets escalated internally, because it's the kind of thing that shows up in a churn-risk report.
What a vendor-led rollout looks like versus a scoped one
| Vendor-led (default) | Internally scoped |
|---|---|
| Feature ships tied to a mandatory edition upgrade | Feature is evaluated against your own bottleneck list first |
| Data handling terms are implied, not written | Data training and retention terms are a signed addendum |
| Goes live for all users on release day | Runs in shadow mode with a pilot group for 30-60 days |
| Training is a release-notes email | Training is a scheduled, budgeted session with real transactions |
| "AI" label taken at face value | Vendor asked directly whether it's a trained model or a relabeled rule set |
None of this requires refusing AI features on principle. It requires treating "the vendor added AI" as a starting point for a conversation, not a decision that's already been made for you. The customers who get burned aren't the ones who adopt AI features late — they're the ones who adopt them on the vendor's timeline instead of their own.