When an IT supplier and a customer enter into an agreement, it may seem obvious what each party can expect: the supplier delivers a service or product, and the customer pays for it. In practice, however, disputes about these mutual expectations arise time and again (often only when a project fails, runs over, or a service underperforms). Only then do parties turn to the contract, asking: what was actually agreed? And, more importantly from a legal perspective: was the supplier merely required to use best efforts, did they have to deliver a specific result, or did they even provide a guarantee?
In this blog, I discuss the three types of obligations found in virtually every IT contract and explain why the distinction can have far-reaching legal and financial consequences.
Why Does This Distinction Matter?
The law provides that any failure to perform an obligation requires the debtor to compensate the creditor for the resulting damage, unless that failure cannot be attributed to them. Before a customer can successfully hold their supplier liable, it must therefore first be established that there has been a failure to perform. This is precisely where disputes often arise: has the supplier actually failed to meet their obligations? To answer that question, we need to look at the nature of the obligations resting on the supplier.
The Best Efforts Obligation
The best efforts obligation is the lightest of the three. The supplier commits to making reasonable efforts to achieve a certain goal but is not legally accountable for actually achieving that goal. Whether the intended result is in fact achieved is therefore not decisive in determining whether there has been a failure to perform.
The Results Obligation
A results obligation is one step heavier. Here, the supplier commits to delivering a concrete result described in the contract. If that result is not achieved, the failure to perform is in principle established, regardless of how much effort the supplier has made. The customer does not need to prove that the supplier did too little; they only need to show that the agreed result is missing.
This does not mean, however, that the supplier is automatically liable for damages. The law still provides an escape: if the failure cannot be attributed to them (force majeure), no damages are owed.
The Guarantee Obligation
A guarantee is the heaviest commitment a supplier can take on, going further than a results obligation. By providing a guarantee, the supplier in principle accepts the risk that the guaranteed commitment is not fulfilled, even if the cause would not normally be attributable to them. In other words, by giving a guarantee, a supplier may lose the ability to rely on force majeure.
Pitfall 1: Making the Label More Important Than the Substance
In IT contracts, parties often assume that the chosen term is decisive. If "guarantee" appears above a clause, they think it constitutes a guarantee. And if a contract states generally that "all obligations of the supplier are best efforts obligations", the risk of results obligations seems to be covered.
It is not that simple. The classification of an obligation is not determined solely by the chosen label, but above all by the substance and context of the agreement. A general best efforts clause, for example, offers little protection if a specific commitment is made elsewhere that a connection, migration, or implementation will be delivered in working order by a certain date. In such cases, the substance of the agreement may outweigh the label the parties have attached to it.
Key takeaway: ensure that the chosen label aligns with the substance of the agreement. If an obligation is intended as a best efforts obligation, avoid language that nonetheless promises a specific result. And if a result or guarantee is agreed, specify exactly what the obligation covers, when it has been met, and what exceptions apply.
Pitfall 2: Underestimating What You Need to Prove
With a best efforts obligation, the dispute is not about whether the desired result was achieved, but about whether the supplier made sufficient efforts. Customers often underestimate this. They point to the failed project or the non-functioning solution, when what they actually need to demonstrate is that the supplier did not act as agreed and as could be expected from a reasonably competent and diligent professional.
That proof is difficult, because much of the work is not visible to the customer and the technical expertise typically lies with the supplier. That said, the supplier may be expected to provide insight into what they did and why those efforts were sufficient. This does not automatically shift the formal burden of proof, but the supplier may have an enhanced duty to explain.
Key takeaway: for best efforts obligations, specify how the supplier will make their efforts transparent (for example, through progress reports, meetings, documentation, and arrangements for cooperation and escalation).
Pitfall 3: Agreeing on a Result Without a Yardstick
A results obligation only has value if it is precisely clear which result must be achieved. This is often where IT contracts go wrong. Parties agree, for example, that a system, connection, or migration must be delivered "in working order", without specifying what "working order" actually means.
This leaves it unclear which functionalities will be delivered, what technical and functional requirements the solution must meet, what performance standards apply, and when the result must be delivered at the latest. If concrete acceptance criteria and a structured acceptance process are also missing, disputes quickly arise about whether the result has actually been achieved.
Key takeaway: make the agreed result measurable. Specify the functionalities, specifications, deadlines, performance requirements, and acceptance criteria that apply. Without that benchmark, a results obligation is difficult to enforce in practice.
Pitfall 4: Formulating Guarantees Too Broadly
In IT contracts, the word "guarantee" is often used to inspire confidence or to reinforce a commercial promise. Think of wording such as: "we guarantee that the software works", "we guarantee a rapid implementation", or "we guarantee full compatibility with your existing systems". This sounds reassuring, but can have greater legal implications than intended.
A guarantee may mean that the supplier accepts the risk of non-performance, even when the cause would not normally be attributable to them. This can limit or even exclude the possibility of relying on force majeure. That makes a guarantee considerably heavier than an ordinary results obligation.
Key takeaway: use the word "guarantee" only deliberately and define its scope clearly. Specify exactly what the guarantee covers, how long it applies, what exceptions apply, and what the legal consequence is if the guarantee is not met.
Conclusion
The distinction between a best efforts obligation, a results obligation, and a guarantee is not a legal technicality but has far-reaching consequences for the allocation of risk, the burden of proof, and ultimate liability. The pitfalls discussed above are just a few of the many that can arise in practice. They also illustrate how important it is to choose the type of obligation deliberately and to record it consistently in the contract. Those who do so when entering into the contract avoid unnecessary disputes and potentially costly surprises later on.
Curious which other pitfalls can trip up your IT contracts? Read the rest of the series, or contact us for a tailored review of your IT contracts.
