A few days ago another ERP implementation contract landed on our desk. Three times twenty-plus pages, annexes. We read everything and honestly held our heads.
Sometimes a contract is written to protect both sides. Sometimes we read contracts and see nothing but a very cleverly constructed machine for long-term milking of the client. The vendor knows what they are doing and acts with cold calculation — cynicism, even. That is probably why we wrote this post.
If you find several of the points below in your contract, stop seriously and ask whether you want this arrangement — and whether the relationship is worth it. We grouped them into four key risk categories so you can spot the attack vectors on your business more easily.
Basket 1: Financial traps (milking the client)
Clauses whose sole purpose is to generate endless costs beyond the original implementation budget.
1. Bespoke modules and endless top-ups
Every element can be classified as bespoke. In theory every element will be built from existing modules. It should be quick and easy — but the contract refers to an audit document.
“The Contractor accepts the theses and conclusions contained in the audit document and will provide services on that basis.”
That document describes needs in general terms: processes, areas, directions. It does not describe functions. It does not say how many fields a form should have, how a specific report should work, which validation rules apply to an order, or what was already priced in.
“In the case of bespoke solutions the auditor supervises the process in order to present a separate price offer for their delivery, testing, and final handover.”
Every deviation from the simplest version is a new offer. A new offer means new hours. New hours mean a new invoice. There is no upper limit on those invoices, no schedule that foresees them, no mechanism that stops them.
The same endless top-up mechanism applies to communication. Watch out for billing every started quarter-hour of phone conversation (even when initiated by the vendor), which leaves no binding written agreements behind — only inflates the monthly bill.
2. Invoice every month — no stage closure
“An invoice for the services listed will be issued at the end of each month.”
With no information on whether the service was closed or what the state of work is.
You pay for time, not for outcome. Invoices arrive every month regardless of how much was actually delivered on the project. That motivates the vendor to stretch the rollout, not to deliver a working system quickly.
Basket 2: Legal vendor lock-in (no exit)
Clauses that tie you to the vendor for years and cut off any escape route.
3. Paying for code or for a perpetual licence? Or ending up with no code and no product rights?
“The subject of this agreement is the grant of a non-exclusive licence for an indefinite period” and “Creator XYZ retains ownership of the SOFTWARE, and the Buyer, by accepting the licence terms, obtains specified rights to use the SOFTWARE.”
We found wording like this hidden in two contracts. The effect is simple. You pay for code that will never be yours. You invest hundreds of thousands — sometimes over a million — in fitting the system to your company.
And in the end you get neither copyright nor source code. You are only a user in your own system. Do you really want to pay €80,000 or €350,000 never to be the real owner of what you paid for?
4. Modification ban — vendor lock-in
“The User may not attempt to reverse-engineer the source code of the Software, make modifications or translations, or create derivative products based on the Software.”
And similar clauses often mean you have code but still cannot touch it. The licence frequently forbids modification by another software house. That is classic vendor lock-in. You are tied for good with no exit when something does not suit you. You pay for fixes.
5. Disputes in the vendor's city
Disputes will be resolved in their city. The court with jurisdiction at the vendor's registered office. That always works in their favour. If it comes to it, you can always drive 400 km.
6. Hidden marketing consents in the package
By signing the contract you grant marketing consents nobody showed you. Bundled with the implementation and service agreement are two consents nobody discusses at the sales meeting. The first concerns your contact data. The second concerns your logo and company name.
Basket 3: Liability asymmetry (you pay for mistakes)
Mechanisms that shift all business risk from the vendor onto your company.
7. Hard cap on vendor liability
A fairly common clause that can be paraphrased as:
“The Contractor's total liability to the Client arising from or in connection with this Agreement shall not exceed X% of the net remuneration paid to the Contractor in the Y months preceding the event causing the damage.”
Or, more creatively:
“If the Contractor accepts the Client's claim, the compensation due to the Client may not exceed the remuneration paid to the Contractor for the stage to which the claim relates.”
Their liability has a hard ceiling. Even if they admit fault, at most they return what you already paid them. All larger losses stay on your side. Maximum up to X% of remuneration paid.
8. Exclusion of liability for lost profits
“The Contractor's liability for lost profits on the Client's side is excluded.”
If the system goes down, you bear all the losses. The contract excludes vendor liability for lost profits, which often pairs with the liability cap described above. The system is down for a week, sales stall, clients leave, and you will not recover a penny of those losses.
9. Contract termination after 14 days
“Failure to remedy irregularities on the Client's side within 14 days entitles the Contractor to terminate the agreement with immediate effect.”
They can walk away from the project whenever they want. You do not fix some irregularity within fourteen days? They can tear up the contract and keep all the money you already paid them.
10. Delays always on your side
“In situations of lack of cooperation on the Client's side, the above deadlines are extended by twice the period during which lack of cooperation occurred in performing the agreement on the Client's side.”
That was the only clause about delays.
All delays are your fault. Your obligations are described in detail with specific deadlines. On the vendor's side there is usually only “due diligence”. If you are late by even one day, their deadlines automatically double. A very convenient mechanism for them.
11. Five days for objections — then “accepted”
“Failure to submit written objections within the stated deadline means the Client has accepted the subject of the agreement without reservation.”
You do not raise objections within five days? The system is accepted. They deliver an acceptance protocol. You have only five business days to submit remarks. You miss that through illness, holiday, or anything else — and the system is automatically deemed accepted.
12. “Third business day” instead of SLA
“Remedial work will commence no later than the third business day after the day the ticket is submitted.”
Dear reader, there is such a thing as an SLA. An SLA is a Service Level Agreement — a service contract that clearly defines how fast the vendor must respond and fix defects. We usually record a table with categories. Instead of “commencement of remedial work” the contract must define concrete response times, workaround times, and fix times for each defect category. E.g. critical defect stopping work: response time 2h, fix time 8h.
“Third business day” is meaningless empty words with no consequences — they only talk about their start, not completion or guarantee. Worse, they cost you money. If service dies at 4 p.m. on Friday, you are probably waiting until Wednesday.
Basket 4: Innovation blockade — how an ERP contract forbids you to grow
Clauses that will prevent you from integrating your company with new technologies (including AI) in the coming years.
13. Single instance and terminal connections
“The User may use only one server instance of the software.” And “Remotely using terminal connections.”
In a few years you will be buying AI from them that others already have today. One server instance, workstations, terminal connections. That is client-server architecture from the turn of the century. Microsoft Dynamics, SAP, Odoo today ship built-in AI copilots, open APIs, and module marketplaces. Adding AI to a terminal architecture means rewriting the system from scratch. And you know who will quote that.
14. Ransom for access to your own data (data ransom / API tax)
“Data entered into the system is the exclusive property of the Client.”
Sounds safe, right? The devil is in the detail: the contract does not specify export format or cost. Six months later you want to plug in a light, agile system — say a voice interface or a predictive algorithm — and API documentation does not exist. Every attempt to pull your own data out is a “non-standard integration” priced at tens of thousands. You own the data, but the vendor holds the key and charges for every door opened.
15. Licensing dead souls and artificial system accounts
You pay per so-called named user (a specific employee), not concurrent use. Worse, if you want any automation script, external AI agent, or even a simple Make flow that queries the database, the vendor classifies it as an “integrating user”. They impose the highest, abstract monthly fee on it. You pay a penalty for optimising processes.
16. Update blackmail (end-of-life blackmail)
“Warranty and SLA response times apply only to the current version and one version back of the Software.”
After two years the vendor releases a “new” version that differs mainly in button colour but forces you to buy a paid upgrade. If you do not, you lose technical support you have been paying for all along. That is de facto forcing continuous licence fees under threat of no fixes for system defects.
We read all three documents. The client has ten pages of obligations, deadlines, and penalties. The vendor has “due diligence” and the right to terminate when the client cannot keep up.
A contract that protects only one side is not a contract. It is an ambush.