ERP Copilots: What Actually Works

Every vendor published a press release last year. "Meet our new AI copilot." "Introducing intelligent workflow assistance." SAP, Oracle, NetSuite—even the mid-market players. The messages sound identical because they are. But I've actually used most of these things, not just watched the demos. And I need to tell you what I actually see.

Most of them are good autocomplete wrapped in flashy UI.

That's not a joke. I mean it literally. You start typing a vendor name or a line item description, and the system finishes it for you. Smart autocomplete based on historical patterns. It's useful. I'm not dismissing it. But vendors are calling this "AI copilot" because marketing realized "autocomplete" doesn't move the needle in enterprise deals.

The ones that actually work—and there are maybe three—do something different. They're built on a different assumption: that the copilot's job isn't to complete what you're typing, but to complete what you're thinking.

The Real Test

Here's how I tell the difference now. I ask a question that requires the system to:

1. Understand the current state (what orders are pending, what's late, who's the key vendor)
2. Connect across three data sources simultaneously
3. Recommend an action that makes sense in context
4. Surface the reasoning so I can override it if I need to

Most copilots fail at step one. They don't actually understand your current state. They pattern-match on keywords. They're trained on generic ERP data, not your data.

The three that work—and I won't name them because this isn't a vendor review—all did one thing differently. They spent engineering effort on a data layer that sits on top of the ERP system. Not integrated into it, but sitting above it. That layer normalizes the data, makes it actually queryable, and gives the LLM real context to work with.

That costs money. That costs architecture decisions. That costs ongoing maintenance. So most vendors skip it.

What we're seeing instead is a watered-down version: copilots trained on preprocessed, anonymized datasets that give the appearance of understanding your specific business. They work well in screenshots. They work less well when your vendor structure has a custom naming convention or your business process has a deviation from the standard flow.

The Pattern I'm Noticing

Every CTO I talk to right now is asking the same question: "Should we build our own copilot or wait for the vendors to mature theirs?" I'm seeing companies go both directions. The ones building their own are moving fast because they're not constrained by the vendor's data architecture. The ones waiting are betting that the vendors will figure it out this year.

I think both bets are wrong. The real opportunity isn't building a copilot; it's building the data foundation that makes copilots useful. The companies winning right now aren't the ones with the cleverest AI model. They're the ones with the cleanest data and the clearest understanding of what they're trying to automate.

SAP has been talking about their "Joule" copilot since early 2024. It's better than their initial release, but it's still fighting the same constraint: SAP's internal data model doesn't expose the context that a copilot actually needs. That's a legacy problem. They can't fix it without breaking backward compatibility with thousands of implementations.

Smaller vendors don't have that problem. They can build the data layer correctly from the start. That's why I think we're going to see a bifurcation in 2025. The large vendors will ship copilots that work fine for common scenarios. The smaller, newer vendors—the ones unencumbered by legacy constraints—will ship copilots that actually work for your specific scenarios.

What I'm Watching

I'm tracking three capabilities that separate the real ones from the theater:

First, whether the copilot can operate on incomplete data. Real workflows have gaps. Vendors are out of stock. Data is stale. A real copilot should flag these gaps and still give you actionable advice. Most copilots just fail silently or return generic guidance.

Second, whether it can reason about constraints. Not just "here's what you could do" but "here's what you could do given that you've already committed to those three suppliers, given that your cash position is here, given that your lead times are there." That requires the copilot to have modeled your constraints, not just looked at your data.

Third, whether it works offline, or at least gracefully degrades when your connection is sketchy. Enterprise software runs everywhere. Sometimes the data center connection drops. A copilot that can't handle that is a copilot for people who never leave the corporate network.

The vendors who nail those three will win in 2025. The rest will keep shipping the autocomplete with better branding. Both will claim to be AI-powered. Only one actually is.

I'm betting the category matures faster than people think. We've stopped being impressed by the technology. Now we're asking whether it actually reduces the time it takes to close a PO or flag a supply chain risk. The ones with the answer will see adoption accelerate.