Software Development Agreement in Serbia: What to Check Before Signing

Home → Blog → Software Development Agreements in Serbia

Updated: 20 October 2026 Author: Kristijan Stoiljković, Attorney at Law · Next review: January 2027

The project is finished, but the client wants more changes before paying. The team hands over the code, then finds the client claiming rights in tools the company built years earlier. Or the company accepts a contractual penalty believing it caps its exposure, when it does not. A software development agreement should tie scope, payment, acceptance and code ownership into one coherent system.

For a Serbian software company working for domestic or foreign clients, a contract that states a price and a deadline is not enough. What matters is what happens when requirements change, the client goes quiet, or the relationship ends early. This article is written from the developer's side and under Serbian law, but the same questions matter to clients, including foreign companies that contract with development teams in Serbia. Even where a contract is governed by foreign law, Serbian rules on who owns code written by your employees still shape the rights you can pass on.

At a glance: five checks before you sign

1. Scope: are the MSA, SOW and specification aligned, and who approves extra work?
2. Payment: do milestones, payment terms and taxes give you a predictable net payment?
3. Acceptance: is there a review period with a clear consequence when it expires?
4. Code ownership: are commissioned code, your pre-existing components and third-party materials kept separate?
5. Liability: does the cap cover contractual penalties, and do the carve-outs leave it intact?

Have a draft contract on the table?

We review the agreement together with the proposal, SOW and specification, identify the priority risks, and propose amendments and negotiating positions that fit your project's business model.

Request a contract review →

What does a software development agreement cover, and how do the MSA and SOW fit together?

A software development agreement governs the building of an agreed solution and the parties' rights and obligations along the way. In a longer relationship, a Master Services Agreement (MSA) sets the general terms, while each Statement of Work (SOW) describes a specific project: deliverables, price and timeline. The technical specification sets out functionality and test criteria.

These documents need a clear order of precedence. If the proposal covers a limited number of integrations but the MSA promises "all integrations necessary for the client's business," you have the makings of a dispute. Specify when a SOW may depart from the MSA and who must approve it.

Bespoke development is different from licensing an existing product or providing SaaS, where the client mainly gets access to software. One project can combine all three, but each needs its own terms.

Scope: what exactly does the price include?

"Development of an application in line with the client's needs" leaves open what "done" means. The specification should cover functionality, integrations, supported environments, documentation and phased deliverables. State your assumptions and exclusions: data migration, training, hosting and support are not necessarily part of the same job.

Set a measurable criterion for each key deliverable. Instead of promising a "fast" system, specify the conditions under which response times are measured. Obligations without a defined environment and load can turn out much broader than what the team priced in.

Payment: pricing model, payment terms and tax

A fixed price works when scope is well defined. The developer then needs to price its assumptions carefully and have a clear process for additional work. Under time and materials, fees are based on time spent and agreed resources, so rates, time records and budget controls are what matter.

Agree on advance payments or milestone invoicing, currency, due dates and how invoices may be disputed. Consider providing that a dispute over part of an invoice does not delay payment of the undisputed amount.

With Serbian clients, payment terms are not entirely up to the parties. The Law on Deadlines for Settlement of Monetary Obligations in Commercial Transactions provides that contracts between businesses generally may not set a payment term longer than 60 days. Where the debtor is a public sector entity, the limit is 45 days. The law allows certain exceptions, so check the agreed term against its current text. Serbian law does not allow a contractual penalty for monetary obligations, so late payment is addressed through statutory default interest, security instruments (such as blank promissory notes, widely used in Serbia, or bank guarantees) and an agreed right to suspend work.

With foreign clients, check the tax position up front: VAT, any withholding tax in the client's country and whether a double tax treaty applies. The net amount you expect must match how the contract allocates taxes and transfer costs. In a cross-border deal, a clause stating that "all prices are inclusive of taxes" may mean that you bear the withholding tax. More on this: tax law.

Regulate any right to suspend work for non-payment through notice, a grace period and the consequences for the project plan. An unpaid invoice alone does not justify arbitrarily switching off a production system.

Change requests: additional work needs an approval process

