What Constitutes Completion of Work in a Contract for System Development

System development often involves long-term projects, and vendors may be repeatedly asked for specification changes or additional feature implementations. This can sometimes put vendors in a difficult situation where there seems to be no end in sight. For such vendors, the question of “What exactly do we need to do and to what extent to consider our job done?” can sometimes become a serious concern.

Furthermore, system development is often carried out under contract, which is aimed at “completing the job”.

In this article, we will explain from a legal perspective, “At what point and to what extent does system development need to be done to be considered complete?”

What Constitutes the Completion of System Development

Completion of System Development from an Engineer’s Perspective

In the field of system development, if you ask “When is the system development completed?”, the typical answer would be “When the testing process is finished and the deliverables have been handed over.” Indeed, the general flow of system development starts with requirement definition, which involves identifying the functions to be implemented, followed by the creation of various design documents, the implementation of the program, and finally, the testing process to confirm that the system is functioning correctly. The process is considered complete when the user accepts the system.

Therefore, from the perspective of engineers involved in the actual work, it is generally understood that “the completion of system development equals the acceptance of the system.”

Completion of System Development from a Legal Perspective

On the other hand, from a legal perspective, if you ask “When is the system development completed?”, the focus of the discussion naturally shifts to when the legal obligations that the vendor had under the contract can be said to have been fulfilled. Contracts in system development are typically classified as either a contract for work or a quasi-mandate contract.

In terms of the completion of system development, i.e., the fulfillment of the obligations that the vendor has, the criteria for judgment are given in the following articles:

Contract for Work: Japanese Civil Code Article 632
Article 632
A contract for work comes into effect when one party agrees to complete a certain job, and the other party agrees to pay for the result of that job.
Quasi-Mandate Contract: Japanese Civil Code Article 648
Article 648
1. Unless otherwise agreed, the agent cannot claim remuneration from the principal.
2. In cases where the agent is to receive remuneration, he cannot claim it unless he has performed the mandated task. However, if the remuneration is determined by a period, the provisions of Article 624, paragraph 2 shall apply.
3. If the performance is terminated midway due to a reason that cannot be attributed to the agent, the agent can claim remuneration in proportion to the performance already made.

The Completion of System Development is an Issue in Contracts for Work

However, not only in the context of system development, the issue of “when the job is completed” is basically a matter of contracts for work. In the case of a quasi-mandate contract, rather than fulfilling the obligation by bringing about a specific result or outcome, it is a type of contract that emphasizes the agent, as a professional, doing what needs to be done with a certain degree of discretion (regardless of the result). Even in the text of the law, in a quasi-mandate contract, even if the expected deliverables are not produced, if the business processing itself was properly carried out, it is possible to claim remuneration (Article 648, paragraph 2), and if the performance was terminated midway due to a reason that cannot be attributed to the agent, it is possible to claim remuneration in proportion to the performance already made (Article 648, paragraph 3). You could say that contracts for work emphasize “results,” while quasi-mandate contracts emphasize “process.”

Therefore, in quasi-mandate contracts, the “duty of care” in the process of carrying out the mandated tasks tends to be a legal issue. That is, when it is assumed that a high degree of trust is placed in the agent, the question is when can a violation of the duty of care based on a mandate contract be pursued.

On the other hand, what is important in a contract for work is the “completion of the job.” If the job that should be completed is not completed, the vendor cannot fulfill its obligations, and it cannot claim remuneration. However, if the job is completed, there is no need to question the details of the process. Therefore, the question of “when is a system development project completed?” can essentially be rephrased as a legal interpretation issue of the phrase “completion of the job” in a contract for work.

When is a Job Considered Complete in System Development?

So, when specifically should we consider a job to be “complete”? Let’s look at some past court cases to clarify this point.

Court Cases Regarding Job Completion

