“Stop selling fear. Our ERP has been running in Europe as SaaS for years.”
A managing director from the machinery and plant engineering sector told me this in a workshop. Two things about it are true. The data is already in Europe, and nobody needs to bring their ERP back from the cloud into their own data centre for that. And for most processes, the AI from the ERP vendor is the right choice.
I know these platforms from my daily work. NXTGN earns its money with consulting and system integration on Dynamics 365, Dataverse and the Power Platform, and for most processes I recommend exactly these platforms. Something has changed nonetheless, and it is not where the data is stored. What has changed is what it costs to get to it.
From purchase to billing per transaction
For a long time, enterprise software was bought: the licence once, then maintenance every year. That is rare today. Then it was rented per user and month. Now billing per transaction is being added, in so-called credits, and I expect it to gradually replace the per-user rent. Credits are no longer charged only for agents. Every answer an assistant generates costs credits too, as does every question to the company's knowledge and every document page processed.
Many ERP and CRM licences come with an allowance of credits, pooled for the whole company. That sounds reassuring, but it only shifts the problem. Once the allowance is used up, you have to feed the meter, meaning buy more credits or pay as you go, so that the agents keep working. If you do not, the platform switches them off. One vendor describes this in its own documentation: if usage is a quarter above the prepaid allowance, the agents are deactivated, and anyone who calls them is told the agent has “reached its usage limit”.
A person works overtime in a busy week. An agent stops when the credits run out. This makes credit-based billing unpredictable, even if many credits are included in the licence. What a month costs depends on how much work the agents have, and that is exactly what nobody knows in advance.
The software itself did not change much with any of these shifts. What changed is who counts and what is counted. And something is now being counted that used to be free as a matter of course: another system reading your own data.
What changes in small steps
In 2024 I would still have said that the data belongs to the customer, so the customer can get to it. That is no longer a given. There was no big bang and no press release. Sometimes it is in the vendor agreement, sometimes it is announced, and sometimes it is only vaguely prepared. Each individual step is too small for an outcry, and I suspect that is intentional.
Four examples from the last two years, all publicly documented:
- In early 2024, a large ERP vendor informed its customers that tools from other providers may no longer use a certain interface to read data from its system. Six months later came the recommendation to use its own, separately licensed product for this purpose.
- In May 2025, a team communication platform changed the terms of its interface. Since then, other applications may no longer export the data in bulk, create persistent copies or search indexes, or use the data in language models. Anyone who had built a small AI application on their own archive had to rework it.
- Another vendor discontinued the feature that allowed customers to export their ERP data to their own data store. One of the two successors keeps the data in the vendor's storage, for a fee beyond the licence allowance. The other still writes to the customer's own storage but is considerably more complex to set up.
- And one platform counts, per licence, how many queries reach the data each day. The limits are already defined, they are just not enforced yet. When they will be, the vendor leaves open. There is no way around it: according to the documentation, the same limits apply to tools from other providers.
On its own, each of these steps has a justification, usually security or platform stability. Put them side by side and a trend appears.
How to spot it in vendor agreements
The vague preparation is the hardest to see, because at first it costs nothing. It is worth looking out for wording like this in the next vendor agreement or the next announcement:
- “reasonable use” without a number, which later gets a number;
- a technical cap on queries that initially serves to “protect the platform” and later gets a price;
- a new integration product from the vendor, next to which the old route still works but is no longer maintained;
- “The vendor reserves the right …”
My advice is to ask about the cap while it has no price yet, and to get in writing what applies once it does. And if you do not want the interface terms to be changed unilaterally, settle that with your software partner while it still costs nothing.
Software without a head
On top of this comes a restructuring that is just beginning in ERP and CRM. It is called “headless”. Vendors separate data and business logic from the application people use to operate the software. That application then becomes just one access point among several. I expect the most important user of the data to be an agent that works directly on it and is billed per transaction.
For vendors, this has a simple consequence. When fewer and fewer people operate the software, it can no longer be billed per user. Payment is then per transaction and for access to the data. I wonder whether management and IT leadership already know how their software partners intend to make money in future.
Tenants on someone else's land
I call this data feudalism. The word is big, the mechanism is simple. A company pays whoever owns the platform its data sits on, and it pays three times: when entering the data, when using it, and once more when it wants to get it back out.
With agents, it goes further. An agent that works without the application lacks the knowledge that used to be built into it, such as which check happens on the form or when someone hesitates. Whoever teaches it this knowledge at the vendor then pays per transaction to use it. And it is hard to get back out. A configured ERP can be exported, a trained agent hardly at all. I consider this the real dependency. How much of it a company takes on is something it has to decide for itself, before the vendor decides for it!
Ending it does not mean building everything yourself
Most agentic processes can be bought off the shelf. An agent for invoice checking does not need to work any differently than at a competitor. It is different for the handful of processes that set a company apart from its competitors. When agents take over this work, the difference will lie in the agents. Anyone who covers these processes with the vendor's ready-made agents will then work like the average of their competitors. The lead turns into a commodity.
I also have a second interest here, because I am building such a system myself. That is why NXTGN AI CORE has to be measured by the same standard. It runs on your own servers or at NXTGN, in a dedicated environment just for you, and there credits play no role. Whether a month is quiet or busy makes no difference to the bill.
My conclusion
To the managing director in the workshop who told me to stop selling fear, I replied: “I am not selling fear, I am selling a sequence.” First assess which processes define a company, then decide for yourself how much dependency to allow there, and only then deploy agents.
For most agentic processes, the vendor is the right place, and nobody needs to be afraid of that. But I would keep the handful of processes that set a company apart in my own hands. That is where agents create the lead over the competition, and you do not lease that out.