Contract for work (Werkvertrag) or service contract (Dien­stver­trag) in software development?

Contract for work vs. service contract in software development: the core difference

The difference can be reduced to one question: is a result owed, or an activity? Under a contract for work, the contractor promises to produce a specific piece of software, app or interface that meets the agreed requirements. Under a service contract, they promise to work competently and diligently – whether the desired result is achieved at the end is not the subject of the contract.

The label in the contract alone does not decide. Courts look at what was actually agreed and put into practice: if there is a concrete specification and an acceptance, that points strongly to a contract for work. If developer hours are called off for changing tasks, it points more to a service contract. The creation of custom software is often classified as a contract for work – but the individual case is always what counts.

Acceptance, defects and payment under a contract for work

Acceptance is the central moment of a contract for work. With it, the client recognizes the work as essentially conforming to the contract. From then on, payment generally becomes due, the burden of proof for defects shifts to the client, and the limitation period for defect claims begins. If the client fails to refuse acceptance, citing at least one defect, within a reasonable period, the work may be deemed accepted (§ 640 (2) BGB).

For software projects, it is therefore advisable to define acceptance criteria in advance: which functions are tested, with what data, in what environment? Partial acceptances after milestones and a clear distinction between defects and new requests also make sense. The client's duties to cooperate include, for example, delivering content, access and decisions on time. The more clearly these points are stated in the contract, the smoother acceptance goes.

Agile projects, maintenance and repairs: contract for work or service contract?

Agile methods such as Scrum don't fit seamlessly into the classic contract-for-work model, because the scope is deliberately left open at the start. In practice, there are several approaches: a service contract with clear roles and sprint goals, contracts for work per release or milestone, or a framework agreement with individual orders. What matters is that the contract and the way you actually work together match.

With maintenance contracts, it depends on the individual services. Hotline, consulting and standby are typically services, whereas fixing a specific fault has the character of a contract for work. Software maintenance contracts are therefore often classified as mixed contracts. A repair in which a specific defect is to be fixed is generally governed by contract-for-work law, because the result is what matters.

Contract for work vs. fixed price – and the “freier Dien­stver­trag”

Contract type and remuneration model are two different things. A contract for work can be billed at a fixed price or by time and materials; a service contract is usually paid by the hour or day but can also provide for a monthly flat fee. A fixed price therefore does not automatically turn a service contract into a contract for work. If no remuneration has been agreed, the customary remuneration applies to a contract for work under § 632 BGB.

The term “freier Dienstvertrag” (freelance service contract) comes from Austrian law, where it describes an activity without personal dependence and with its own social security rules. In German law, the closest equivalent is the service contract with a self-employed freelancer. Whether someone is actually self-employed depends on the circumstances, in particular on being bound by instructions and being integrated into the organization. This overview does not replace legal advice.