What are the Countermeasures When System Defects are Discovered After Acceptance?

In general terms, system development involves implementing a program in accordance with the requirements defined in the requirements definition phase. Both the user and the vendor verify whether the final product meets the specifications, and the project is considered complete upon passing the acceptance test.

However, in reality, bugs or defects that were not detected during the testing process or at the time of acceptance may well emerge during subsequent operational phases. If you have already accepted the delivery, what can you legally demand?

It’s Not Surprising to Find Bugs After Acceptance Testing or Test Processes

From a technical perspective, it’s not uncommon to discover various bugs and malfunctions after the completion of various test processes by the vendor and the user’s acceptance. The user’s acceptance process usually focuses on checking the input and output that can be confirmed from the screen. However, IT systems often have a complex and detailed structure in the database behind the scenes and in the parts of the program that control various calculations, beyond the appearance on the screen that can be confirmed by the user. Therefore, there are inherent limitations to what can be investigated from the user’s perspective of checking the input and output on the screen. Consequently, it is not realistic to exhaustively verify all possible malfunctions that could occur in the subsequent operation phase during the check.

The same can be said from the perspective of the vendor who is responsible for the development work. For example, the ‘test process’ is to check whether there are any bugs or malfunctions in the content of the implemented program. However, it is not always possible to exhaustively verify all possible bugs and malfunctions in the test process. Even after the developed system starts to be actively used in business, it requires excellent technical skills to create a system that continues to work without any problems, even when operations that the vendor did not anticipate are performed, a large amount of data is actually registered, or multiple users start to access at the same time.

It is not realistic to discover all possible bugs and malfunctions at stages such as acceptance and testing, and it should be understood that IT systems may reveal various problems after they start to be used.

It is Customary for the Debt Itself to be Considered as Settled

So, how should we deal with such troubles when they actually occur? Let’s organize it according to the legal order.

First of all, if various bugs or defects are discovered, even after the fact, the user side would want to hold the vendor, who has been entrusted with the work so far, accountable in some way. However, usually, if the delivery has already been completed and has passed the acceptance, it is often difficult to pursue responsibility based on non-performance of obligations.

Unless there is some special agreement, the contract for system development is subject to the provisions of the Civil Code on contracts for work regarding the implementation of the program.

And in a contract for work, “completion of work” is a requirement for the performance of obligations.

Here, we explain that in past court precedents, “completion of work” in a contract for work means the end of all stages of development in the context of system development. And we explain that problems such as bugs and defects after all stages of development have ended are issues of warranty liability for defects in a contract for work.

To sum up, if you have once accepted delivery and completed acceptance, it is usually assumed that the obligation itself has already been fulfilled, and the issue is whether or not to pursue warranty liability for defects, i.e., quality assurance issues, afterwards.

Pathway to Pursue Liability Based on Warranty Against Defects

So, when seeking a response from a vendor based on warranty against defects, what should you consider and in what order? Let’s go through it below.

First, Confirm the Severity and Seriousness of Bugs or Defects

When bugs or defects are discovered after the fact and some form of guarantee is sought on the grounds that they are “defects” under the law, the severity of the bugs or defects becomes an issue. The issue of legal defects can be divided into three patterns:

1. Even if it can be called a bug or defect, it is only minor and cannot be considered a “defect” under the law.
2. It qualifies as a “defect” under the law, but the purpose of the contract can still be achieved.
3. It qualifies as a “defect” under the law, and the purpose of the contract cannot be achieved.

The boundary that separates whether or not liability can be pursued based on warranty against defects is between 1 and 2, and the boundary that separates whether or not the contract can be cancelled based on warranty against defects is between 2 and 3.

Article 634

1. When there is a defect in the object of the work, the orderer can request the contractor to repair the defect within a reasonable period. However, this does not apply if the defect is not significant and the repair requires excessive costs.

2. The orderer can request damages instead of or in addition to the repair of the defect. In this case, the provisions of Article 533 shall apply mutatis mutandis.

Article 635

When there is a defect in the object of the work and as a result, the orderer cannot achieve the purpose of the contract, the orderer can cancel the contract. However, this does not apply to buildings and other land structures.

For more detailed explanations on these step-by-step distinctions of “defects”, please refer to the following article.

Next, Clarify What Should Be Requested from the Vendor

Next, you need to clarify what you should request from the other party. If you want to cancel the contract, it is not enough to prove that it is a defect, you need to prove that it is something that “cannot achieve the purpose of the contract”. Important clues for judging the “purpose” mentioned here include the minutes of meetings held at the start of the system development project and the contents of the specifications. Since bugs or defects can be discovered after acceptance, it is important to thoroughly store various documents even after the development project is completed.

In addition to cancellation, other possible claims under the warranty against defects include claims for damages and requests for defect repair.

Other Points to Note

When performing legal actions such as contract termination, pay attention to the method

If you are going to terminate a contract as part of the warranty liability, you should also learn how to carry out the legal procedures for termination. We have detailed explanations in the following article about the effects of contract termination, how to make valid expressions of intent, and how to notify in a way that does not cause trouble later.

It is preferable to resolve disputes through negotiation rather than litigation

Furthermore, these legal theories are not only meaningful when a lawsuit occurs. Litigation is a significant burden for both parties. Rather, these insights should be utilized in the negotiation stage before litigation. For more information on how these legal insights can be meaningful in negotiations outside of court, please refer to the following article.

Distinguish between bugs and defects, and lack of functionality

The discussion differs depending on whether there are bugs or defects in the implemented functions and specifications, or whether the necessary features are not provided in the first place. If the necessary functions are not fully provided, it may not be recognized as “completion of work” in the contract, and the performance of the obligation may not be recognized.

Even if the necessary functions and specifications are not provided, if the user did not provide appropriate information at the requirement definition stage, it may be inappropriate to consider it as part of the contract in the first place.

Summary: Existence of Post-Completion Responsibilities in System Development

Issues that arise during the course of a project may become apparent either during the project’s progression or after its completion, such as during the operational phase. The characteristic of system development projects that you can’t necessarily relax even after successfully completing all stages is perhaps best symbolized by the system of ‘warranty liability for defects’ (Japanese ‘Kashi Tanpo Sekinin’). It is considered important to thoroughly manage documentation with a view to what happens after the completion of the system development project, and to understand this entire process.