What is Liability for Non-Conformity in System and Software Development Contracts? Explaining the Amendments

What should you do legally if there is an error after the delivery of the system you ordered?

If the operation is difficult, the processing speed is slow, or the ordered function is not equipped… As the order of the system, you will question the “Liability for Non-Conformity” to the vendor who developed the system.

“Liability for Non-Conformity” was newly established to replace the “Defect Warranty Liability” that was abolished by the amendment of the Civil Code in 2017 (Gregorian calendar year). Therefore, it is necessary to pay attention to how this amendment affects system and software development.

Troubles often occur after delivery. To avoid such troubles, we will explain the contents of “Liability for Non-Conformity” and the impact of the amendment.

Amendments to the Civil Code Regarding Liability for Non-Conformity

The law to amend part of the Japanese Civil Code was promulgated on June 2, 2017 (Heisei 29) and came into effect on April 1, 2020.

The part of the Civil Code that sets the most basic rules regarding contracts and the like is called the “Obligation Law” in Japan.

Since its enactment in 1896 (Meiji 29), the Japanese Obligation Law had hardly been revised for about 120 years.

The purpose of this amendment is to make significant revisions to adapt to current society.

Among the many specific amendments, the establishment of the concept of Liability for Non-Conformity is one of the main points of the amendment.

As a result, what was called “warranty liability for defects” in Japan has been replaced with “contractual non-compliance liability”.

What is Non-Conformity?

“Contract non-conformity” refers to the absence of the intended functionality, quality, performance, or condition, in light of the agreement between the parties and the purpose and nature of the contract.

This concept of “contract non-conformity” was introduced to replace the traditional concept of “defects” as a result of the revision of the Civil Code.

In the context of system and software development, “contract non-conformity” applies when the completed system does not match the pre-determined specifications, or when the system or software lacks the functionality or performance that it should normally possess, given its nature.

When determining the presence or absence of “contract non-conformity”, the agreement between the parties and the purpose and nature of the contract are emphasized.

Therefore, it is important to document the purpose of the system or software development and the order history, and to clarify what kind of requests or images the orderer had.

Cases Where Software Defects Constitute “Breach of Contract”

When Software Issues Cause Disruptions and Delays in Repairs

Firstly, we can consider cases where significant software defects occur that require a review back to the design stage for correction, and cannot be promptly addressed.

For example, there is a court case that recognized a situation as a “defect” that constitutes a “breach of contract” under the current Japanese Contract Law, where a disruption occurred, such as the search process of the introduced inventory inquiry system taking more than 30 minutes, and the customer inquiries had to be handled by creating a separate handwritten inventory ledger (Tokyo District Court, April 22, 2002 (Heisei 14)).

When Defects are Continuously Emerging

Also, we can consider cases where even if individual defects are minor and do not take time to correct, repeated defects occur, and it takes a long time to correct all defects and make the system function properly.

For example, if repeated defects occur in the introduced inventory inquiry system, and it is unclear how many defects will occur in the future and how long it will take to correct them, and it is not possible to carry out normal business operations using the system, it can be said to be a “breach of contract”.

Cases Where Software Bugs Do Not Applicable ‘Non-Conformity’

When Repairs are Made Promptly or Alternative Measures are Taken

In court precedents, even if a user points out bugs or other defects, it is judged that it does not constitute a ‘defect’ if repairs are made promptly or alternative measures deemed reasonable after consultation with the user are taken (Tokyo District Court, February 18, 1997 (Heisei 9)).

In the development of systems and software, it is impossible to program in such a way that no bugs occur at all, and it is inevitable that some defects will occur.

Therefore, even if there are defects, if measures such as prompt repair are taken, it should not be considered a ‘defect’.

This can be thought of in the same way under the current concept of ‘breach of contract’.

The basis for determining ‘without delay’ here is the evidence such as the minutes created during the process of system development.

When a Specific Individual Cannot Easily Understand the Operation Method

Regarding operability and usability, since they are largely subjective, it is considered a ‘breach of contract’ when it is not usable based on the standard of a general user.

Just because a specific individual cannot easily understand the operation method, it cannot be said to constitute a ‘breach of contract’.

When a Defect Occurs Due to Causes Unrelated to the Vendor’s Work

If a defect occurs due to causes unrelated to the development work of the vendor who develops the system or software, it cannot be said that there is a ‘breach of contract’ in the system or software itself.

For example, if a defect occurs due to trouble with hardware that the vendor is not responsible for procuring, it is not considered a ‘breach of contract’.

[Addition] When a Defect Occurs Due to User Instructions

If a defect occurs in the completed system or software due to incorrect instructions from the user, even if the system, etc. is recognized as having a ‘breach of contract’, the vendor will not be responsible for the breach of contract in principle.

For example, if a defect occurs in software developed based on agreed specifications due to incorrect explanations about circumstances that only the user can know in the development of a business system, the vendor has no responsibility whatsoever.

Behind such judgments, it is thought that there is a concept that the user, who is the orderer in software development, also has a ‘duty to cooperate’.

Claims that the Client or Buyer Can Make Based on Non-Performance of Contractual Obligations

