What is the Law When Payment for System Development is Unpaid?
For vendors undertaking system development tasks, arguably the greatest risk is the situation where, despite having delivered the product, the user does not pay the remuneration. The cost of system development often involves a significant amount of skilled personnel, including programmers, resulting in high labor costs. Failure to collect sales can sometimes become a matter of life and death. In this article, we will discuss from a legal perspective the issues that vendors should consider when users do not respond to payment of remuneration.
First, Confirm Whether You Are in a Position to Request Payment
- Despite the vendor having delivered the product to the user, the user refuses to accept the delivery, causing a delay in the payment request process.
- Although it was understood that the acceptance process had been completed, there is some discrepancy with the user’s understanding, and they refuse to make the payment.
These situations can realistically occur.
In addition, in system development terminology, the user checking the specifications of the completed system and accepting the delivery is called “acceptance”. The significance of this acceptance and what should be considered when its progress is not satisfactory are explained in detail in the following article.
Related article: What are the application scenarios of the deemed acceptance clause in system development?[ja]
While the overall explanation of acceptance itself is left to the above article, from a legal perspective, whether the user’s acceptance can be considered complete needs to be considered, taking into account the provisions of the “deemed acceptance clause”.
With this in mind, the first point to consider when assuming a case where the user does not make the payment is as follows.
- Whether the job is completed or still unfinished
- Whether the warranty liability (Japanese Civil Code Article 635) can be applied or not
The reason why the above two points should be confirmed first is that if the job is not completed and the warranty liability (Japanese Civil Code Article 635) is not applicable, even if a lawsuit is filed, it is unlikely that the payment will be made.
So, what should the vendor’s representative investigate specifically to consider the above two points? Let’s look at what documents should be checked below.
Documents to Check for Determining the Eligibility of Fee Claims
| Delivery Note If there is no delivery note, it can be inferred that the delivery has not been completed and the work is not finished. |
| Document Notifying the Results of Acceptance This is the most important document when deciding whether the work can be treated as completed. Also, if the acceptance is being postponed due to user circumstances, it would be good to check how the “deemed acceptance clause” was described in the contract. |
| Task Management List This document is used to understand what issues have been identified so far and how they have been addressed. It also serves as a document to understand the status of defects and malfunctions that became apparent after delivery, and the status of their repairs. |
| Requirement Definition Document, Design Document, Change Management Document, Meeting Minutes, etc. These documents are used to clarify what should be called a defect or malfunction by clarifying what understanding the user and the vendor initially had. |
For details on how to manage changes in the specifications of the system to be developed and how to create change management documents, please refer to a separate article.
Related Article: How to Manage Changes in System Development from a Legal Perspective[ja]
| Termination Notice or Document Stating User’s Intent This serves as a means to understand the user’s intention for not proceeding with the acceptance (or not agreeing to pay the fee). |
Next, Confirm How Much You Can Claim
The amount that can be claimed is usually stated in the contract. However, if changes to the specifications are made after the fact, it is possible that there may not be a proper contract (or a document equivalent to it). The method of recalculating the estimate based on reasons such as changes in specifications and additional functions is explained in detail in the following article.
Related article: Is it possible to increase the estimated amount for system development after the fact?[ja]
While the method of recalculating the estimate is as described in this article, from the perspective of considering whether or not the claim amount can be increased, you should focus on:
- The presence and content of the estimate for additional development and function modifications
- The user’s response to the estimate
- The presence of an agreement on the amount related to the situation that caused the additional development and function modifications listed in the issue management list
In other words, you need to investigate whether there was a consensus with the user side on the point of “ordering the work for that amount” (in other words, whether a contract has been established).
Finally, Consider the Issues When Actually Litigating
Be Aware of the Possibility of a Counterclaim
In system development, when either the user or the vendor initiates a lawsuit, it is not uncommon for the other party to counterclaim. In other words, there may be some argument on the user’s side in situations where payment is not made.
While the user side also has various obligations to cooperate in system development, it should not be forgotten that the vendor side, as a system development expert, has a wide range of discretion and significant responsibility. We have detailed the project management obligations that the vendor side bears in system development in the following article.
Related article: What are the Project Management Duties in System Development?[ja]
In other words, it is necessary to carefully consider in advance whether it is possible to attribute the blame to the user side, which unilaterally refuses to pay. Looking at past court cases, there are many cases where the vendor initially filed a lawsuit seeking payment, but the user counterclaimed for restoration of the original state and damages.
Consider Whether There is Really a Business Advantage
Even if the vendor’s argument is accepted and it is recognized in a lawsuit that it is possible to claim payment, if the situation escalates to a lawsuit, it is expected that it will be practically difficult to continue transactions in the future. In addition, even if your argument is accepted in a lawsuit, you should be prepared for the fact that it may take a considerable amount of time to actually receive payment. Considering the time and cost involved in litigation, it may often be more reasonable and better to make efforts to find a compromise.
Summary
If a user refuses to make a reward payment and you attempt to legally examine the issue, it will be necessary to review multiple types of documents. In addition, it’s not just about thorough document management. You also need to consider what kind of organizational risks and disadvantages you may face if you ultimately decide to litigate.
Thorough document management on a daily basis is indeed usually part of the field-level operations. However, if you decide to litigate based on the stored documents and materials, it could become a significant management decision. In such irregular situations, it is important to understand the entire process, along with the fact that the unity and organizational strength of the field and management sides are tested.
Category: IT
Tag: ITSystem Development
