Article Categories

All Articles

Soft Skills

Organizational Culture

Technology

BLOG

What Is a Quasi-Mandate Contract? When to Use It in System Development and How It Differs from Fixed-Price

October 18, 2026

Technology

"I heard a quasi-mandate contract has no deliverables. Will I pay and end up with nothing?" "I asked for a fixed-price contract and was told the requirements are not settled, so it has to be quasi-mandate. Is that a bad deal for me?" Of all the contract questions we are asked, the quasi-mandate contract is the most misunderstood.

A quasi-mandate contract (jun-inin, 準委任契約) is a contract in which you pay for work being done properly. It is a time-and-materials style contract under Article 656 of the Civil Code. Deliverables still come out of it. The difference is that the developer does not promise to complete a defined deliverable. For phases where the requirements are still being worked out, or for development that improves a product while it is in use, this form matches reality better.

This article explains what a quasi-mandate contract is, how it differs from a fixed-price contract, which phases of system development it suits, and the common failures and how to avoid them. We write from the viewpoint of a company that develops under both forms.

Across the phases of system development, requirements definition and operations are contracted as quasi-mandate, and design through development and testing, once the specification is fixed, as fixed-price. Contracting by phase is the basic approach.

About the author

wesionaryTEAM Editorial Team

The editorial team is made up of wesionaryTEAM's project managers and engineers. Drawing on what we learn every day on business system, AI adoption and digital transformation projects, we publish information people can use when making decisions, with cases and figures.

What a quasi-mandate contract is
How it differs from a fixed-price contract
"No deliverables" is a misunderstanding
Which development phases suit a quasi-mandate
How the cost of a quasi-mandate is set
Common failures under a quasi-mandate, and how to avoid them
Contracting by phase
FAQ
Summary

What a quasi-mandate contract is

The quasi-mandate contract is based on Article 656 of the Civil Code. A mandate contract (Article 643) entrusts legal acts to another party. A quasi-mandate applies the same rules to entrusted work that is not a legal act. System development is not a legal act, so a contract that entrusts work to a development company is a quasi-mandate.

Under Article 644, the development company, as the party entrusted, must carry out the work with the care of a prudent manager. This duty of care means working to the standard normally expected of a professional. It is not a contract that allows cutting corners.

There are two types of payment. The pay-for-performance type pays by the time or period worked. The pay-for-results type pays for the result the work produces. The second type was written into the Civil Code in the amendment that took effect in April 2020 (Article 648-2). Even in the pay-for-results type, unlike a fixed-price contract, the developer does not promise that the result will be completed.

How it differs from a fixed-price contract

	Quasi-mandate contract	Fixed-price contract
What you pay for	Work performed	Completion of the work
Duty to complete	No	Yes
Liability for defects	Within the duty of care	Liability for non-conformity
Ending the contract early	Either party, at any time	The client may, by compensating the developer

A fixed-price contract (ukeoi) pays for completion of the work, as Article 632 of the Civil Code states. If the work is not completed, the developer cannot claim payment. If the delivered product does not conform to the contract, the client can demand repair or a reduction in price. We cover this in detail in What is fixed-price (ukeoi) development?.

Ending the contract early also differs. Under Article 651, either party to a quasi-mandate may terminate at any time, although terminating at a time that harms the other party requires compensation. Under Article 641, the client to a fixed-price contract may terminate at any time before completion, but must compensate the developer for its losses.

Under either contract, if the client gives direct instructions to the development company's engineers about how to do the work or how many hours to work, this may count as disguised contracting (giso ukeoi) and breach the Worker Dispatch Act. The Q&A collection published by MHLW (Ministry of Health, Labour and Welfare) says this is judged by the actual practice, not the form of the contract, and that the same applies to quasi-mandate contracts.

"No deliverables" is a misunderstanding

A quasi-mandate contract still produces deliverables: a requirements document, design documents, working software. The difference is what you pay for. In a fixed-price contract you pay for the deliverable being completed to the agreed specification. In a quasi-mandate you pay for the work being done properly, to a professional standard.

Put another way, what the client buys under a quasi-mandate is the time and skill of professionals who make judgments as they go in an uncertain situation. If you demand a promise of completion before anyone knows what will be built, the development company can only add a risk premium or interpret the scope narrowly. The quasi-mandate removes that strain.

In return, the client must keep deciding what to work on first. Let go of that, and the contract becomes one where only time passes.

Which development phases suit a quasi-mandate

