When you commission system development externally, the contract type divides broadly into two: the quasi-mandate contract and the contract for work. Which you choose greatly changes “who bears responsibility if it isn’t completed” and “whether you can change requirements midway,” so it’s a point to decide before negotiating the amount. This article explains the difference in their legal nature and the criteria for deciding which to contract under. Note that this article is a general summary; individual contract decisions presuppose the wording of the contract and confirmation by a professional.
The difference in legal nature between quasi-mandate and contract for work
Whether there is completion liability
A contract for work (Civil Code Article 632) is a contract that promises “completion of the work.” The vendor bears the obligation to complete the agreed deliverable, and in principle cannot claim compensation if it isn’t completed. A quasi-mandate (Civil Code Article 656) is a contract that promises “performance of the work,” with no completion obligation. Instead, the vendor bears a duty of care of a good manager (the duty to perform the work with the care normally expected of a professional), and compensation accrues for the work performed.
Non-conformity liability
Under a contract for work, if the deliverable doesn’t conform to the contract, the client can demand repair, price reduction, damages, or termination (non-conformity liability; restructured from the former “warranty against defects” in the Civil Code amendment that took effect in 2020). A quasi-mandate has, in principle, no non-conformity liability for the deliverable, but a breach of the duty of care can be pursued as liability for non-performance. Note that the amended Civil Code also codifies a result-completion type of quasi-mandate (Civil Code Article 648-2), where compensation is paid for a result, making an intermediate design possible.
Direction and command
A commonly misunderstood point: under both quasi-mandate and contract for work, the client cannot directly direct or command the vendor’s engineers. Work instructions should as a rule go through the vendor’s responsible manager. Breaking this leads to the disguised-contracting problem described below. Also, under either contract the vendor bears an obligation to report on the progress and results of the work, so it’s not that “you can’t ask about results because it’s a quasi-mandate”—quality management through reporting can naturally be required.
Comparison table and which suits which case
| Aspect | Contract for work | Quasi-mandate |
|---|---|---|
| What is promised | Completion of the deliverable | Performance of the work (duty of care) |
| Compensation model | A fixed amount for completion, as a base | Payment according to work performed, as a base |
| Specification changes | In principle requires a contract change (additional estimate) | Easy to reflect flexibly |
| Where the non-completion risk sits | Mainly on the vendor side | Mainly on the client side |
| Suited processes | Development and maintenance of fixed, routine work with settled specs | Requirements definition, agile development, PoC, technical support |
In practice, as shown even in IPA’s model contracts, the standard is to use different contract types per process: quasi-mandate for processes with fluid specs like requirements definition and external design, and contract for work for the manufacturing process after specs are fixed. Fixing everything as “all contract for work” tends to be more expensive after all, because the vendor adds the risk of the not-yet-settled stage into the amount.
If you’re unsure how to decide, thinking in the following order makes it easier to organize. (1) Can you finalize the deliverable right now in text and screens?—if not, a quasi-mandate is a candidate. (2) If you can finalize it, who should bear the risk of non-completion?—if you want the vendor to bear it, then contract for work, but the amount rises accordingly. (3) Do you want to change priorities midway?—if so, a contract for work incurs contract-change procedures every time you change. Answering just these three questions already narrows down considerably which contract suits your situation.
Beware of disguised contracting
Even if the contract is nominally a contract for work or quasi-mandate, if in reality the client directly and routinely gives work instructions to the vendor’s engineers, it may be judged as disguised contracting (a state that is in reality worker dispatch but hasn’t gone through the procedures of the Worker Dispatch Act). The client side too can become subject to corrective guidance. Since this especially tends to happen with on-premises-style quasi-mandates, it’s important to observe the following practices.
- Make the vendor’s responsible manager (the lead) the point of contact for work instructions and progress management.
- Have the vendor side manage the working hours and leave of individual engineers.
- Leave the authority to decide the selection and replacement of personnel with the vendor side.
The affinity between agile development and quasi-mandate
Agile development, which reviews priorities each sprint, structurally doesn’t mesh with a contract for work that “finalizes the finished product first.” As long as what to build is decided while running, agile development is fundamentally a quasi-mandate (performance-ratio type). However, because a quasi-mandate is also a contract where “compensation accrues if time is spent,” the client side must not leave everything to the vendor; continuing involvement—participating in sprint reviews, deciding priorities, checking velocity (the development team’s pace)—is a condition for producing results. Note that the model contract for agile development published by METI and IPA also presupposes a quasi-mandate; it’s not that “because it’s agile, the contract can be vague.” Documenting the division of roles, the meeting bodies, and the method of confirming results in the contract or an appendix is recommended.
Clauses to check in the contract
- Contract type and scope of work — Whether quasi-mandate or contract for work, and whether it’s specified per process. For a multi-stage contract, also check the relationship between the master agreement and individual agreements.
- Criteria for acceptance and work-completion confirmation — For a contract for work, the acceptance criteria and period; for a quasi-mandate, the monthly work report and confirmation method.
- Scope and period of non-conformity liability — For a contract for work, the notice period (a special provision such as one year from delivery is common) and the scope of response.
- Ownership of intellectual property — When and to what extent the copyright of the deliverable transfers to the client. Whether there’s a clause for non-exercise of moral rights of the author.
- Whether subcontracting is permitted — Whether prior consent is required, and the management responsibility for subcontractors.
- Conditions for mid-term termination — A quasi-mandate can in principle be terminated at any time (Civil Code Article 651), but check the settlement method and notice period provisions.
Summary｜Using the right type per process is the practical answer
There’s no one-size-fits-all answer to “which is more advantageous, quasi-mandate or contract for work”; the axis of judgment is contract for work if the specs are settled, quasi-mandate if they aren’t settled or keep changing. Confirm requirements definition and PoC small under a quasi-mandate, then carve out the settled parts under a contract for work or result-completion type—this division minimizes the risk for both client and vendor. In SHANNON’s contract development, we make it standard to concentrate on hypothesis testing under a quasi-mandate at the PoC stage, then discuss the contract type for the subsequent main development according to its content. Feel free to consult us from the pre-commissioning stage, including how to choose the contract type.