Agile development does not mean unlimited scope for the same price. The change request procedure should set out who submits a request, who assesses its impact and who approves the price and the new timeline. The agreed channel may be email or a project management tool, as long as it is clear who has authority to approve.

Sample clause · change of scope"Any change to scope, timeline or price shall be made on the basis of a written change request. Within [five] business days, the Contractor shall provide an assessment of the change's impact on price, timeline and resources. The Contractor shall not be required to start work on the change until a person authorized under [Annex X] has approved the assessment in writing; until then, work shall continue under the current SOW."Illustrative only. Adapt deadlines, authorized persons and communication channels to your project and the rest of the agreement.

Distinguish a budget estimate from a firm cap. Build in a warning when an agreed threshold is approaching, and a rule for whether work continues. Your sales team and project manager should follow the same procedure the contract describes.

Deadlines also depend on the client

Delivery dates may depend on access to infrastructure, test data, decisions and client feedback. Allocate these obligations and dates in the contract. Provide for notice of blockers, a reasonable extension of deadlines and how the cost of remobilizing the team is charged.

Tie client delays to their actual impact on the project. A blanket clause excusing the developer from all obligations whenever the client is late says little about what actually happened. Keep a record of requests, responses and plan changes.

Acceptance: how to avoid waiting indefinitely for sign-off

Specify how delivery is made, when testing starts, the review period and what a substantiated objection must contain. Distinguish a defect against the specification from a new feature. Agree which defects block acceptance and which are fixed later according to a plan.

Serbian law gives the developer some protection. Where the rules on contracts for work (ugovor o delu) apply, the work is deemed accepted if the client, without good reason, fails to respond to the contractor's invitation to inspect and accept it (Article 614(2) of the Law on Obligations). Send that invitation in a way you can prove. In a dispute, however, the question will be whether the client had good reason, so the contract should still set the review period, the content of objections and the evidence of delivery.

Sample clause · acceptance"The Contractor shall notify the Client of delivery when the deliverable is available in the agreed test environment, together with the documentation required for testing. Within five business days of receiving that notice, the Client shall test the deliverable against the criteria in the Specification and provide the Contractor with either a signed acceptance certificate or a substantiated list of defects constituting deviations from the Specification. If the Client fails to provide substantiated objections within that period, or begins to use the deliverable in live production other than in trial use agreed for testing purposes, the deliverable shall be deemed accepted. Defects classified as minor under [Annex X] shall not be grounds for refusing acceptance and shall be remedied in accordance with the agreed plan."Illustrative only. Define defect categories (e.g. critical, major, minor) in an annex and check consistency with the payment schedule and warranty provisions.

Hypothetical example: The client uses the delivered module but does not sign the acceptance certificate and holds back the final payment. Clearly defined criteria, proof of delivery and a rule on production use make it easier to establish whether acceptance has taken place.

Who owns the code? If the contract is silent, the risk sits with the developer

Separate newly developed code, the developer's pre-existing components and third-party materials. For each category, define what the client gets and on what terms. Handing over source code, granting a license and assigning economic rights are three different things.

For commissioned software, the default rule favors the client. Where a computer program is created under a commission agreement, the Serbian Law on Copyright and Related Rights provides that the commissioning party acquires the rights to exploit it, unless the contract provides otherwise (Article 95). The rule applies to the program that was commissioned. It does not mean your existing libraries and tools automatically pass to the client. But if the contract does not draw a line between what was commissioned and what already existed, there is room for a dispute. And a developer can only pass on rights it has itself acquired from employees and contractors. So separate three categories expressly: commissioned code, the developer's pre-existing components, and rights obtained from authors and third parties.

For programs written by employees in the course of their duties, the employer holds the exclusive economic rights permanently, unless the employment contract provides otherwise (Article 98). For computer programs, an employee is entitled to special remuneration only if the contract provides for it; there is no automatic right. The employment contract should therefore state clearly whether special remuneration is payable or whether work on software is covered by salary. Moral rights cannot be transferred by contract.