Requirements definition. The phase that decides what to build cannot promise completion before the decision is made. The usual approach is to do requirements definition under a quasi-mandate and then estimate development as fixed-price based on the settled specification.
Agile development. Development that builds and checks in short cycles changes its priorities along the way. IPA's Model Transaction Contract for Information Systems (Agile Development Edition) also assumes a quasi-mandate contract.
Proof of concept (PoC) and minimum viable product (MVP). What gets built next depends on the results, so a fixed deliverable is a poor fit.
Operations, maintenance and insourcing support. Work where professionals accompany you for a set period is the typical quasi-mandate.

By contrast, phases where what will be built is already decided, such as a rebuild or migration with a complete specification, suit a fixed-price contract.

How the cost of a quasi-mandate is set

In the pay-for-performance type, the amount is set by the team (headcount and roles) and the period. Most often you pay a monthly fee per person, and the rate per person depends on role and experience. When you receive an estimate, check who will be involved and for what share of their time.

In the pay-for-results type, the amount is set against an agreed result, for example a complete set of requirements documents or a report on test results. It looks close to fixed-price, but because the developer does not promise to complete the result, the definition of what counts as the result matters.

In either type, agree the period, a budget ceiling, and the procedure for discussing it when the ceiling is about to be exceeded. This prevents work going ahead with no view of the cost.

Common failures under a quasi-mandate, and how to avoid them

Only time passes. If you reserve people without setting a goal, work is happening but nothing moves forward. For each period, decide what you need to learn to move on, and set the end condition first.
Giving direct instructions. If the client's staff tell the development company's engineers directly what order to work in or to work overtime, this may be disguised contracting. Pass requests from the client's lead to the development company's lead, and leave decisions on how to do the work with the development company. The MHLW Q&A collection says that close cooperation, advice and suggestions between the parties are not disguised contracting as long as the contractor makes its own decisions in a relationship between equals.
Reporting is not visible. If you cannot see what time was spent on, you cannot judge whether the cost is reasonable. Include a weekly report and a list of remaining work in the contract.
No end has been defined. A quasi-mandate has no "completion". Unless you decide what you need to know, or what needs to work, for the engagement to end, there is no natural stopping point. Write the items to be judged at the end of the period into the contract.
The scope keeps growing. A quasi-mandate handles change well, but it has no brake. Set the period, the budget ceiling and the review points at the start.

Contracting by phase

You do not have to choose quasi-mandate or fixed-price once for the whole project. The Model Transaction Contract for Information Systems from METI and IPA uses multi-stage contracting, where each phase gets its own contract.

What we most often propose is this combination: requirements definition under a quasi-mandate, then design through development and testing as fixed-price once the specification is settled, then operations and improvement after launch under a quasi-mandate again. The settled parts get a duty to complete; the unsettled parts get flexibility.

This article is a general overview. For an individual contract, please rely on the contract text and, where needed, a check by a professional.

FAQ

Under a quasi-mandate contract, will defects not be fixed?

They will. The development company owes a duty of care, and it is responsible for work that falls below the standard normally expected of a professional. The legal basis differs from liability for non-conformity under a fixed-price contract, however, so check the scope of defect handling in the contract.

Are quasi-mandate and SES the same thing?

SES (system engineering service) is the name of a service that provides engineers' working time, and most SES arrangements are quasi-mandate contracts. Quasi-mandate is the broader term and also covers requirements definition support and operations and maintenance.

Under a quasi-mandate contract, may the client pass requests directly to the developers?

Sharing requests and information is fine. Giving direct instructions on how to do the work or on working hours may be disguised contracting. Decide the roles and points of contact when you sign the contract.

How is the cost of a quasi-mandate set?

By headcount and period (pay-for-performance type) or by an agreed result (pay-for-results type). A monthly fee per person is the most common form, so check the period and team the estimate assumes.

Can we start with a quasi-mandate and switch to fixed-price part way through?

Yes. Doing requirements definition under a quasi-mandate and re-estimating development as fixed-price once the specification is settled is a common approach.

Summary

A quasi-mandate contract pays for work performed. It does not promise to complete a deliverable, and in return it suits phases where decisions are made as you go. Deliverables still come out of it, on condition that the client keeps making the priority decisions.

The basic approach is to split by phase: quasi-mandate for requirements definition and improvement, fixed-price for development once the specification is settled. Your project manager will work out which phase to run under which form with you in a free estimate consultation.

Development Consultations and Estimates

As your co-creation partner, we drive business development and DX.

We start with a call with your project manager to confirm what to build and the expected cost range.