Here, we will explain the content of non-performance of contractual obligations related to system and software development, taking into account changes due to amendments.

Request for Repair

If a defect is deemed to be a non-performance of contractual obligations, the client may request for the defect to be repaired.

Before the amendment, it was not possible to request for repair if the defect in question was not significant and the repair required excessive costs. This limitation has been removed by the amendment.

However, even after the amendment, if “the non-performance of the contract is not significant and the repair requires excessive costs”, there is a possibility that the request for repair may not be recognized as the repair is impossible.

Claim for Damages

If a system or software with a defect prevents normal business operations or incurs additional costs, the client may claim for damages.

Before the amendment, it was possible to claim for damages regardless of the presence or absence of negligence, unless there was a special agreement.

However, the amendment has made it impossible to claim for damages if the performer has a reason for exemption (a reason that cannot be attributed to the debtor).

Therefore, if the vendor can prove the reason for exemption, they will not be liable for damages.

Contract Termination

The development contract may be terminated on the grounds of non-performance of the system or software contract.

In a court case we have already introduced, the contract was terminated because the system introduced had to be abandoned due to defects such as the search process of the inventory inquiry system taking more than 30 minutes, the processing time being too long, and the terminal itself being unusable (Tokyo District Court, April 22, 2002 (Heisei 14)).

Before the amendment, the contract could be terminated only if the “purpose of the contract could not be achieved” due to the defect. However, this limitation has been removed by the amendment.

However, even under the amended law, it should be noted that if the degree of non-performance of the contract is “minor”, termination is not allowed.

Request for Reduction of Remuneration

The right to request a reduction in remuneration has been newly established by the amendment.

If there is a defect in the system and the client requests its repair, but the repair is not carried out even after a reasonable period of time, the client may request a reduction in remuneration.

Period of Liability

• Request for Repair
• Claim for Damages
• Contract Termination
• Request for Reduction of Remuneration

The period in which these rights can be exercised is limited.

Specifically, the rights can be exercised only if the client notifies the vendor within one year from the time they became aware of the non-performance of the contract in the system or software.

Before the amendment, the period for exercising rights was limited to “within one year from the time the system or software was delivered”. Therefore, it can be said that the period in which rights can be exercised has been extended by the amendment.

In addition to this time limit, the above rights recognized based on non-performance of contractual obligations are also subject to the provisions of the statute of limitations.

Therefore, for example, if you first become aware of a defect 11 years after receiving the system or software, the rights such as the right to claim damages have already expired after the “ten-year” statute of limitations, regardless of whether you notify the non-performance of the contract “within one year from the time you became aware of it” or not, you cannot exercise your rights.

Refusal to Pay Remuneration

The client can refuse to pay the full remuneration until the developer carries out the repair or pays damages.

Key Points in Contract Provisions Considering Non-Conformity

The provisions of non-conformity liability are optional, and the content of liability and the period for exercising rights can be limited or shortened by special agreement between the parties.

Here, we will explain the contract provisions that should be noted in relation to non-conformity liability in system and software development.

Point 1: Events and Scope of Non-Conformity

If there is dissatisfaction with the system or software, the client may want to pursue the vendor for non-conformity liability.

However, as a vendor, it is unacceptable to be pursued for non-conformity liability simply because the client does not like something, even if it is just a specification.

Furthermore, the vendor may significantly increase the estimate in preparation for unjust pursuit of non-conformity liability, which would be disadvantageous to the client.

Therefore, it is important to clearly indicate in writing what purpose the client has in mind, what functions they want the system to have, and to ensure that these are accurately reflected in the specifications.

It may also be worth making it clear that if the system or software is delivered exactly as specified, it does not constitute non-conformity, even if there is some inconvenience in the specifications.

With this provision, you can prevent the client from questioning non-conformity liability due to their preferences, even though the system was developed according to the specifications.

Point 2: Clarification of Warranty Period

The period for exercising non-conformity liability rights is calculated from the time the non-conformity is “known”, not from the time the product is “delivered”.

Even if a separate statute of limitations applies, the period is “up to ten years” at most, which is a long time.

For the vendor, it is a significant burden to have to provide a free warranty for a long period of “up to ten years” depending on the case, and this must be added to the estimate.

On the other hand, as a client, it may be more beneficial in terms of cost to set the warranty period flexibly according to the usage period of the system or software.

Therefore, it is possible to set the warranty period flexibly according to the content of the system, etc.

Point 3: Response When Non-Conformity Occurs

When non-conformity occurs, it is possible to limit the rights that can be exercised, such as claims for damages or cancellation, which are recognized under the Civil Code, to a certain extent by agreement between the parties.

As a client, it is necessary to understand exactly what limitations are placed on the contract.

Summary: Consult a Lawyer When Drafting Contracts that Include “Liability for Non-Conformity”

The amendment to the Japanese Civil Code has had a significant impact on the legal aspects of system and software development.

When a delivered system has a defect, it is not always clear whether this constitutes a “breach of contract” and what kind of liability can be questioned.

Furthermore, to prevent disputes in advance, it is essential to have sufficient discussions between the client and the vendor at the stage of the development contract.

If you have any concerns about drafting contracts, please do not hesitate to consult a specialist lawyer.