Litigation & Dispute Resolution

System Development Disputes

In system development projects, disputes arise between user companies and vendors over delivery delays, defects, acceptance and additional fees. Based on the contract and the development record, we help clients sort out claims and payment, and decide whether to continue or end the development. This guide is based on Japanese law. Whichever side you are on, you can consult us before deciding on litigation, and even before your documents are fully organized.

Our attorneys include the firm's Managing Partner, who has a background in science and engineering, attorneys with experience handling system development disputes, and an attorney who presided over system development litigation as a judge.

View our attorneys' backgrounds and practice areas →

Last updated: September 8, 2026

What to Check First When a System Development Dispute Arises

Check the impact on your business and the deadlines for delivery, payment, acceptance and notices.
Collect the contract, quotations, specifications and change agreements, and confirm the agreed scope of work.
Preserve emails, chat logs, meeting minutes, issue trackers and test results in a form that shows the history of changes.
Organize the development history and each side's requests in chronological order, and separate what is agreed from what is disputed.
Locate the deliverables, source code, data and administrative access rights, and sort out the conditions for business continuity and handover.
Before withholding payment, suspending work, cutting off access or terminating the contract, examine the contractual basis and the consequences.

Completing all of these steps is not a precondition for contacting us.

How we can helpClaims and defenses for both sides / Deciding whether to continue or end the development / Negotiation and litigation

Contact Form

Contents

1. Common Types of System Development Disputes
2. Initial Response When a Dispute Arises
3. Key Questions: Contract, Responsibility and Claims
4. Setting the Course and Choosing the Procedure
5. Agile Development and "Lab" Contracts
6. Contracts and Operations That Prevent Disputes
7. How Our Attorneys Support You
FAQ

1. Common Types of System Development Disputes

The system development disputes we handle typically fall into the following categories.

[User company] Delay or abandonment — the system cannot be used as planned, and you are considering whether to continue the project or claim damages.
[Vendor] Specification changes and additional fees — the workload has grown, but the customer will not agree to adjust the price or schedule.
[User company] Defects and acceptance — defects remain, and you are unsure how to handle acceptance or request fixes.
[Vendor] Refused acceptance and unpaid fees — the deliverables were provided, but acceptance is withheld and the fee remains unpaid.
[Both] Termination and settlement — the parties disagree over fees, refunds and damages upon early termination.
[Both] Handover of deliverables and data — the parties cannot agree on the delivery of source code or the conditions for its use.

In every category, how accurately you can organize the contract and the development record largely determines how smoothly the subsequent negotiation and proceedings will go.

2. Initial Response When a Dispute Arises

First, secure the contract, specifications, minutes, emails and other records — keeping originals, versions and edit histories intact — to the extent you may lawfully access them. Then organize the development history and the record of requests, approvals and changes in chronological order, matching each potential issue with its supporting documents. In parallel with preserving records, also consider system recovery, damage containment and business continuity.

In managing deadlines, distinguish contractual deadlines from statutory time limits. In addition to notice periods under the contract, check statutory notice periods and limitation periods according to the nature of the contract and the claims involved. Rather than uniformly waiting for the full picture before giving notice or responding, proceed with the necessary steps with the deadlines in mind. Measures such as withholding payment, suspending work, cutting off access or terminating the contract have a significant impact on the other party's business, so examine their contractual basis and consequences before acting.

3. Key Questions: Contract, Responsibility and Claims

(1) Nature of the contract, scope of development and additional fees

Under Japanese law, system development contracts may take the form of a contract for work (ukeoi, under which completion of the work is owed) or a quasi-mandate (jun-inin, under which the performance of services is owed), and different phases — requirements definition, design, development, testing — may be governed by different contracts. The analysis of responsibility and fees starts with identifying which work was performed under which contract. On that basis, distinguish the originally agreed scope of work from subsequent additions and changes, and sort out their impact on price and schedule. For additional or changed orders, we also check disclosure obligations under applicable Japanese legislation.

An illustrative scenario: repair, or additional development?

Where the user company regards certain work as "fixing functions that were required from the start" while the vendor regards it as "additional development outside the contract," we organize not only the volume of work but also the original specifications, the change requests, the quotations presented and the approval history, matching them against one another.

* This is an illustrative scenario for explanation. It is not an actual case handled by our firm.

(2) Project management and the customer's cooperation

The vendor's duty to manage the progress of the project, and the user company's duty to cooperate — for example by finalizing specifications and providing materials — can both be at issue. However, the label of a duty alone does not decide where responsibility lies. We examine the contractual division of roles, how the phases actually progressed and the record of communications to determine the cause of delays and rework.

(3) Completion, acceptance and non-conformity

Completion of the work, the acceptance procedure and non-conformity with the contract (defects) are analyzed separately under Japanese law. Whether the work is deemed completed, and how acceptance was defined in the contract and actually operated, affect the obligation to pay. Where defects remain, claims for cure (such as repair) or damages are considered separately from how payment should be handled. The contract's acceptance clauses and its provisions on non-conformity are also reviewed.

(4) Termination, settlement upon early ending, and damages

A development project may end in several ways — termination for breach, cancellation by the ordering party, or ending by agreement — and the form of ending changes how settlement and damages are handled. Upon an early ending, the questions include payment for the work already performed and whether and to what extent fees already paid should be refunded. Damages are considered separately from this settlement, based on whether there was a breach and the scope of the loss. Where the contract contains limitation-of-liability clauses, such as caps on damages, their scope of application is also examined.

4. Setting the Course and Choosing the Procedure

Continuing the development, or ending the contract

Before choosing between negotiation and legal proceedings, sort out whether to continue the development or end the contract. In transactions with overseas companies, also check the governing law and the jurisdiction or arbitration clauses of the contract.