Serbian development teams often include contractors registered as sole proprietors rather than employees. Your contract with each developer must transfer rights that cover everything you promise the client, including the right to modify the code, to assign or license it further and to incorporate existing components. Do not assume that design and other supporting materials are subject to the same regime as computer programs.

If the transfer of the agreed rights is conditional on payment, say so expressly, together with what testing is permitted before payment. Also specify handover of the repository, documentation and access credentials: contractual rights without a technically usable handover can leave the client dependent on the developer.

Hypothetical example: The developer promises the client exclusive rights to the entire deliverable, while a subcontractor keeps its own library and grants only a limited license. The mismatch should be fixed by obtaining broader rights from the subcontractor or by carving the library out of the exclusivity promised to the client.

Open source and AI tools: know what goes into the deliverable

Open-source components are not in themselves an obstacle to commercial development. What matters is the specific license, how components are linked and distributed, and any notice or source-code disclosure obligations. Keep a register of components and an approval step for licenses that could affect the intended use.

For AI tools, specify which services may be used, how confidential data is handled and how generated code is reviewed. Avoid absolute warranties about the origin and exclusivity of the output without proper checks. If the project involves processing personal data, set out the parties' roles and the required documentation separately (data protection).

Liability caps and contractual penalties

A cap needs a basis, a period and a scope: is it calculated by reference to fees under a specific SOW, all payments, or a set period? Check whether it is aggregate, and whether carve-outs, penalties and third-party claims effectively hollow it out.

Article 265 of the Law on Obligations allows the parties to agree a maximum amount of damages, but only if that amount is not manifestly disproportionate to the loss. Liability for intent and gross negligence cannot be excluded in advance, and a cap on damages does not protect a debtor who caused non-performance intentionally or through gross negligence. A court may also set aside an exclusion of liability for ordinary negligence if it resulted from an unequal bargaining position. A commercially acceptable cap is therefore not automatically valid in every situation.

"Indirect or consequential loss" needs a contractual definition. Serbian law does not measure damages by reference to a direct/indirect distinction. The Law on Obligations distinguishes actual loss (obična šteta) from loss of profit (izmakla korist) and limits recovery to the loss the debtor should have foreseen when the contract was made, except in cases of fraud, intent and gross negligence (Article 266). A clause carried over from an English-law or US template may therefore not work as intended. If you use the term, list the categories of loss you are excluding, such as loss of profit. Deal with loss of data and business interruption separately, because on the facts they may amount to actual loss.

Sample clause · limitation of liability"The Contractor's aggregate liability for all claims arising under the same SOW, on any legal basis under or in connection with this Agreement, including contractual penalties, shall be limited to the fees paid or payable under that SOW in the twelve months preceding the first event giving rise to a claim. The Contractor's aggregate liability under all SOWs combined shall not exceed [amount]. The Contractor shall not be liable for the Client's loss of profit. The limitations in this clause shall not apply in cases of intent or gross negligence, or in any other case where the law does not permit liability to be limited."Illustrative only, for an ongoing relationship under an MSA with several SOWs. For a one-off development project, the cap is usually tied to the total fees under the contract, with no time period. The level of the cap is a commercial question that depends on project value, risk and insurance.

A contractual penalty is not a liability cap. Readers used to common-law contracts should note that Serbian law approaches penalties differently. A contractual penalty can be claimed even if the creditor has suffered no loss, and if the actual loss exceeds the penalty, the creditor may claim the difference (Article 275). A court may reduce a disproportionately high penalty at the debtor's request (Article 274), but you should not count on that in negotiations. A penalty cannot be agreed for monetary obligations (Article 270). If the penalty is to be the only financial consequence of delay, state expressly that it excludes damages beyond the penalty amount and bring it within the aggregate cap. Such a clause does not take away the client's right to demand performance or to terminate, and it does not protect the developer in cases of intent or gross negligence (Article 265).

Sample clause · contractual penalty"The contractual penalty under this clause shall exclude the Client's right to claim damages for late delivery in excess of the penalty amount. The total penalty shall not exceed [10%] of the value of the SOW to which the delay relates and shall count towards the limitation of liability in Clause [X]. This clause is without prejudice to the Client's right to demand performance or to terminate this Agreement in accordance with its terms."Illustrative only. The exclusion of further damages does not apply where the delay was caused intentionally or through gross negligence (Article 265 of the Law on Obligations). The percentage is a matter for negotiation; check how it interacts with SLA service credits.

