MONOLITH LAW OFFICE+81-3-6262-3248Weekdays 10:00-18:00 JST

MONOLITH LAW MAGAZINE

IT

Can a System Development Contract Be Established Without a Contract Document?

IT

Can a System Development Contract Be Established Without a Contract Document?

In system development, it is not uncommon for developers to proceed with work before a contract is created. However, this flow is practically ‘dangerous’. If a contract is not created, there is a risk that if trouble arises later, the client may claim that the contract has not yet been established and therefore there is no need for them to pay a fee. In actual system development-related disputes, it is not uncommon for the establishment of the contract itself to be disputed, and for judgments to be made that are disadvantageous to the developer. As a developer, there is a risk of not being able to receive payment if the client decides to cancel the project or switch to another company. Furthermore, as will be discussed later, even if a contract is created, there are cases where the establishment of the contract is denied.

Here, we will explain the establishment of system development contracts, and the legal structure for claiming money if the establishment of the contract is not recognized.

Formation of a Contract

As a general rule, a contract is formed when both parties agree on the elements of the contract (the matching of the intention to offer and the intention to accept).

Once a contract is formed, both parties are bound by it. If one party fails to fulfill the contract, the other party can enforce performance through litigation or claim damages for non-performance. The “elements of the contract” need to be specific or concrete to the extent that they can be enforced and non-performance can be determined.

The formation of a contract is a very important issue

Formation of a System Development Contract

The nature of a system development contract is primarily a contract for work and a quasi-mandate contract. A contract for work promises the completion of work and payment for it. A paid quasi-mandate contract promises the performance of work and payment for it.

Therefore, if there is an agreement between the parties on the “content of the work or business” and the “amount of remuneration”, which are the elements of the contract, the contract is considered to be formed.

Note that a contract can be formed by a mere verbal promise, and a written contract is not mandatory.

Monetary Claims in Case of Cancellation after the Formation of a System Development Contract

If a system development contract has been formed and the user unilaterally decides to cancel it, legally, it is considered that the user has notified the cancellation of the contract.

If a contract for work has been formed, the vendor is in a position to be compensated for damages if the user can cancel at any time before the work is completed (Japanese Civil Code Article 641). Therefore, if the user does not compensate for damages, the vendor can claim “damages” equal to the amount of expenses incurred by the vendor up to that point and the amount of remuneration that would have been received, subtracting the expenses saved by avoiding system completion.

Also, if a quasi-mandate contract has been formed, the agent can claim remuneration based on the performance ratio when the mandate ends in the middle of performance (Revised Japanese Civil Code Article 648, Paragraph 3). Therefore, the vendor can claim payment for the work that is already done.

Establishment of System Development Contracts

Specificity of System Content

Typically, business transactions between companies, especially those involving large amounts, are conducted in writing. Therefore, if a contract has been drafted, it is easier to have the establishment of the contract to be acknowledged.

Since the system to be developed gradually becomes more concrete through various processes, it is understood that the specificity of the system content, which is an element of the contract, is sufficient if the scope and outline of the system to be developed are clarified.

In court cases, there was no dispute over the conclusion of the basic contract and the confidentiality agreement, and the basic contract stated that “e-commerce technology support, website construction support, and related tasks” were to be entrusted. However, the contract was denied because the specific content of the e-commerce business, the scope of the entrusted tasks, and the scope of development and design as a system were not explicitly stated.

Even if a system development basic contract is created, if the work or task content is abstract and not specified, it is difficult to have the establishment of the contract acknowledged. The establishment of a contract can be acknowledged by a contract that specifies the work or task content and the amount of remuneration to the extent that it can be enforced and non-performance can be recognized.

Vendor Presents Estimates and Specifications, User Approves and Orders

Typically, business transactions between companies are conducted in a written format, so if a contract has not been drafted, it is difficult to have the establishment of the contract acknowledged. In system development, work often begins before a contract is created, but how is whether the contract is concluded or not is determined?

In a court case (Nagoya District Court, January 28, 2004 (Heisei 16)), the establishment of a system development contract was described as follows:

  • After negotiations such as specification confirmation between the vendor and the user,
  • the vendor presents specifications and estimates, etc., and
  • the contract is established by the user approving and ordering this.

In this court case, the vendor was entrusted by the user, a local government, to introduce a financial accounting system, etc. An RFP titled “Request for Submission of Proposal for Introduction of Comprehensive Administrative Information System” was presented, and in response to this, the vendor presented a proposal and an estimate, and the user submitted a “Notice of Adoption”. The vendor did not sufficiently consider the user’s business content, etc., by meeting with the user, and it was not recognized that the content and cost of customization were specifically considered within the user. The content of the vendor’s proposal was not specific, and it was not clear what the user had agreed to, so the establishment contract was not acknowledged.

We will provide additional explanations about the establishment of a contract mentioned in the court case, taking into account other court cases, etc., in below.

After negotiations such as specification confirmation between the vendor and the user

From the phrase “after negotiations”, if the elements of the contract such as the system content and remuneration amount are “under negotiation”, it is difficult to have the establishment of the contract acknowledged because was is not to be agreed upon.

