The amended Civil Code, which came into effect on April 1st in the second year of Reiwa era (2023), has changed the responsibility of contractors in entrusted development (contracting agreements) from liability for defects to liability for non-conformity. While both types of responsibility are borne by the contractor towards the user, many people do not fully understand the differences between them. It is important to understand these differences in order to avoid potential troubles when requesting system development services.

Difference between defect warranty liability and contract non-compliance liability

Before the enforcement of the amended Civil Code in the second year of Reiwa era (2023), both entrusted development (contracting agreements) and System Engineering and Support (SES) were subject to liability for defects. Here, we will explain the four differences between liability for defects and liability for non-conformity, as well as the responsibilities that vendors bear in SES.

Four differences between liability for defects and liability for non-conformity

In entrusted development (contracting agreements) for system development, even under the pre-amended Civil Code, the following three rights were recognized when there were deficiencies in the completed system:
・Right to claim for repair
・Right to claim for damages
・Right to terminate the contract

Based on this, the amended Civil Code now recognizes the following four rights (Civil Code Article 636):
・Right to claim for completion
・Right to claim for reduction of price
・Right to claim for damages due to non-performance
・Right to terminate the contract due to non-performance

When comparing the responsibilities of contractual non-conformity liability and defect warranty liability, it can be seen that the amendment to contractual non-conformity liability has expanded the rights of the user (buyer) side. For example, under defect warranty liability, the right to claim for repairs was only recognized in cases where hidden defects were found in the delivered system.

However, under contractual non-conformity liability, the options for claiming have increased, including the right to claim for complete performance or reduction of price for deficiencies that do not conform to the contract. In addition, the period during which liability can be pursued has been extended to one year from the time the non-conformity was discovered, making it easier for the user side to make claims.

Is there no contractual non-conformity liability in SES (Quasi-delegation contract)?

In system development, not only contract-based development, but also a contract type called SES (Quasi-delegation contract) is often used. Unlike contract-based development, SES is a contract form where remuneration is paid for the performance of delegated work, rather than the delivery of deliverables. And, under SES, the liability borne by the vendor is defect warranty liability, not contractual non-conformity liability.

There are two types of SES contracts, "completion-type" (Article 648-2, paragraph 1 of the Civil Code) and "performance-ratio-type" (Article 648, paragraph 2 of the Civil Code). In SES contracts for the purpose of system development, where compensation is paid for the results achieved as a result of the work, many fall under the completion-type. Therefore, even in the case of SES, the vendor is required to deliver the system in order to generate compensation, and if they cannot deliver, they are liable for non-performance under the law.

Furthermore, in SES contracts, the vendor has a duty of care (Article 644 of the Civil Code) and must fulfill the obligation to perform the work with the skills and knowledge required as someone involved in system development. It does not mean that the responsibilities to be fulfilled by the vendor are substantially reduced just because they do not bear the responsibility for non-conformity under the SES contract.

Case Examples of Troubles in System Development

Now that we understand the overview of contract non-conformity liability and defect warranty liability, in this chapter, we will explain two specific cases where these liabilities have been recognized.

Case where defects were judged based on the purpose of the contract (Tokyo District Court judgment, December 22, 2004)

Overview

The user commissioned the vendor to develop a sales management system, but the delivered system had defects, and the user requested contract termination and damages due to the failure to achieve the contract objectives. The vendor refused and the case went to court.

Nature of Defects

The bulk inventory allocation process using migration data took more than 30 minutes, and business operations could not proceed during that time, and order registration processing could not be performed on other terminals either due to an issue with exclusive control. When the registration data of the product master was opened, the processing of all programs using the product master would stop due to the issue with exclusive control.

Judgment

The bulk inventory allocation process taking time and the issue with exclusive control do not conform to the contract requirements and can be considered as defects. The judgment of the Tokyo District Court on December 22, Heisei 16, determined that the system delivered for the commissioned development of the sales management system did not conform to the contract requirements and had defects that prevented the achievement of the contract objectives. In this case, the "speed of bulk inventory allocation process" and "exclusive control" were not included in the requirement definition.

In other words, based on the requirement definition, the developed system would have fulfilled its contents. However, the judgment was made based on the user's objectives in system development, rather than the requirement definition.

Case where the user's breach of cooperation obligation was recognized (Sapporo High Court judgment on August 31, Heisei 29)

Overview

An auction was conducted and a winning bidder was selected to start a project for the introduction of a hospital information system. However, due to continued additional specifications from the user, the project was delayed and faced issues, leading to development failure. The user requested contract termination and the situation escalated into a lawsuit.

Chronology

Even after the deadline for finalizing the specifications (specification freeze) had passed, the user continued to request additional specifications.

There were additional requests from the user even after an agreement was made for specification freeze.

Judgment

It was recognized that the user's breach of cooperation obligation, by making a large number of additional requests contrary to the agreement on specification freeze, caused delays in the system development.

In the judgment of the Sapporo High Court on August 31, Heisei 29, the user's breach of cooperation obligation was recognized, and the vendor was ordered to pay damages. In this precedent, it was determined that the user's cooperation obligation was not fulfilled in progressing the project, as there were numerous additional requests made after the specification freeze. While it is natural for vendors to have obligations in the development process, users also have a certain level of cooperation obligation as part of the contractual relationship.

Points to include in the contract to mitigate risks

Troubles in system development can happen to anyone, but everyone wants to avoid being involved in such troubles. Therefore, in this chapter, we will introduce contents that are good to include in the contract to avoid risks of being caught up in trouble.

Preconditions for the Contract

With the amendment from warranty liability to non-conformity liability, as mentioned in the previous chapter, it is possible that the focus may shift from whether the system has defects to whether the deliverables conform to the content and purpose of the contract. Therefore, the contract should include detailed descriptions of business scope, deliverable standards, delivery dates, system environment, etc..

Response Methods for Specification Changes, etc.

There are cases where oversights in specifications become apparent after the development stage has begun, and specification changes become inevitable. In such cases, including provisions in the contract regarding how to proceed with specification changes or additions, as well as the cost burden, can make subsequent responses smoother. It is recommended to include provisions regarding the procedures and cost burden for specification changes or additions to the extent possible.

Contents of Meetings for Smooth Business Progress

Many people may be unsure about what to communicate during meetings with vendors. This chapter will explain how to conduct meetings effectively in actual system development projects.

Clearly communicate the purpose of system development

The most important thing for the user to communicate when developing a system is the purpose of the system development. If the purpose is unclear, it may be difficult for the vendor to make proposals, and communication may break down before a contract is signed. Therefore, it is recommended to summarize what functions to implement and how to streamline business operations within the company. Creating an RFP (request for proposal) is also recommended.

If there is a possibility of specification changes or additions, inform in advance

If there is a possibility of specification changes or additions during the development process, it is recommended to inform the vendor in advance. Be as detailed as possible about which parts may be added or changed, and when they will be finalized. This allows the vendor to adjust the development schedule in advance and make proposals, reducing the likelihood of additional costs or problems.

In this article, we explained the difference between warranty liability and contract non-conformity liability in system development. At Jitera, we specialize in system development with SES (quasi-outsourcing contracts). With SES, warranty liability arises rather than contract non-conformity liability, but the responsibility for system development is not significantly different from what we explained in this article.

By filling out the inquiry form, you can request a quote for the type of system you want to develop and the functions you want to implement with just a few simple questions. This makes it possible to start meetings with a certain degree of clarity about the scope of work and delivery date. Jitera has its own development automation platform, which enables us to develop systems at a cost and delivery time that have never been seen before. Why not try a new system development experience with us?