Short answer
A software development contract in Thailand needs ten clauses: scope, milestone payments, copyright and source code, acceptance, change requests, warranty, support, personal data, termination and tax. Scope causes most disputes; write it as a list of what users must be able to do, and use that list as the acceptance test. This is not legal advice.
Key points
- Write scope as tasks users must be able to complete; the same list becomes the acceptance test.
- Tie each payment to an accepted deliverable, not a date, with testing and fixing deadlines on both sides.
- Section 10 of the Copyright Act gives commissioned work to the client unless agreed otherwise; source-code handover still needs its own clause.
- A juristic-person client normally withholds 3%, and a hire-of-work contract carries THB 1 stamp duty per THB 1,000.
- If the system holds personal data, PDPA section 40 requires an agreement with the developer as data processor.
What clauses should a software development contract include?
Ten, and each needs a written answer. If the draft is silent on one, ask before signing; the clause nobody wrote down is usually the one argued over near the end.
This guide is written from the buyer's side, to check a draft against. It is not legal advice, and the final contract should always go past a lawyer.
- Scope: a list of what each user group must be able to do, attached as a schedule.
- Payments: each milestone tied to an accepted deliverable, not a calendar date.
- Copyright and source code: who owns it, and when and how the code is handed over.
- Acceptance: what is tested, within how many days, and what happens on failure.
- Change requests: how extra work is requested, priced and approved.
- Warranty: how long defects are fixed free after acceptance.
- Support: what it covers and costs, separate from the build price.
- Personal data: the developer's duties as a data processor under PDPA.
- Termination: what is paid and what you receive if the project stops midway.
- Tax: whether VAT is included, and withholding tax and stamp duty.
How do you write the scope of work so nobody argues later?
Write scope as a list of tasks each group of users must be able to complete, and use the same list as the acceptance test. That works better than a list of screens or a sixty-page requirements document nobody reads to the end.
Once the list is the scope, anything on it must pass and anything off it is a change request. "Is this included in the price?" is answered by opening the list. Have the real users in each department read and sign the list, not one executive.
- Sample item: a salesperson creates a quotation from the product list and sends it to their manager for approval.
- Sample item: a manager sees every quotation awaiting approval and approves it or sends it back with a reason.
- Sample clause: "The scope of this agreement is the list of acceptance tests in Schedule A. Work not listed in Schedule A is a change under the change-request clause."
How should milestone payments and acceptance testing work?
Tie each payment to a deliverable that passes its tests, such as "the sales module passes Schedule A", rather than to a calendar date. Keep the upfront payment to an amount you could afford to lose if the project stalls.
Acceptance needs deadlines on both sides: how many days the client has to test, what happens if it does not respond in time, and how many days the developer has to fix what failed. Without them, work tends to sit in "awaiting acceptance" for a month.
- Sample clause: "The Client will test each milestone against Schedule A within 10 business days of notice of delivery and will list any failed items in writing."
- Sample clause: "Minor defects that do not prevent use as described in Schedule A are not grounds for refusing acceptance; the Developer will fix them within the warranty period."
- Notice of deliveryThe developer gives written notice that the milestone is delivered.
- TestingThe client tests against Schedule A within the agreed number of days.
- Written resultsFailures are listed in writing; minor defects are not grounds to refuse acceptance.
- FixesThe developer fixes failed items within the agreed number of days.
- Acceptance and paymentThe milestone is accepted and its payment falls due.
Who owns the copyright and source code of commissioned software in Thailand?
Section 10 of Thailand's Copyright Act B.E. 2537 (1994) gives copyright in work created under a hire-of-work arrangement to the employer, unless the parties agree otherwise. Owning the copyright does not put the code in your hands, though: the contract has to say what is handed over, when and where.
Components the developer brings with it, such as its own libraries or open-source software, do not all become yours. The contract should grant you a perpetual right to use them at no extra charge.
- All source code lives in a repository opened in the client's account from day one, not handed over as a file at the end.
- Server, domain and third-party service accounts are opened in the client company's name.
- Installation documents, system credentials and deployment steps are part of the handover.
- Sample clause: "Copyright in work created under this agreement belongs to the Client. For components the Developer owned beforehand, the Developer grants the Client a perpetual, royalty-free right to use, modify and have others maintain them."
How should change requests, warranty and support be written?
Change requests need a process, not a ban; almost every system gets extra work. Request it in writing, have the developer price and schedule it, and approve before work starts. An unapproved change should never hold up acceptance of the original scope.
Keep warranty and support apart. Warranty means fixing anything that does not match the list, free, for an agreed period. Support is paid, ongoing work such as security updates, monitoring and small adjustments. Put the support price in writing now, even if you do not sign for it yet.
- Written requestThe client writes down what it wants added or changed.
- EstimateThe developer prices and schedules the change.
- ApprovalThe client approves the price and timing before the change starts.
- Separate acceptanceThe change is accepted on its own and never delays the original scope.
What should the contract say about PDPA, termination and tax?
If the system holds personal data, a developer with access to it is a data processor, and section 40 of the Personal Data Protection Act B.E. 2562 (2019) requires the controller to have an agreement with the processor. That can be clauses in the contract or a separate data processing agreement (DPA).
The termination clause should say that if the project stops midway, the client pays only for delivered work and receives the source code for it. On tax, a juristic-person client normally withholds 3% on hire-of-work fees, and a hire-of-work contract carries stamp duty of THB 1 per THB 1,000 of the fee under Instrument 4 of the Stamp Duty Schedule.
- State whether the price includes VAT, if the developer is VAT-registered.
- State that withholding tax is calculated on the amount before VAT.
- The processor must delete or return personal data when the contract ends.
- withholding on hire-of-work fees, juristic-person client
- 3%
- stamp duty per THB 1,000 of the fee (Instrument 4)
- THB 1
- PDPA: agreement required with the data processor
- Section 40
Where do software development contracts usually fail?
Rarely on legality. They fail because the wording is broad enough for each side to read it differently. These are the five gaps that come up most, and the wording that closes each one.
Wording that fails
- Scope reads "a complete sales system", with no list
- Large payments before any work is seen
- Source code held in the developer's account
- No acceptance deadline; work waits for months
- Annual support bundled into the build price, no end date
Wording that protects
- Scope is the test list in Schedule A
- Each payment tied to an accepted deliverable
- Repository in the client's account from day one
- Testing and fixing deadlines on both sides
- Support priced separately, with a clear term
Checklist before signing a software development contract
- Is scope a list of what users must be able to do, read by the real users?
- Is every payment tied to an accepted deliverable?
- Are there acceptance and fix deadlines on both sides?
- Is the source code in your company's account from day one?
- Is there a written change-request process?
- Are warranty and paid support separate, with support priced?
- Is there a data processing agreement if the system holds customer data?
- Do you know what you pay and receive if the project stops midway?
Frequently asked questions
Who owns the source code of commissioned software in Thailand?
Under section 10 of the Copyright Act B.E. 2537, copyright in commissioned work belongs to the employer unless the parties agree otherwise, so a clause giving copyright to the developer overrides that default; read it carefully. Handover of the source code must still be written in separately, because owning the copyright does not deliver the files.
How much withholding tax applies to software development fees in Thailand?
A juristic-person client normally withholds 3% of the fee before VAT, because software development is treated as hire of work. An individual paying personally does not withhold. Classification follows what the contract actually describes, so check with your accountant before the first payment.
Does a software development contract need stamp duty in Thailand?
Yes. A hire-of-work contract carries stamp duty of THB 1 for every THB 1,000, or fraction of THB 1,000, of the fee, under Instrument 4 of the Stamp Duty Schedule. The law places the duty on the contractor, but in practice the contract usually says which party pays it.
Can a signed quotation replace a software development contract?
For a small job with clear scope it may be enough. Most quotations, however, say nothing about copyright, acceptance, change requests, personal data or termination, which are where disputes start. If you use a quotation, attach the ten clauses in this guide as a schedule both parties sign.
Do I need a data processing agreement with my software developer?
Yes, if the developer has access to real personal data. Section 40 of Thailand's PDPA requires the data controller to have an agreement with its data processor. It can be clauses in the development contract or a separate DPA, and at minimum it should require the developer to delete or return the data when the contract ends.
What happens if I cancel a software project halfway?
It depends on the termination clause. The clause that protects the client says it pays only for work already delivered and accepted, and receives the source code for that work. Without such a clause, ending a project midway usually turns into a negotiation, so agree the terms before signing.