However, in a contract, it is possible to determine the price at market value, so there are court cases where it was recognized that a contract was established with a price equivalent to the market value because the user approved the system content and “approximate” remuneration amount, etc.

In order to say that “negotiations have been conducted”, it is a good idea for the vendor to keep a record of having sufficiently considered the user’s business content, system content, etc., by meeting with the user, etc., in emails or minutes, etc.

The vendor presents specifications and estimates, etc., and the user approves and orders this

  • If the user issues an order form or purchase order, it is easier for the establishment of the contract to be acknowledged. If the vendor submits a request or works based on an order form, etc., it is easier to acknowledge the establishment of the contract as there is more “agreement”.
  • Internal documents from the user often state that a contract is to be concluded in the future, making it difficult for the establishment of a contract to be acknowledged. However, if there is no such description and the elements of the contract such as the content of system development and the amount of remuneration are described as specifically as possible, it will work positively for the establishment of the contract to be acknowledged.
  • If a memorandum, agreement, or confirmation is based on the premise of concluding a separate contract or if the content is abstract, it is difficult to have the establishment of the contract acknowledged.
  • If the contract draft is not stamped, the stamping implies conclusion, making it difficult to have the establishment of the contract acknowledged.
  • An estimate serves as evidence when recognizing the remuneration amount agreed upon between the parties.

Settlement Agreement

If work is performed under the instruction of the user on the premise of concluding a contract, a “settlement agreement” to settle the remuneration for the work up to the time of work stoppage may be recognized. To make this agreement more easily acknowledged, it is a good idea to have the user write down the method of settling the remuneration in the event that a contract is not concluded in an internal document, etc., or to obtain the approval of a person with authority from the user for a document prepared by the vendor.

Legal Structure for Claiming Money When Contract Formation is Not Recognized

What happens when contract formation is not acknowledged?

Negligence in Contract Formation

When negotiations for contract formation begin, the parties involved are obligated to make efforts not to infringe on each other’s property under the principle of good faith (Article 1, Paragraph 2 of the Japanese Civil Code). If a contract is not formed, and there are objective circumstances and culpability that led the other party to expect that the contract would certainly be formed, you can claim damages for breach of this obligation. This is referred to as negligence in contract formation.

Here are some examples of cases where negligence in contract formation was recognized in precedents:

  • A vendor had completed the requirements definition at the request of a user and had also partially implemented the basic and detailed designs. The user explained that the act of inviting other companies to bid was a formal procedure to get approval from the president, but another company was selected just before the contract was to be signed, and the contract was not formed.
  • A vendor was asked by a user to keep to the delivery date and proceeded with the work, with the contract signing date also confirmed to be imminent. However, preparations for in-house development were being made within the user’s company, which was kept secret, and the contract was not formed.
  • A vendor was notified by a user that they had been chosen as the construction contractor, and there were no questions about the estimate, and the vendor carried out tasks such as specification confirmation based on meetings with the user. The user was aware of the vendor’s expenses, but the contract was rejected because they could not agree on the estimated amount.

On the other hand, there are precedents where negligence in contract formation was not recognized, such as when the possibility of selecting another company or the conditions for reaching a contract were explicitly stated.

If you proceed with the work at the user’s request, but the contract negotiations were abruptly broken off for reasons such as the possibility of selecting a company other than your own or the conditions for agreement, which were not explicitly stated, you may be allowed to claim for damages.

There is no dispute that the range of “damages” includes the costs incurred up to that point. In addition to this, there are precedents that include the profit from the actual work performed. Also, if you can present evidence that you suffered damages equivalent to the profit you would have made if you had continued to work after refusing an application from another company, this may also be included.

Article 512 of the Japanese Commercial Code

If a vendor has performed actions related to system development for a user, they can claim a reasonable fee based on Article 512 of the Japanese Commercial Code.

Once you start negotiating about system development, it is a good idea to leave evidence that both parties have recognized the system content and the amount of remuneration, using emails or minutes, and that circumstances that would make the contract formation certain and the elements of the contract have been concretized.

Even if payment is refused for reasons such as not having exchanged a contract, as mentioned above, it is possible to be recognized for a monetary claim.

Summary

As such, it can be said that courts tend to make a ‘negative’ judgment in relation to contractual relationships where no contract exists, especially when compared to the perception of the contracted company. From the perspective of the contracted company, they may want to argue that “we were supposed to start working first and the contract was supposed to be concluded afterwards, so the contract itself is established”. However, this argument is not always accepted.

Furthermore, if the establishment of a contract is denied, there may be cases where money can be claimed based on legal structures such as negligence in contract conclusion or the Japanese Commercial Code Article 512, but this is by no means a ‘certain’ matter.

If you have to start working before the contract is concluded, you need to:

  • Firstly, understand that this is a risky action and make a management decision on whether to allocate man-hours for the project, taking into account the risk. Especially for small and medium-sized enterprises and startups, there may be situations where they have to make a management decision to ‘move first’ in order to gain transaction experience with large corporations. This is a possible management decision if the risk is taken into account.
  • Consider whether it is possible to conclude a liquidation agreement in case the contract is not established.

It can be said that such thinking is necessary.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Return to Top