Why it’s wise to include a non-tacitated receipt?

Partagez cet article

Articles À la Une

The development phase of an IT tool ends with the acceptance phase, which can be either tacit or express. While it is often in the service provider’s interest for this acceptance to be tacit, this is not always the case on the customer’s side.

The end of the development phase for a software tool, whether it’s a web platform, an application or software itself, is what’s known as the acceptance phase. Its aim is to confirm that the deliverable ordered and expected complies with the specifications and needs expressed by the client. It is often the case that the acceptance phase is not organized, or that it is planned by the service provider in a tacit manner. Sometimes, it is planned that the acceptance be pronounced expressly, following the test phases.

IT service providers will often explain that a tacit acceptance must be provided for, as otherwise the project can be never-ending, as the client often “drags his feet” in carrying out acceptance tests and validating the deliverable. But is it a good idea to accept this?

First of all, it’s worth remembering that one of the client’s essential obligations in an IT development project is to participate effectively in the project, and not unreasonably slow down the contractor’s work. If an acceptance test is scheduled, the client must also keep to the timetable. Moreover, if no acceptance report has been signed, but the IT solution has begun to operate, judges will tend to consider that the client has accepted the deliverable (all the more so if he has written to his service provider expressing his satisfaction, and the post-warranty maintenance period has effectively begun with the payment of the corresponding invoices).

However, a tacit acceptance and the absence of an acceptance report has several disadvantages for the client.

Firstly, it does not allow any reservations to be expressed about the deliverables, and the work to be carried out by the service provider to resolve these reservations should be included in the initial development budget, and not in the maintenance envelope if the anomalies are reported within the warranty period.

Secondly, the acceptance report which is a contradictory and dated document, enables the warranty period to start with a definite date, during which the service provider must still correct any anomalies with regard to the specifications, at his own expense.

It is therefore advisable to include an express acceptance clause, with precise conditions adapted to the project and to the client’s technical (or not) teams who will have to validate the deliverables.

However, it’s not enough for the contract to stipulate the obligation of a written acceptance to give you complete peace of mind. In practice, the acceptance phase should not be taken lightly. The client (who is often pressed for time at the end of the project and in a hurry to get the system into production) must make a real effort to check for any reservations and report them. An acceptance report signed by the client will serve as proof before the courts that the expected deliverables have been met, that the service provider has fulfilled and finalized his mission, and that the client must therefore pay the balance of the service. What could be more damaging than having an IT solution that doesn’t work properly, with an obligation to pay and no means of exerting pressure on the service provider?

Successful IT development requires a balanced mix of the service provider’s technical expertise, the client’s collaboration throughout the project, and the alchemy between the legal provisions of the contract and the way the client’s teams operate.

Don’t hesitate to contact the experts at MIIP – MADE IN IP about these issues!

Charlotte Urman / Trademark Attorney