Link warranties to agreed characteristics and conditions of use. For third-party infringement claims, provide for notice, control of the defense, settlement and remedial measures. Indemnities are a common-law concept with no direct counterpart in Serbian law, so under a Serbian-law contract spell out their scope, procedure and relationship to the liability cap.

Review related obligations together.

For a foreign-law draft or a complex chain of subcontractors, the review should also cover the SOW, rights in components and the carve-outs from the liability cap.

Request a contract review → Contracts and Negotiations

Termination and disputes with foreign clients

Distinguish termination for breach from termination for convenience. Provide for a cure period, payment for work performed, work in progress and transition costs. Where the rules on contracts for work apply, Serbian law allows the client to terminate before the work is completed, but the client must then pay the agreed price, reduced as provided by law, for example by the costs the contractor saved as a result of termination (Article 629). Spell out in the contract how that settlement is calculated.

Define the materials to be handed over, the status of paid and unpaid deliverables, and the length and price of transition assistance. Governing law, jurisdiction and arbitration are separate questions. Foreign governing law may require local counsel, and the cost of proceedings and of enforcing a judgment or award should be proportionate to the deal.

Clauses to check before signing

Pre-signing checklist

• Are the MSA, SOW, proposal and specification consistent, with a clear order of precedence?
• Does every change go through approval of price and timeline?
• Are payment and acceptance tied to provable events and a review period?
• Do payment terms comply with the statutory maximum for Serbian clients?
• Has the tax position for a foreign client been checked before signing?
• Are your pre-existing components carved out of the rights granted to the client?
• Do the rights obtained from employees and contractors cover what you promise the client?
• Are penalties capped and included in the aggregate liability cap?
• Is it clear what is paid for and handed over on termination?

Software development agreements: frequently asked questions

Is a template from the internet good enough?

It can serve as a list of topics to cover. It will not tell you whether scope, rights and liability fit your project and the governing law.

Does an MSA replace a SOW?

No. The MSA sets the framework; the SOW defines the project. If you use a single document, it needs to do both jobs.

Who owns the software if the contract says nothing?

Under Serbian law, the default rule for commissioned software favors the client. It does not automatically extend to the developer's pre-existing components, but without a clear dividing line the risk of a dispute grows. Use the contract to define what the client gets and what stays yours.

Does the client automatically get the source code?

The right to use the code and the obligation to hand it over are separate questions. Specify in the contract what is handed over, in what format and when.

Can acceptance happen without a signed acceptance certificate?

Yes. Under the Serbian rules on contracts for work, the work is deemed accepted if the client, without good reason, fails to respond to an invitation to inspect and accept it. An agreed review period and proof of the invitation reduce the room for dispute.

Does a contractual penalty cap my liability?

Not by itself. If the loss exceeds the penalty, the client may claim the difference unless the contract excludes damages beyond the penalty amount. Even then, the exclusion does not apply in cases of intent or gross negligence.

What is a reasonable liability cap?

There is no standard percentage. It depends on project value, potential consequences, insurance, carve-outs and the governing law.

Does working with a foreign client mean foreign law applies?

Not automatically. Check the choice-of-law clause and the rules that determine the governing law where no choice has been made.

Legal support before you sign an IT contract

A well-structured software development agreement should support the way your team actually works. Stoiljković Law assists with drafting and reviewing IT contracts, aligning MSA and SOW documentation, employee and contractor agreements, and negotiations with domestic and international clients. Learn more: IT law and intellectual property.

What a contract review covers:

• review of the draft and its attachments: MSA, SOW, specification and proposal;
• a list of priority risks from your company's perspective;
• proposed amendments, ready to send to the other side;
• support in negotiations, if needed.

To get started, a short project description and your target signing date are enough. Add your company's role, the other party's country and the approximate contract value if you know them. We will agree on a secure way to share a confidential draft.

Request a review before you sign →