Common mistakes in IT contracts and how to avoid them

Every company has to deal with it these days: IT contracts. These might include a software license agreement, a maintenance agreement or, for example, a purchase agreement for all kinds of different hardware, etc. What are common mistakes in these types of contracts and how can they be avoided?

To answer that question, we must first zoom out and look at the nature of an IT contract. This is because most IT contracts are simply assignment agreements. However, case law has elaborated on the special duty of care of IT suppliers - after all, an IT supplier must behave as a good contractor during the performance of its work (section 7:401 of the Civil Code). If a contract contains certain gaps or ambiguities, these are filled in using this duty of care. What this duty of care entails in a specific case strongly depends on the circumstances of the case. There have been many judgments in recent years that give more direction to this, but if a contract is unclear or contains gaps, a dispute about the scope of this duty of care often arises.

How do you avoid this problem? It sounds simple: make sure you conclude good and clear contracts, without gaps. By the way, this is not only in the interest of the IT supplier, but also in the interest of the client. Concluding a good clear contract with few gaps may sound obvious and simple, but then you need to know how to draft a good IT contract and what to watch out for. Below you will find some common mistakes and the corresponding tips.

1. Wrong designation/uncertainty about development method

If an IT contract deals with the development of software, things often go wrong when parties do not make it clear what kind of development method they choose. For example, is there agile development - flexible development where the supplier starts working immediately, using sprints and requirements become clear during development and scrums are used regularly? Or has a waterfall method with several predefined phases been chosen? Make it clear well in advance which method or methods will be used, so that it is clear what parties can expect from each other.

2. No or unclear descriptions of the minimum requirements of the product

The parties may not yet know in advance exactly what a product (such as software) must be able to do, or the minimum requirements for a product may change during product development. To avoid disputes, even if this is not yet possible immediately, we recommend establishing Key Performance Indicators ("KPIs") that a product must meet as soon as possible. If the contract has already been concluded and KPIs are only established during product development, we recommend explicitly including this in an addendum. This way, it is clear to all parties what the product must be able to do and parties can determine (or have it determined) whether the product meets the requirements.

3. Failure to exclude and/or make a clear distinction between direct and indirect damage

As an IT supplier, it is necessary to distinguish between direct and indirect damage and exclude the latter type of damage. Incidentally, this is also industry customary. However, we often see that if indirect damage is excluded, indirect damage is subsequently not defined in the contract. However, under Dutch law, indirect damage is not a well-defined concept. Parties can therefore get into a dispute as to whether certain damages should be seen as indirect damages. Therefore, if a company wants to exclude indirect damage, the company would be wise to clarify what the party sees as indirect damage (e.g. does it include loss of profit, fines from authorities, consequential damage, etc.).

4. Maintenance and management

Parties often fail to make clear agreements on software maintenance and management. Therefore, work with a clear Service Level Agreement ("SLA") describing the conditions under which the IT supplier provides maintenance and management services and clearly stating what kind of work is covered by these maintenance and management services. Minimum response times for the IT supplier can be used for this. A nice additional advantage for the IT supplier is that a good SLA can also directly limit the IT supplier's liability.

5. Poor acceptance procedure

If an acceptance procedure is chosen for the product, ensure that the conditions for acceptance are clearly included in the contract and work as much as possible with measurable factors, such as KPIs. It is very important here that the acceptance procedure is (at least partly) in the hands of the IT supplier - this prevents a hostage situation by a customer who wrongly claims that the product does not yet meet the (barely described) requirements.

6. Best Effort/obligation of result

Be aware of the difference between an obligation to use best efforts (in Dutch: “inspanningsverbintenis”), where the other party only undertakes to deliver a certain effort, and an obligation of result (in Dutch: “resultaatsverbintenis”), where the other party undertakes to deliver a certain result. It is is a lot harder to prove that a party is not complying with an obligation to use best efforts. As an IT supplier, you can play with this in the contract when developing new software.

7. Use of warranties, without explanation of the term warranty

Similarly, the term warranty (in Dutch: “garantie”) is not a well-defined concept under Dutch law. If parties want to use a warranty, make it clear what this warranty entails and what one party is entitled to if the other party does not comply (e.g. to compensation for damages or, if possible, repair or delivery of a replacement product).

8. Escrow perils

If parties wish to use an escrow (depositing the source code of software with a designated third party, the escrow agent), make it clear from when the escrow is required and ensure that clear (not subjective!) terms and conditions are established under which this software will be released. Also agree clearly on who bears the costs for this.

To learn more about IT contracts under Dutch law, the tips above or simply to spar about the content of this blog, contact Matthijs Gardien and Merel van Bunge.