Most people who search for a system development contract are looking for a template they can use as-is. In practice, however, disputes rarely turn on the wording of individual clauses. They turn on the fact that four items — the contract type, the acceptance criteria, the non-conformity liability, and the ownership of intellectual property — get decided on inconsistent assumptions. These four have to be designed as one set, calibrated to a single variable: how firmly the requirements have been fixed. This article works through how to make those decisions, using the case of a Japanese-owned factory in Thailand commissioning a production management system.
What a system development contract really has to settle — why general principles are not enough
Contract templates are freely available online. Buyers still feel uneasy after reading them, because a template only tells you which clauses to include. It does not tell you how to fill them in for your own situation.
The points that actually cause trouble in system development contracts come down to four. First, whether the contract type should be a contract for work or a quasi-mandate contract. Second, the acceptance criteria — what exactly counts as completion. Third, non-conformity liability, which governs what happens when defects surface after delivery. Fourth, whether the intellectual property in the finished program belongs to the buyer or to the development company.
What matters is that these are not four independent questions. All four are governed by the same variable: how firmly the requirements have been fixed. Settling just one of them in your favour therefore does not stabilise the contract as a whole. On the contrary, the wrong combination produces a contract that contradicts itself.
The most common contradiction is combining a lump-sum contract for work with strict acceptance criteria while the requirements definition is still unsettled. A contract for work is a promise to complete the work, so if what counts as completion has not been determined, the object of the promise does not exist. Write detailed acceptance criteria on top of that and, as development proceeds, every single change triggers the same argument — was this inside the original specification, or is it a new request? The buyer says it was obviously included. The development company says it was outside the agreed scope. Both are right on their own understanding, so the argument never lands.
The reverse pattern also occurs. The requirements and screen designs are completely fixed, yet every phase is placed under a quasi-mandate contract because the development company proposed it that way. In that arrangement the buyer owes payment for the effort expended even if nothing is completed, which means the buyer absorbs almost the entire completion risk. There is no rational reason to accept that when the requirements are already settled.
In other words, the general question of whether a contract for work or a quasi-mandate contract is the correct choice is meaningless. The useful question is how firmly your own requirements are fixed right now, and how to design all four items together around that level of certainty. This article covers that design procedure.
How the cost breakdown itself is determined is covered in our article on what drives the quotation for business system development, and how to choose the supplier is covered in how to select a system development company in Thailand. This article stays out of pricing and vendor comparison and deals only with the legal skeleton of the contract.
One disclaimer up front. This article is a practical guide for people who commission systems. It is not legal advice. For the content of any specific contract, or for handling any specific dispute, always consult a qualified lawyer or other professional.
How a contract for work differs from a quasi-mandate contract
Start with the difference between the two contract types, limited to the effects that matter in practice.
Under a contract for work, the contractor promises to complete the work and the buyer pays for the result. The key point is that payment is tied to the result. If the promised deliverable is not completed, the contractor cannot in principle claim the fee.
A quasi-mandate contract is a contract to entrust the handling of affairs that are not legal acts. The contractor owes a duty to act with the care of a good manager, but does not promise completion of a deliverable. Payment is in principle made for the period worked or the effort expended. Under the amended Civil Code that took effect in April 2020, a form of quasi-mandate in which payment is made for a result is also written into the statute, so a quasi-mandate does not mean that no deliverable can be defined at all.
| Point of comparison | Contract for work | Quasi-mandate contract |
|---|---|---|
| What is promised | Completion of the work | Handling the work with the care of a good manager |
| Responsibility for completion | Borne by the contractor | In principle not borne |
| Basis of payment | Paid for the completed result | Paid for the effort and period worked |
| Non-conformity liability | Applies | In principle does not apply |
| Tolerance of specification changes | Low. Each change needs separate negotiation | High. Changes are absorbed within work instructions |
| Suitable phase | Build and test, once requirements are fixed | Requirements definition, study, operation and maintenance |
Practitioner commentary generally agrees that the requirements definition phase suits a quasi-mandate contract. The reason is plain. Requirements definition is the work of deciding what to build. It is logically impossible to have someone promise the completion of something that has not yet been defined. Force it into a lump-sum contract for work anyway, and the development company will either load the uncertainty into the quotation as a risk premium or interpret the scope narrowly and behave defensively. Neither outcome serves the buyer.
Conversely, leaving the build phase under a quasi-mandate contract after the requirements have been fixed means effort accumulates while nobody carries responsibility for completion. That is the natural point to switch to a contract for work.
The two types are therefore not better or worse than each other. They are right for different phases. The strain comes from trying to cover the whole project with a single contract. Split the phases and change the type, and you avoid the weakness of each.
Which one to choose — decide by how firmly the requirements are fixed
Where should the switch happen? The criterion is how firmly the requirements are fixed. That sounds abstract, but it can be judged by whether you can answer three questions.
First, are the business processes the system will handle, the sites covered, and the departments covered all determined? Second, do you have a list of the main screens and reports, with the input and output items for each one enumerated? Third, are the interface points with existing systems and equipment decided — that is, is it settled what will be connected to what?
If you can answer all three, commissioning the build phase under a contract for work will not create serious friction. If even one answer is that it will be worked out later, that part should be fixed first in a quasi-mandate phase.
| State of the requirements | Recommended contract type | Where acceptance criteria sit |
|---|---|---|
| Scope and interfaces both undetermined | Quasi-mandate (study and concept phase) | Deliverable is a report. Judged on completeness of the items covered |
| Scope decided but screens and items undetermined | Quasi-mandate (requirements definition phase) | Deliverable is the requirements specification. Judged on whether agreed points are reflected |
| Screens, items and interfaces all fixed | Contract for work (design, build and test phase) | Passing the test items derived from the requirements specification |
| Improvement and incident response after go-live | Quasi-mandate (operation and maintenance) | Judged on response time and service levels |
The table shows that contract type and acceptance criteria move together. Acceptance in a quasi-mandate phase is judged on whether an intermediate deliverable — a report or a requirements specification — reflects what was agreed. Acceptance in a contract-for-work phase is judged on whether the tests derived from the requirements specification were passed. If the deliverable of the earlier phase is not fixed, the acceptance criteria of the later phase cannot be written. That order cannot be skipped.
A question that comes up constantly is whether commissioning requirements definition separately under a quasi-mandate contract simply adds cost. It does. But as the original estimate below shows, what increases is visible cost, while what falls is invisible rework and delay. Which is the better deal cannot be settled in the abstract. What you can say is that a proposal with no requirements definition cost in the quotation has not made that work disappear. Either somebody is doing it unpaid, or it is buried inside the build phase.
The meaning of requirements certainty also shifts depending on whether you choose custom development or a package, because a package already carries part of the requirements inside the product. That fork is covered in our article on judging between the three options of custom development and packages.
When and against what the acceptance criteria should be set
Acceptance is the stage of a contract most likely to end in argument. Practitioner guides point out that the single largest cause of acceptance trouble is vague acceptance criteria, and that the remedy is to fix the acceptance criteria before development starts.
Obvious as that sounds, it is rarely done. In most projects the contract states only a procedure — the buyer shall inspect within a defined period after delivery and, if the deliverable passes, shall issue a certificate of acceptance — and says nothing about what passing means. Arrive at delivery in that state and the buyer will judge against its own expectations while the development company judges against what the specification says. The two yardsticks differ, so acceptance is guaranteed to become contentious.
Recent practice increasingly splits acceptance across several points in time rather than doing it once — at the completion of requirements definition, at the completion of design, and at final acceptance. There are two reasons. One is that the cost of rework escalates the later it happens. A problem caught at the requirements specification stage is fixed by rewriting a document. The same problem caught during testing means redoing design, implementation and testing. The other is that it brings forward the moment the buyer sees something real. Imagining a finished system from documents alone is hard for anyone, and confirming a screen prototype early surfaces misunderstandings while they are still cheap.
| Acceptance point | Deliverable covered | Criterion for passing |
|---|---|---|
| Completion of requirements definition | Requirements specification, business flow diagrams | All agreed points recorded without omission and open items listed |
| Completion of design | Basic design document, screen and report definitions | Each item in the requirements specification carried through into the design |
| Final acceptance | The complete working system | The pre-agreed test items meet the pass rate set in advance |
When writing acceptance criteria, these are the items to have in place as a minimum.
- The object of acceptance. Which deliverable is inspected, and in what units
- The method of judgement. Against a test specification, by hands-on operation, or by document review
- The pass or fail line. Whether minor defects pass subject to later correction, or everything must be cleared first
- The inspection period. Within how many business days of delivery the judgement must be made
- The treatment of deemed acceptance. What happens if the buyer does not judge within the period
- The procedure on failure. Redelivery deadline, scope of re-inspection, who bears the cost
Of these, buyers most often overlook deemed acceptance and the treatment of minor defects. If a deemed acceptance clause is in place but no internal inspection capacity has been arranged, a delivery received during a busy period can sit untouched until the deadline passes and the deliverable is automatically treated as accepted. Equally, criteria that tolerate no minor defects at all mean go-live never arrives. The workable approach is to judge pass or fail on whether the business can run, and to correct minor defects against a deadline.
Another approach is to have each bidder submit its proposed acceptance criteria during the competitive quotation stage. It works well as a comparison axis for proposals. That process is covered in detail in our article on running an RFP for a production management system.
Non-conformity liability — how it differs from the old defect warranty
If a defect appears after delivery and after acceptance has passed, how much of it must the development company fix? Non-conformity liability is what answers that.
The amended Civil Code that took effect in April 2020 replaced the former defect warranty liability with non-conformity liability. The change goes beyond the name and includes changes that matter in practice.
The most consequential is the change to when the period for exercising rights begins to run. Under the old regime, rights had to be exercised within one year from delivery. After the amendment it is enough to give notice within one year from the point at which the non-conformity became known. That widens the room for a buyer to seek a remedy for a defect discovered long after delivery.
The other change is that remedies were written into the statute. The amended Civil Code expressly provides for a demand for cure and a demand for price reduction. A demand for cure is the right to require the non-conforming part to be repaired, or a substitute to be delivered, so that the state of the deliverable conforms to the contract. A demand for price reduction is the right to seek a reduction proportionate to the non-conformity where cure is not provided. Damages and termination were already available, so two further options were added alongside them.
Note, however, that the non-conformity liability provisions can be varied by agreement between the parties. In practice it is not unusual for a contract to shorten the liability period, or to cap the scope of liability at the total fees the buyer has paid. Templates presented by development companies normally contain limitations of this kind. As the buyer, do not simply check whether the clause exists. Check how the period and the cap are written.
There is also the perennial argument in system development over where a defect ends and a specification change begins. A system that behaves exactly as specified but is awkward for the business is not a non-conformity; it is a request for a specification change. Keeping that line out of after-the-fact debate is precisely why it matters how concretely the requirements specification and the acceptance criteria were written. Thickening the non-conformity liability clause alone achieves nothing while the specification it is measured against remains vague.
Who owns the intellectual property
We paid for it, so the finished system is ours. That is a natural instinct, and legally it is wrong.
If the contract says nothing, copyright in the developed system belongs to the development company — the contractor. The programs were actually created by that company’s employees. A buyer that wants to hold the copyright has to state the assignment expressly in the contract.
The part most often overlooked here is the right to modify. Rewriting a program can amount to adaptation under copyright law. So if copyright stays with the development company, a buyer that commissions maintenance or modification from a different company risks infringing copyright. The problem surfaces years later, when the relationship with the original developer ends, or when the buyer wants to switch because response times have become unacceptable.
In practice there are three broad options.
- Assign copyright entirely to the buyer. This gives the buyer the greatest freedom, but the development company can no longer reuse comparable assets on other projects, so the quotation may rise
- Leave copyright with the development company while granting the buyer a licence to use and modify. If the licence expressly permits maintenance to be commissioned from third parties, the practical drawbacks are small
- Separate the general-purpose parts from the bespoke parts. Libraries and shared foundations stay with the development company, and only the business-specific logic is assigned to the buyer
The third option is rational, but a vague boundary plants the seed of a future dispute. It is far better to enumerate concretely, at the time of contracting, which components count as general-purpose modules.
Where an assignment is agreed, standard practice is also to address non-exercise of moral rights. Moral rights cannot be assigned, so the mechanism is an agreement not to exercise them. Because the drafting here determines the outcome, we strongly recommend having a lawyer review this point.
Two gaps that get overlooked in non-disclosure agreements
Most companies will already have signed a non-disclosure agreement at the request-for-proposal stage. Precisely because it comes so early, the template often gets reused without scrutiny, and two points can be missing from the version in force.
The first gap is that the obligation does not reach subcontractors. In system development it is common for the development company to subcontract part of the work to another company or an offshore site. If the non-disclosure agreement names only the development company, the people actually handling your drawings and cost data sit outside the contract. You need to settle whether subcontracting is permitted at all and, if it is, to state expressly that equivalent confidentiality obligations are imposed on the subcontractor and that the development company is responsible for the subcontractor’s acts.
The second gap is that there is no prohibition on use outside the purpose, and no treatment of what happens after the contract ends. Many non-disclosure agreements provide that information will not be disclosed to third parties, but stop short of providing that it will not be used for any purpose other than the project. That leaves room to argue that reusing the material in the company’s own analysis or in proposals to others is not prohibited as long as nothing is disclosed. You should also settle what happens to the data you provided once the project ends — whether it is returned or destroyed, and how destruction is to be evidenced. If you handed over production data for testing, the presence of that single sentence makes a real difference.
Non-disclosure agreements tend to be signed once and then used for years without review. The moment you sign the development contract is a good opportunity to inspect these two points.
Learning from a real case — what happens when the contract is designed badly
The case most often cited as an example of weak contract design escalating into a large-scale dispute is the system development litigation between Suruga Bank and IBM Japan.
According to press reports, the Tokyo District Court handed down a judgment on 29 March 2012 ordering a payment of approximately 7.4 billion JPY. On appeal, the Tokyo High Court handed down a judgment on 26 September 2013 reducing that sum to approximately 4.2 billion JPY. The Tokyo High Court was reported to have held that the uncertainty inherent in the early stages of a project calls for a proportionate share of risk to be borne by the user company as well.
This article is not a case commentary, so it will not go into the legal assessment. What matters for a practitioner is the following.
First, regardless of the size of the sums, the issue in contention was who had assumed how much of the uncertainty of the early stages. Second, that allocation was judged from both the drafting of the contract and the way the project was actually run. Third, the very fact that the first instance and the appeal reached different conclusions shows that this question does not resolve itself easily.
Turn that around and it means that a contract placing full responsibility for completion on one side while the requirements are still unsettled is unstable, whatever the size of the project. Small and mid-sized projects rarely reach court. Instead the loss appears as drawn-out negotiations over additional fees, a delayed go-live, and a broken working relationship between the people involved. It simply never gets totalled up as a figure. What is lost is the same.
Contracts are not the only reason implementations go wrong. The full set of items to settle internally before commissioning anything is covered in our article on why production management system implementations fail.
Three additional clauses you need when contracting in Thailand
Everything so far has been general principle on the assumption of Japanese law. Where a Thai subsidiary is the buyer, or where a Japanese head office contracts with a Thai development company, there are additional clauses to check. Simply translating the contract you used in Japan into Thai can leave you with a contract that does not work.
First, the governing law. Which country’s law the contract is interpreted under can be selected by agreement of the parties. Japanese law is possible, and so is Thai law. But if the chosen governing law conflicts with the jurisdiction clause discussed below, you end up having to prove the content of Japanese law in a Thai court, which makes the procedure far heavier.
Second, the language of prevalence. Under the provisions of the Thai Civil and Commercial Code, where a contract has been prepared in several languages and no order of precedence is stated, the Thai version is understood to prevail. Exchanging only a Japanese and an English version and assuming you are safe leaves room for unexpected interpretations to be asserted once a Thai translation appears later. The practical response is to choose one of two routes — designate the English version as the authoritative text and position the Thai and Japanese versions as translations, or state expressly that the Thai version prevails and then scrutinise the Thai wording. Circulating three languages side by side with the point left vague is the most dangerous option.
Third, the jurisdiction. If you envisage claiming payment or damages against a Thai entity, an agreement designating the Thai courts as the forum is effectively essential. A favourable judgment obtained in a Japanese court cannot be enforced directly in Thailand. The combination of Japanese law and Japanese courts feels reassuring from the Japanese side, but it lacks practical effect when the counterparty’s assets are in Thailand.
| Clause | What it settles | Risk if left unsettled |
|---|---|---|
| Governing law | Which country’s law governs interpretation | The interpretive basis is unfixed and the evidential burden grows |
| Language of prevalence | Which language version is authoritative | The Thai version is taken to prevail and unexpected readings arise |
| Jurisdiction | Where disputes are resolved | A judgment cannot be enforced against the counterparty’s assets |
There is one more point, on the contract type itself. The Thai Civil and Commercial Code contains a contract type called hire of work, which is the concept closest to the contract for work under Japanese law. It is defined as a contract under which payment is made for the result of completed work, and it is set out in statutory provisions. On the other hand, there is no contract type in Thai law that corresponds strictly to the Japanese quasi-mandate contract, that is, the mandate of affairs which are not legal acts.
So when you contract with a Thai development company for a requirements definition phase, writing that the contract shall be a quasi-mandate contract conveys nothing. Instead, the contract has to describe concretely, as a matter of the nature of the work, whether that work promises the completion of a deliverable or whether payment is made in return for the provision of services. What will be submitted as a deliverable, what the payment is earned against, and whether or not a guarantee of completion is included all have to be written out fully in the words of the clause.
Regional differences in practice also matter if you develop in a neighbouring country. The points that arise when developing in Vietnam are collected in our article on system development in Vietnam.
Original estimate — the rework cost created by a contract type mismatch
Now let us convert the argument so far into money. What follows is an original estimate based on a model case; the figures are not those of any actual company. Read it for the structure it reveals rather than for the size of the amounts.
Start with the assumptions. A Japanese-owned factory in Thailand is commissioning the replacement of its production management system. The contract value of the build phase is 3,000,000 THB. The standard unit price for additional development is 3,000 THB per person-day, and the standard development effort per specification change is 3 person-days. On that basis, compare two cases with different levels of requirements certainty.
In Case A, the build phase is contracted as a lump-sum contract for work while the requirements definition is 60% settled. After the contract was signed, 8 specification changes arose.
| Item | Calculation | Amount |
|---|---|---|
| Additional development at the standard rate | 8 changes × 3 person-days × 3,000 THB per person-day | 72,000 THB |
| Additional overhead from case-by-case negotiation | 8 changes × 4,500 THB | 36,000 THB |
| Case A total additional cost | 72,000 + 36,000 | 108,000 THB |
The overhead of 4,500 THB per change puts a figure on the work required to process a specification change through case-by-case negotiation after the contract has been signed. Investigating the scope of impact, redoing the quotation and holding an additional agreement meeting are together assumed to amount to 1.5 person-days per change. Under a contract for work, work outside the contracted scope cannot proceed unpaid, so that negotiation happens every single time.
There are also costs that never show up as money. Of those 8 changes, 5 spanned several modules, and those took an average of 6.4 business days each to agree. In total, 5 changes × 6.4 business days gives 32 business days accumulating as delay on the critical path. That delay is not converted into money here. On top of it, the longer negotiations drag on, the higher the risk of escalation into a dispute and the more the working relationship between the people involved is damaged. These cannot be quantified, but in practice they can be the heaviest cost of all.
In Case B, the requirements definition phase is carved out separately as a quasi-mandate contract, certainty is raised to 95%, and only then is the build phase contracted as a contract for work. The requirements definition phase runs for 2.5 months at 150,000 THB per month, giving a contract value of 375,000 THB.
| Item | Calculation | Amount |
|---|---|---|
| Requirements definition phase (quasi-mandate contract; not included in the total additional cost) | 2.5 months × 150,000 THB | 375,000 THB |
| Additional development at the standard rate | 2 changes × 3 person-days × 3,000 THB per person-day | 18,000 THB |
| Additional overhead from case-by-case negotiation | 2 changes × 4,500 THB | 9,000 THB |
| Case B total additional cost | 18,000 + 9,000 | 27,000 THB |
Specification changes after contract signature fell to 2. The total additional cost is 27,000 THB. Against Case A at 108,000 THB, the calculation 108,000 ÷ 27,000 gives a gap of 4.0 times. The difference is 108,000 − 27,000, which is 81,000 THB.
Here is the part that has to be stated honestly. Case B invests 375,000 THB up front in the requirements definition phase. The additional cost it avoids is 81,000 THB. Since 81,000 THB is below 375,000 THB, that investment does not pay back in cash terms. Saying that separating out requirements definition lowers your costs would not be accurate.
| Comparison item | Case A | Case B |
|---|---|---|
| Contract for the requirements definition phase | No separate contract | 375,000 THB |
| Specification changes after contract signature | 8 changes | 2 changes |
| Total additional cost | 108,000 THB | 27,000 THB |
| Critical path delay | 32 business days | None occurred |
So why recommend separating out requirements definition at all? Because what you recover is not money. It is the avoidance of 32 business days of delay and the reduction of the risk of escalation into a dispute. Assess, on an axis other than money, how heavily a 32 business day slip in go-live weighs on your own business plan, and what you stand to lose if post-contract negotiations turn into a dispute. Where the start of factory operations or a fiscal closing deadline cannot be moved, 32 business days of delay carries far more weight than a difference of 81,000 THB. Conversely, on a small project with a comfortable deadline and relatively simple requirements, the Case A approach can be the rational one.
Either way, the decision to carve out requirements definition under a quasi-mandate contract is made because you want to eliminate uncertainty early, not because it will be cheaper. Start it expecting an outsized return on investment and you will be disappointed.
Contract checklist — what to confirm before you commission
Here the material above is reordered into the sequence in which you should read a contract when one lands on your desk. Working through a template from a development company in this order makes omissions less likely.
| Item to confirm | What to look at |
|---|---|
| Contract type | Are contract for work and quasi-mandate split appropriately by phase? Does a single contract cover the whole project? |
| Scope of work | Are the target processes, sites and departments identified? Are the assumptions enumerated? |
| Definition of deliverables | Is what will be delivered in each phase enumerated? Is the level of detail of documents stated? |
| Acceptance criteria | Are the method of judgement and the pass or fail line written down? Are they fixed before work starts? |
| Acceptance period | Is the inspection period one your organisation can actually meet? What triggers deemed acceptance? |
| Specification change procedure | Are the way to raise a change, the impact assessment period and the method of pricing all defined? |
| Non-conformity liability | How long is the liability period? Is there a cap? What are the exclusions? |
| Intellectual property | Assignment or licence? Are the right to modify and third-party maintenance permitted? |
| Confidentiality | Does the obligation reach subcontractors? Are use outside the purpose and post-termination handling covered? |
| Subcontracting | Is prior consent required? Is the development company responsible for the subcontractor’s acts? |
| Damages | Is there a cap? Is it stated whether lost profit is included? |
| Termination for convenience | Who can terminate and when? Is the method of settling work in progress written down? |
| Governing law | Which country’s law applies? Is it consistent with the jurisdiction clause? |
| Language of prevalence | Is it stated which language version is authoritative? |
| Jurisdiction | Does the agreement allow enforcement in the country where the counterparty’s assets are? |
Of this list, the first five are the ones the buyer can settle on its own — contract type, scope of work, definition of deliverables, acceptance criteria and acceptance period. Do not leave these to the development company to fill in. Go into the negotiation with your own draft. The remaining items are of a different character; there the task is to read the template closely and check that the terms are not unfavourable.
You do not need to get everything perfect at once. But for the four items of contract type, acceptance criteria, non-conformity liability and intellectual property, always confirm that they are consistent against the same yardstick of requirements certainty. A contract in which those four pull in different directions will not work no matter how many clauses it contains.
How to use the IPA model contract
You do not have to draft a contract from scratch. A neutral template published by a public body is available.
The Information-technology Promotion Agency, Japan (IPA) published the second edition of its Model Transaction and Contract for Information Systems on 22 December 2020. It was prepared as a template that aims to favour neither user companies nor IT vendors, and guidelines on security specifications were published at the same time.
The value of this model contract is not that you can use it as-is. It is that you can see how the issues — dividing contract types by phase, the acceptance procedure, the handling of intellectual property — get organised into actual clause language. Read it side by side with the template a development company has given you, and it becomes visible which clauses have been dropped and which have been rewritten to favour one side.
For practical use we recommend this order. First read the model contract through to grasp the overall picture of the issues. Next, map the contract from the development company against the model contract’s table of contents. Where an issue is missing, ask the development company why. Then rewrite the contract type and acceptance criteria sections to match your own level of requirements certainty.
There are caveats. The model contract assumes Japanese law, so it cannot be applied as-is to a contract in Thailand. The three clauses discussed above — governing law, language of prevalence and jurisdiction — have to be added, and the treatment of the quasi-mandate type has to be reinterpreted. Use it strictly as a map for checking that no issue has been missed, and have the final clause language reviewed by a professional familiar with local legal practice.
Frequently asked questions
Which is safer, a contract for work or a quasi-mandate contract?
Neither is inherently safer. For phases where the requirements are fixed, a contract for work is more favourable to the buyer because it places responsibility for completion on the development company. But sign a contract for work for a phase where the requirements are not settled, and every specification change triggers a separate negotiation, which ends up working against you. Safety is not determined by the type. It is determined by the combination of the type and the level of requirements certainty.
When should the acceptance criteria be decided?
Before development starts. Practitioner guides repeatedly point out that vague acceptance criteria are the single largest cause of trouble, and that the criteria should be fixed before work begins. Trying to write the criteria just before delivery never converges, because each side argues for a standard that favours it. Ideally you decide how each requirement will be inspected at the same time as you finalise the requirements specification.
How long should the non-conformity liability period be?
There is no single right answer. The amended Civil Code created a framework of notice within one year from the point at which the non-conformity became known, but the contract can set a shorter period, and such clauses are common in practice. A useful guide is whether the system has seasonal operation. If it contains fiscal closing or stocktaking functions that run only once a year, a short period makes it impossible even to discover the defect.
Should copyright always be assigned to us?
Not necessarily. Demanding an assignment can push the quotation up. What matters in practice is less ownership itself than securing a state in which you can keep modifying the system in future. Even with copyright remaining with the development company, if you hold a licence to use and modify and third-party maintenance is permitted, the practical drawbacks stay small. Conversely, even with an assignment clause, a vague boundary around general-purpose modules leaves you unsure how freely you can act.
Is translating our Japanese contract into Thai enough?
No. You need the three clauses on governing law, language of prevalence and jurisdiction. In particular, if the language of prevalence is not stated, note that under the provisions of the Thai Civil and Commercial Code the Thai version is taken to prevail. And because Thai law has no contract type corresponding strictly to the Japanese quasi-mandate contract, the nature of the work has to be described concretely within the clauses themselves.
Does a small project really need a contract built out to this level?
A small contract value does not make disputes less likely. That said, if you have limited time and need to prioritise, prioritise two things — the acceptance criteria and the intellectual property. Acceptance criteria decide directly whether payment is due, and intellectual property decides directly how freely you can switch suppliers a few years later. With those two secured, leaving the other clauses at the standard template makes a catastrophic outcome much easier to avoid.
Summary
What a system development contract has to settle is four items — the contract type, the acceptance criteria, the non-conformity liability, and the ownership of intellectual property. These are not independent questions. All four are governed by a single variable, how firmly the requirements have been fixed. Decide them separately and you produce a contract that contradicts itself.
The debate over whether a contract for work or a quasi-mandate contract is correct is beside the point. In practice you use them by phase — quasi-mandate for requirements definition, contract for work for the build phase once the requirements are fixed. Set acceptance criteria before work starts and split acceptance across the completion of requirements definition, the completion of design and final acceptance, and rework in later phases shrinks. Non-conformity liability changed with the amended Civil Code that took effect in April 2020, both in when the period starts running and in the remedies available, but it can be varied by contract, so always check how the period and the cap are written. Intellectual property belongs to the development company unless you say otherwise. In practice, whether modification and third-party maintenance are permitted matters more than ownership itself.
In the original estimate, Case A — a lump-sum contract for work signed while requirements were 60% settled — carried 108,000 THB of additional cost, against 27,000 THB for Case B, which carved out requirements definition under a quasi-mandate contract. That is a gap of 4.0 times. But the 375,000 THB invested up front in requirements definition is not recovered in cash by a difference of 81,000 THB alone. What is recovered is the avoidance of 32 business days of delay and a lower risk of dispute — value that resists being put into money. Being able to explain that honestly inside your own organisation matters when you take the proposal through approval.
When contracting in Thailand, always add the three clauses on governing law, language of prevalence and jurisdiction. A translated Japanese contract will not work on its own. And to repeat, this article is a practical guide, not legal advice. Have the content of any specific contract checked by a qualified lawyer or other professional.
How you fill in the clauses of a contract comes down, in the end, to how far your own requirements have been fixed. It is perfectly fine if you cannot yet judge that level of certainty yourself, or if you do not know which parts of the contract a development company has handed you should be negotiated. Drawing on our experience of production management system implementation and contract practice in Thailand, we are happy to help simply by organising where you stand. Please get in touch through our contact page.
References
- BUSINESS LAWYERS — The difference between a contract for work and a quasi-mandate contract, and how to use each in system development
- BUSINESS LAWYERS — Non-conformity liability in system development in practice
- Tokyo Startup Law Office — Non-conformity liability in system development
- Human Navi — What acceptance means in system development, and how to set acceptance criteria that prevent trouble
- Shu Sogo Office — Copyright ownership and the right to modify in system development
- Information-technology Promotion Agency, Japan (IPA) — Model Transaction and Contract for Information Systems, Second Edition
- Nikkei — Appeal judgment in the system development litigation between Suruga Bank and IBM Japan
- GVA Law Office — Contract practice in Thailand and how to approach governing law, language and jurisdiction
- Legal Execution Thailand — Thailand Civil and Commercial Code, Title VII Hire of Work
