Distinguishing and Understanding the Differences Between Contracting and Quasi-Mandate Contracts in System Development
In the process of ordering and receiving system development, various contracts with different titles are exchanged, such as the contract agreement, the business consignment contract, and the system development contract.
Under Japanese law, contracts in which one party undertakes a service (such as development work) and the other party pays for it are distinguished as contract agreements and quasi-mandate contracts.
In a nutshell,
- Contract Agreement : A contract where you can receive payment if you deliver what is promised
- Quasi-Mandate Contract : A contract where you receive payment and make the best effort commensurate with that payment
These are the types of contracts.
Is System Development a Contract or a Quasi-Mandate?
System development aims to create a “promised” system, and according to the distinction above, it may seem to be a contract. However, it’s not that simple. System development differs slightly from the typical contract that the law envisages.
A typical contract, for example, is a custom-made suit. In the case of a suit, once the measurements are determined, it’s easy for the parties involved to imagine the finished product, and it’s also easy to judge whether the finished product matches the order. In contrast, in system development, there is usually no document that easily shows the overall picture of the system, making it difficult for the client to grasp the overall picture. Also, the system to be developed has a unique personalityistic of gradually becoming concrete through different stages.
Therefore, it can often be a problem to distinguish whether the nature of a contract in a certain stage of system development, especially in the initial stage, is a “contract” that promises the completion of work, or a “quasi-mandate” that does its best. Depending on this distinction, if the work is not completed, the remuneration that the system development company can receive may become zero, leading to one party being forced to bear an excessive and large financial burden. Therefore, it is important to distinguish which contract it falls under.
Therefore, I will explain the differences between a contract and a quasi-mandate, which contract should be concluded, and the criteria for distinguishing between the two.
Differences between Contract for Work and Quasi-Mandate Contract
First, let’s explain the differences in the provisions of the Contract for Work and the Quasi-Mandate Contract under the Civil Code, as well as the treatment when a special contract is concluded.
Remuneration Receipt, Termination, Warranty Liability for Defects, Re-Contracting and Special Contracts in Contract for Work
A Contract for Work is a contract in which one party (the contractor/vendor) promises to complete a certain job, and the other party (the client/user) promises to pay remuneration (contract price) for the result of that job.
“Completion of work” can be exemplified by the creation of deliverables such as “project plans”, “requirement definition documents”, “basic design documents”, “programs”, “systems”, etc., which are agreed upon by both parties.
Remuneration Receipt
If the work is not completed, the contractor/vendor cannot receive remuneration. If you want to be paid before the work is completed, you need to make a special contract for advance payment. The concept of “completion of work” is very important in system development projects based on a Contract for Work.
Even if a special contract is concluded, if the work is not completed due to the termination of the project, the contractor/vendor must return the remuneration already received to the client/user as unjust enrichment. This is the biggest difference from the Quasi-Mandate Contract.
Termination
If neither party is in breach of contract, the client/user can terminate the contract by compensating for damages until the work is completed. In this case, the “damage” is the amount deducted from the cost incurred by the contractor/vendor and the remuneration that would have been received, by the cost saved by being exempted from the obligation to complete the work. On the other hand, the contractor/vendor cannot terminate the contract.
If a special contract is made that termination is not possible unless the other party is in breach of contract, the contractor/vendor will not have the risk of being terminated at any time despite no breach of contract.
Warranty Liability for Defects
If there are defects in the object of the work, the client can request for defect repair, claim for damages, and terminate the contract when the purpose of the contract cannot be achieved.
A defect means a flaw or defect, and is recognized when the quality or performance that the object should have is lacking in light of the purpose of the contract. If the system is not up to the promised specifications or performance after the completion of the last process planned in the contract, it is considered a “defect”.
In a court case, it was ruled that bugs related to personal information leakage in the system construction of a university were not defects, but the absence of exclusive control, which is essential in the system, was recognized as a “defect”. You can make a special contract to not bear the warranty liability, or to shorten the period of bearing the liability.
Re-Contracting
The contractor/vendor is free to re-contract. If a special contract is made to prohibit re-contracting, re-contracting cannot be done.
Remuneration Receipt, Termination, Warranty Liability for Defects, Re-Contracting and Special Contracts in Quasi-Mandate Contract
A Quasi-Mandate Contract is a contract in which one party (the trustee/vendor) is entrusted by another party (the mandator/user) to handle affairs. The trustee has the duty of care of a good manager, which means to exert his/her abilities and perform the work reasonably. In other words, it means “doing your best”.
A typical example is medical treatment, which promises to provide more than the standard level of treatment process, but does not take responsibility for the result of healing.
The major difference from the Contract for Work is that you do not have to take responsibility for the result of the work.
Remuneration Receipt
Unlike the Contract for Work, even if the work is not completed, the trustee/vendor can receive remuneration if the office work itself is properly performed. Also, if the mandate ends in the middle of performance due to a reason that cannot be attributed to the trustee, the trustee can claim remuneration according to the proportion of performance already done.
In the amendment to the Civil Code enacted in 2017 (enforced in April 2020), even in the case of a quasi-mandate, there may be cases where remuneration is paid for the achieved results, and in such cases, a provision has been established that allows the remuneration to be claimed after the completion of the results in principle.
Termination
Unlike the Contract for Work, even if the other party is not in breach of contract, not only the mandator/user but also the trustee/vendor can terminate the contract at any time.
If a special contract is made that termination is not possible unless the other party is in breach of contract, the risk of being terminated at any time without reason will be eliminated.
Warranty Liability for Defects
Unlike the Contract for Work, there is no provision for warranty liability for defects. The terms “warranty liability for defects” and “acceptance” mentioned above are somewhat famous as legal terms related to system development, but these concepts only appear in the case of a Contract for Work. However, the trustee has a duty of care to “do his/her best”, and if he/she does not perform the work reasonably, there is a risk of being claimed for damages or termination based on breach of contract.
Especially as an obligation borne by the vendor side in system development, there are project management obligations, etc.
Re-Contracting
Unlike the Contract for Work, the trustee/vendor, in principle, cannot re-contract. If you want to re-contract, you make a special contract to that effect.
This part often becomes a problem in practice and requires caution. If you contract a quasi-mandate type development project without a special contract for re-contracting permission, judging that “since it is system development, re-contracting should be possible unless specifically stated”, you may end up in a situation where you could be accused of breaching the contract just for “having re-contracted”.
Even the User Side, Who is the Orderer, Has Obligations
While the discussion so far has mainly been about the obligations borne by the vendor side, who is the order recipient, in the context of system development, which requires a large number of people and man-hours, the user side, who is the orderer, also has a certain “obligation to cooperate”.
Choosing Between a Contract for Work and a Quasi-Mandate Contract
Advantages and Disadvantages for Development Companies/Vendors
For development companies/vendors, the advantage of choosing a ‘contract for work’ is that if they can manage well with fewer people, they can make more profit than with a quasi-mandate. Unlike a quasi-mandate, a contract for work obligates the completion of the work. In other words, no matter how much they reduce personnel or streamline operations to keep costs down, as long as they complete the work, they have fulfilled their obligation.
The disadvantages are:
- They cannot ensure payment until the work is completed
- If unexpected man-hours occur to complete the requirements, they may have to bear the cost of additional work, which could potentially lead to a deficit
- They bear the warranty liability for defects
- Even if unexpected man-hours occur to meet the requirements, they may have to bear the cost of such additional work or increased man-hours, which could potentially lead to a deficit
- They bear the warranty liability for defects
The advantages of choosing a ‘quasi-mandate contract’ are as follows:
- They can receive payment even if the work is not completed
- They can have the cost of increased man-hours covered
- They do not have to bear the heavy responsibility of completing the work and producing a defect-free product
- Unlike a contract for work, a quasi-mandate obligates ‘effort commensurate with the remuneration’, and therefore, it is easier to predict the cost to fulfill this obligation in advance
Advantages and Disadvantages for Clients/Users
For clients/users, the advantages of choosing a ‘contract for work’ are as follows:
- They do not have to pay until the work is completed (they can get a refund even if they prepay)
- The remuneration to be paid is fixed, so there is no cost burden for increased man-hours due to additional work, etc.
The disadvantage is that there is a risk of being presented with a high estimate to avoid the risk of loss.
The advantage of choosing a ‘quasi-mandate contract’ is that you can expect a lower estimate than a contract for work. The disadvantages are that you cannot make the contractor/vendor responsible for completing the work, and if unexpected man-hours occur, you may have to bear the cost of such additional work or increased man-hours.
Court Precedents
In court precedents, there have been cases where the contract was judged to be a quasi-mandate contract up to the confirmation of requirements definition and basic design, and cases where the contract was judged to be a contract for work for the work from the post-basic design process to unit testing.
Which Contract Should You Enter Into, a Contract for Work or a Quasi-Mandate Contract?
It is conceivable to enter into a model contract type contract according to the process, but the difficulty and content of the development target, the amount of money you want to receive/can prepare, the intention of the other party and the power relationship between the two parties, whether you can imagine the completed product and describe it in the contract, etc., should be judged and negotiated based on individual circumstances at each company from the management and legal aspects.
Criteria for Distinguishing Between Contract for Work and Quasi-Mandate Contract
What is Contract Characterization?
The question of “whether the nature of the contract falls under a contract for work or a quasi-mandate contract” arises in certain situations and has specific implications.
When the parties do not explicitly agree on whether the contract (related to the work) is a contract for work or a quasi-mandate contract, i.e., they do not make a special agreement and do not include a clause to that effect in the contract, the provisions of either type of contract stipulated in the Civil Code will apply. This is based on a post-hoc judgment of “which type of contract it is,” and this judgment is made based on certain criteria.
This is the case.
However, this is based on the assumption that:
- A contract for system development is in place
- The contract is either a contract for work or a quasi-mandate contract
Before addressing this issue, there is the question of “whether a contract for system development is in place in the first place.”
Then, assuming that the system development is in place as mentioned in the above 2, the question of which contract it falls under can lead to a decision on which party bears an excessive amount of money, which can be a major issue.
It is not uncommon for the contract to not explicitly state “contract for work” or “quasi-mandate,” or for the substance to differ even if it is stated, or for there to be a discrepancy in understanding between the parties. Therefore, we will explain the criteria for distinguishing between a contract for work and a quasi-mandate contract.
The Nature of the Contract is Determined by Considering Various Elements
In order to determine the nature of the contract, we look at the contract as a whole and consider whether its purpose is to “deliver a completed product” or whether the vendor is to “perform the work reasonably.” Whether the project was progressing towards a somewhat specifically determined object to be completed is a key point.
The nature of the contract is determined by considering the following elements:
Track Record of the Development Company
If there is a history of creating systems of the same or higher level, it is often judged that “it was naturally expected to be completed, it was an obligation to complete, and there was an agreement to pay remuneration upon completion,” and it tends to be a contract for work.
Whether the Goal on the Process Chart is “Completion”
If it is completion, it is often judged that “it was an obligation to complete,” and it tends to be a contract for work.
Clarity of the Content of the Deliverables in the Contract Content/Contract Document
The clearer, the more likely it is judged that “it was expected to complete something with clear requirements,” and it tends to be a contract for work.
Whether the Remuneration is Unit Price Based
If yes, it is often judged that “it was an obligation to complete with the understanding that remuneration would be generated upon completion,” and it tends to be a contract for work.
Whether the Remuneration is Paid After Completion
If yes, it is often judged that “it was an obligation to complete,” and it tends to be a contract for work.
Presence of Acceptance, Warranty Liability, and Guarantee Clauses
If present, it is often judged that “it was an obligation to complete” and “acceptance, warranty liability, and guarantee clauses were prepared on that premise,” and it tends to be a contract for work.
Presence of Wording for Contract for Work or Quasi-Mandate
Of course, the wording is also an important consideration. However, it is not simply judged by the wording of “contract for work” or “quasi-mandate” alone, so care must be taken in drafting the contract.
In addition, such judgments are made not only based on the contract, but also on evidence such as minutes created during the system development process.
Summary: Consult Lawyers about Quasi-Mandate Contracts in System Development
While “contracting” and “quasi-mandate contract” may seem similar, their legal effects are entirely different. It would be safer to seek the judgment of an expert when entering into a contract. Our firm possesses advanced expertise in matters such as system development contracting. Please feel free to consult us.
Category: IT
Tag: ITSystem Development