Matters to confirm in common

Contract and development record
Each side's requests
Impact on the business

Preparing to continue the development

Remaining work and scope of fixes
Specification changes
Schedule
Allocation of costs
Confirmation and approval process

Preparing to end the contract

Settlement of fees and refunds
Deliverables, source code and data
Administrative access rights
Timing and scope of handover cooperation

Common considerations: claims and responsibility are examined in parallel under either course.

The course may be revisited as negotiations develop.

When the contract is to end, the handover of deliverables, source code, design documents, data and administrative access rights is treated not only as a question of who owns the rights, but as a condition for keeping the business running. In addition to the delivery of source code, we also confirm the scope in which it may be used and modified after the handover.

Negotiation, mediation, litigation and arbitration

The procedure is chosen from negotiation, civil mediation, litigation and other options, in light of the dispute resolution clause of the contract and the issues in dispute, together with cost and time. There is in principle no obligation to attempt mediation first. Mediation in Japan aims at a resolution by agreement, and mediators with specialized knowledge may be involved.

In litigation, settlement is available as well as judgment. In organizing the issues, the court may, after hearing the parties, involve technical advisers (expert commissioners). Their explanations assist the court's understanding of technical matters and are not themselves evidence.

Arbitration, such as under the Japan Commercial Arbitration Association (JCAA), is a procedure in which the resolution is entrusted to arbitrators based on an arbitration agreement. An arbitral award has, in principle, the same effect as a final and binding judgment, but enforcement requires an enforcement decision by a court. In cross-border matters, check whether there is an arbitration agreement and what it provides for the seat of arbitration and the language of the proceedings.

5. Agile Development and "Lab" Contracts

"Agile" refers to a way of running the development, and a "lab contract" — a form of engagement common in Japan under which a vendor makes a dedicated development team available — refers to a form of transaction. Both are analyzed separately from the legal nature of the contract, such as contract for work or quasi-mandate. In agile development, the points to confirm include how changes to work items and priorities are decided, the customer's involvement in decision-making, the standards for quality and completion, and the management of budget and schedule. In lab contracts, we confirm the team structure, skills and availability, reporting, responses to staffing shortfalls and replacements, and the conditions for ending the engagement and handover. Being a quasi-mandate does not mean the vendor bears no responsibility. In lab contracts and similar arrangements, we also examine the actual chain of direction toward the development staff, not only the label of the contract.

6. Contracts and Operations That Prevent Disputes

Many of the issues that surface in disputes can be prepared for through everyday contracts and operations. On the contract side, this includes defining the scope of work, specifications and quality standards; establishing a procedure for confirming and agreeing on the price and schedule impact of changes and additions; and setting the conditions for acceptance and payment, limitations of liability, and settlement and handover upon ending. On the operations side, it is important to designate who has authority to approve changes and additions, and to keep minutes and change histories. These preparations are effective when they are matched against what would actually be at issue in a dispute.

7. How Our Attorneys Support You

We advise both user companies and vendors on system development disputes. Our work covers the analysis of the contract and the development record, the assessment of claims and defenses, negotiation over the conditions for continuing or ending the development, and representation in mediation, litigation and other proceedings, handling the matter consistently from start to finish.

Beyond dispute response, we also assist with preventing similar problems, such as improving contract templates and change management arrangements.

View our attorneys’ backgrounds and practice areas →

FAQ

Q1. [User company] Defects remain. Can we refuse acceptance or withhold payment?

Depending on the contract and the seriousness of the defects, you may be able to withhold acceptance or payment, but you cannot necessarily refuse the entire payment as a matter of course. We check the conditions for completion, acceptance and payment, as well as statutory payment rules that may apply to subcontracting-type transactions under Japanese law.

Q2. [Vendor] There is no written agreement on the additional fees. Can we still claim them?

Even without a formal amendment, you may be able to claim fees for additional work if an agreement on paid additional work can be established. We examine the original scope of work, the change clauses, and the history of requests and approvals shown in quotations, emails and other records.

Q3. [User company] The development was abandoned midway. Will the fees we already paid be refunded?

A full refund is not guaranteed. Whether and how much should be refunded is assessed based on the nature of the contract, the grounds on which it ended, the work already performed and the benefit obtainable from the deliverables. Where there has been a breach, a claim for damages is considered separately.

Q4. [Vendor] The customer was late in finalizing specifications and providing materials. Are we still liable for the delay?

If the customer's conduct caused the delay, that can affect whether and to what extent the vendor is liable. However, we also review the vendor's own explanations, warnings and project management, examining the history of requests and responses and their impact on the schedule.

Q5. [User company] We want to transfer the project to another developer. Can we demand delivery of the source code?

Whether you can demand delivery depends on the contractual agreements and on the rights in, and conditions for use of, the deliverables. We confirm the scope of the handover and of the required cooperation, covering not only the source code but also design documents, data and administrative access rights.

Q6. [Vendor] The fees remain unpaid. Can we stop the development work or cut off access to the system?

Even where fees are unpaid, suspending work or cutting off access is not necessarily permissible right away. We confirm whether and when the payment obligation arose, whether the contract provides for suspension and whether a demand for payment is required, and the impact on the other party's business, and then consider the appropriate steps.

Contact

You Can Consult Us Before Deciding on a Course of Action

Whether to continue or end the development; how to handle acceptance and payment, claims and responses, settlement and handover. We advise both user companies and vendors from the negotiation stage. You are welcome to contact us even before your documents and records are fully organized.

This article is provided for general informational purposes only and does not constitute legal advice on any specific matter. Please consult us regarding your specific situation. The content is based on the laws and regulations in effect as of the date of the last update.