The court case cited below involves a vendor who delivered a system that later revealed issues with processing speed and communication costs. Despite these issues being discovered, the development process itself was completed, leading to a dispute over whether the job could be considered “complete”. The court ultimately ruled that the job was indeed complete.

Articles 632 and 633 of the Japanese Civil Code stipulate that the time for payment of the contractor’s fee to the client is when the contractor has completed the work and delivered the object of the work to the client. On the other hand, Article 634 of the same law stipulates that if there are defects in the object of the work, the contractor is liable to the client (Paragraph 1), and the client has the right to refuse payment of the fee until the contractor has fulfilled his warranty liability for the defects in the object of the work (Paragraph 2). According to these provisions of the Civil Code, the law distinguishes between cases where the result of the work is incomplete and cases where the work is not completed, and it is understood that even if there are defects in the object of the work, whether they are hidden or apparent, they do not constitute incomplete work.
Therefore, whether the contractor has completed the work should be judged based on whether the work has been completed up to the final process planned in the original contract, and it is reasonable to interpret that the client cannot refuse to pay the contract price simply because there are defects in the object of the work when the contractor has completed the final process of the work and delivered the object.

In the above judgment, “job completion” was determined to be satisfied as long as the final process in system development was completed. As a remedy for defects (often referred to as “defects” in legal terms) in the system created by the vendor, a separate system of warranty liability for defects is provided.

Therefore, even if the concept of “job completion” is interpreted somewhat broadly, it does not ultimately impose unfairness on the user side. To summarize, it is as follows:

【Obligation in a Contract = Job Completion = Completion of All Processes】
========
If the job is not completed…
↓
【Bear the Responsibility for Non-performance of Obligation】
========
If the job is completed but there are defects…
↓
【Recognize the Performance of the Obligation and Deal with the Issue of Warranty Liability for Defects】

The above court case demonstrates how to separate these issues.

However, in relation to the point of “job completion”, it is also possible to consider from the perspective of “passing the user’s acceptance inspection”. For legal issues when the user’s acceptance inspection is not progressing, we have provided an explanation in a separate article.

What Completion of Legal Work Means

In system development, if the “completion of work” is recognized, it means that the obligation has been fulfilled, and there will be no further pursuit of liability for “non-performance” of the obligation. In a contract, if the work is not considered complete, you cannot request payment, and even if you have made special agreements for prepayments, they must essentially be returned. On the other hand, if the fact that the work is complete is recognized, the vendor will be responsible for issues such as warranty of defects and quality assurance under the contract.

The fact that the vendor is released from the liability for non-performance of the obligation means that the room for the user to cancel the contract becomes significantly smaller. This is because the cancellation of the contract based on the warranty of defects is limited to cases where the purpose of the contract cannot be achieved. If the contract is cancelled, the vendor also loses the right to request payment (in other words, no payment is received at all), so in practice, disputes often arise over the “completion of work”.

For a detailed explanation of the “cancellation” of contracts in system development, please refer to the following article.

Notes Regarding the Completion of Work

How to Consider Specification Changes and Additional Development

It is also possible that vendors may find themselves in a situation where they have already met the initial specifications, but are being asked for changes or additional features, making it difficult to conclude the project. In such cases, issues such as “when to end system development” arise. Detailed explanations for these situations can be found in the following article.

Pay Close Attention to the Civil Code Revision

Furthermore, the provisions for defect warranty liability based on contracts for work have traditionally been complex and difficult to understand due to the intricate connections between the articles. This area is strongly affected by the revision of the Civil Code. As the Civil Code is revised, the following article provides a detailed explanation on how to interpret “defects”.

Summary: Legal Concept of Completion of Work can be a Guide to Consider Completion of a System Development

In this article, we have discussed system development completion consideration issues, which can often be pushed into situations where “there is no end in sight,” to the legal concept of “completion of work.” The end of each project will vary depending on the development requirements, but when disputes arise over such points, the legal concept of “completion of work” is often a guiding thread.