Contract for work vs. service contract in software, AI and games projects

Anyone who develops software, trains AI models or manages a games project with milestones and publisher acceptances needs a clean contract architecture. The formal difference between “contract for work vs. service contract” is not an academic detail, but in practice determines acceptance, defect rights, change requests, scope of liability and remuneration logic. The legal core can be reduced to a brief formula: The service contract owes an activity (Section 611 BGB), the contract for work owes a result (Section 631 BGB). This difference runs through the entire project life cycle – from the service description and acceptance to the question of whether rectification, reduction or compensation can be demanded. At the same time, the distinction from employment (Section 611a BGB) always resonates, as incorrectly designed freelancer set-ups harbor the risk of bogus self-employment. This article classifies the dogmatics, translates them into resilient clause mechanics and uses examples from software, AI and games projects to show how to draft a legally compliant and economically viable contract.

Performance debt vs. activity

The service contract requires the provision of a service, not the achievement of a specific result. Typical examples in the digital sector are operating and support contracts, SRE readiness, content moderation, SOC services, penetration testing “as a service” and ongoing admin activities on cloud stacks. As a rule, remuneration is provided on a time or service level basis, and disruptions to performance are governed by the rules of general rights to disrupt performance; there are no rights in respect of defects within the meaning of Sections 634 et seq. BGB do not exist because the service does not owe any success that can be accepted.

On the other hand, there is the contract for work and services. It requires the production of a specific “work” – i.e. a result that is ready for acceptance. In software practice, this could be the implementation of a defined feature set in accordance with specifications, the delivery of an app version with defined user stories, the achievement of specification maturity (“feature complete”) or the provision of measurable integration services with a certain system depth. In the games sector, vertical slice, alpha, beta, gold master and day-one patch are typical partial successes that can be accepted. Acceptance is central (§ 640 BGB): Only upon acceptance does remuneration become due, warranty periods begin to run and the burden of proof shifts. The fiction of acceptance applies if acceptance has been refused without significant defects or if deadlines expire unused; this mechanism should be properly incorporated in the contract so that projects do not fail due to blockade tactics.

The practical error often lies in “work contract language” with a de facto service contract setup. Anyone who promises a “success package” for “operation and further development”, for example, without defining measurable success, creates friction: clients expect defects to be rectified, contractors point to mere activity obligations. A two-pronged architecture provides a remedy: sprints or milestones on the development track under a contract for work and services and SLA services for operation, maintenance and incident management. In this way, the legal nature remains clear, the remuneration consistent and the escalation in the event of an incident calculable.

Service description, acceptance and warranty rights

In the work contract regime, the service description is the centerpiece. A good specification not only describes “what” (functional scope, interfaces, data models, performance targets), but also “how” in the sense that quality criteria and acceptance tests are defined. In AI projects, it is not enough to agree on “model training”; data sources, training and validation metrics, budget and compute limits as well as target corridors for accuracy, ROC-AUC, F-score or specific error tolerances are required. As AI expenditure is probabilistic, it must be legally clarified what counts as “success”: for example, the achievement of a validated target band on an approved test set, not perfection in individual cases. This is where it is decided whether acceptance and maturity are viable.

Acceptance is preferably carried out in two stages. First, the formal pre-acceptance per partial service (e.g. per sprint increment) based on the agreed acceptance criteria, followed by the overall acceptance of the release. Partial acceptances are not an end in themselves, but an instrument of proof and a liquidity anchor. Those who expressly provide for partial acceptances shift the warranty cycles forward, smooth out cash flows and reduce the risk of an “all-or-nothing” blockade at the end. Warranty rights then follow the work contract logic: subsequent performance (Section 635 BGB), self-remedy (Section 637 BGB), reduction (Section 638 BGB), compensation and withdrawal under the general conditions (Sections 280, 281, 323 BGB). The trick lies in the clear separation from change requests: what is a deviation from the specifications remains a defect; what is a new requirement is a compensable change. This line should not be hidden in the body text, but should be secured by clear definitions and an independent amendment mechanism.

A second lever is cooperation. Without data access, a test environment, credentials, sample content or product owner availability, success cannot be achieved. § Section 642 BGB gives the contractor a claim for compensation if the customer fails to cooperate as required. Integrating this standard into the clause mechanics prevents projects from unilaterally “running to zero” even though the client lacks internal approvals. Delayed acceptance must also be addressed: If acceptance does not take place despite the ability to accept, remuneration must be able to fall due; fictitious acceptance and default rules ensure predictability here.

Agile models, change requests and hybrid contracts:

Agile is not a separate type of contract, but a methodology. From a legal perspective, agility can be structured as a sequence of clearly defined, acceptable sub-works. Sprint backlogs with concrete “Definition of Done” can be summarized in work logic, provided that the user stories are sufficiently defined. Alternatively, an agile project can be structured as a service contract with a “best-efforts” character if successes that can be accepted are deliberately dispensed with – a setup that often makes sense for research and pre-development (prototyping, tech spike, data preparation). The unreflected mixture is problematic: “time & material” without acceptance and at the same time rights for defects under the law on work and services do not go together.

Change requests are the nerve center of complex projects. Without a robust change request mechanism, there is a risk of economic distortions. A proper procedure begins with a written notification of change, describes the effects on scope, costs and deadlines, provides for evaluation deadlines on both sides and regulates an interim phase in which either the old specification continues to apply or implementation begins provisionally. It is important to ensure accountability: if the contractor has to act on demand without budget approvals, the project becomes a loss-making trap. “No Work Without Order” and an escalation-capable approval process are therefore not formalism, but risk management.

A milestone architecture is ideal for games co-development, where each milestone has its own mini-obligation, acceptance criteria, review deadlines and a milestone approval. Vertical slice, combat loop prototype, content drop, beta freeze, submission build and day one patch are all partial successes that can be accepted. On the service contract side, bug fix SLAs, live ops support and balancing support run in parallel and are remunerated according to tickets, priorities and response times. This turns “agile” into a clear legal framework that helps both sides: clients receive reliable deliverables and contractors a fair basis for remuneration.

Remuneration, caps and risk allocation

Remuneration for work without acceptance is a contradiction. Remuneration in the contract for work and services regime should therefore be linked to milestones. The number, amount and due date follow the economic logic of the project: early payments secure cash flow, later payments link liquidity to actual performance. In AI setups, it has proven to be a good idea to structure preliminary projects with a smaller volume as “Discovery & Data Readiness”, which reduces the risk of expensive misconceptions and prepares a robust main project. If the data situation is unclear, a “Research & Feasibility” block under a service contract makes sense, which is open-ended and deliberately does not provide for acceptance.

Price changes due to changes are not only permissible, but mandatory if the scope of services, data quality or security requirements increase. An index of effort and deadline effects creates transparency: every change is categorized into effort points that have an impact on budget planning. Price escalation clauses for significant third-party costs – compute, hosting, licenses, DOOH slots – are advisable as long as they are backed up with verifiable evidence. Caps reduce the overall risk; they fit into both worlds, but must be carefully adjusted. In works law, caps primarily address secondary compensation, while core performance and supplementary performance cannot be capped by their very nature. In service SLAs, caps are a central element of the risk price; higher cap, higher price – the correlation is as simple as that.

Bonus-malus mechanisms work if they are linked to measurable, controllable parameters. A games port with clear performance targets on target hardware can be linked to frame time, crash rate and compliance pass rate. An AI support bot in customer service, on the other hand, should not be measured by “overall customer satisfaction”, but by first-contact resolution within defined domains and hallucination rates on narrowly defined knowledge bases. The legal classification is important: if it remains with activity obligations (service contract), bonus/malus are performance incentives; if a concrete success is relevant to remuneration, one approaches work contract logic and should consistently consider acceptance and defect rights.

Liability, IP rights and compliance: what really counts in the event of a dispute

Liability follows the nature of the contract. In the contract for work and services, a defect leads to subsequent performance, then to a reduction in price or compensation. The contractor is liable for the failure to achieve the success owed, unless deficiencies in cooperation or impossible specifications break the causality. In service relationships, liability is assumed for careful performance, not for success. An SRE standby service that complies with SLA response times is not liable for the fact that an overload not caused by it never occurs. Both worlds have limitations of liability; gross negligence and intent are typically excluded, as are injuries to life, limb and health.

The rights chain in software and content production is particularly tricky. If there is no clear transfer of rights or if the service provider has involved subcontractors who have not granted sufficient rights, there is a risk of blocking and injunctive relief. In a contract for work and services, a comprehensive, project-specific grant of simple or exclusive rights of use is part of the core remuneration. In dynamic environments – such as toolchains with open source libraries – license compliance must also be included. In the worst case, copyleft components can influence the licensing of the entire work. Making the open source policy part of the contract reduces this risk. In AI projects, there is also the issue of training data: sources, licenses, protection of privacy and confidentiality, as well as responsibility for generated output. Purely synthetic outputs can be low-copyright; this does not change the fact that they can be unlawful if they copy protected templates too closely or infringe personal rights. The warranty and indemnification clauses must reflect this reality.

Finally, the boundary to employment. § Section 611a BGB defines the employment relationship. Where the density of instructions, integration into the organization, unilateral working time requirements and job commitment dominate, there is a risk of bogus self-employment. Long-term “service retainers” with full integration into the product team are particularly vulnerable. Contracts should therefore emphasize the entrepreneurial nature of freelance work: own equipment, independent work organization, responsibility for results, substitution options, calculated project risks. In work setups, the success-based nature also speaks against employment. Nevertheless, it is the actual practice that is decisive, not the paper.

Typical scenarios from practice – and how to classify them successfully

A medium-sized company commissions the development of a connector that links an ERP system with a PIM. The parties define data fields, sync rhythms, conflict logic, error tolerances and latency budgets in a specification sheet. This is where the contract for work and services comes into play: The connector is ready for acceptance, the measure of success is that it functions in accordance with the specification. At the same time, the company concludes a service contract for “Operations & Monitoring”, in which logs are monitored, faults are classified and SLA response times are agreed. If a bug occurs, it must be checked whether it is a defect in an accepted work component or an operational incident. The former category triggers subsequent performance; the latter is processed as an incident in accordance with the SLA.

An AI provider fine-tunes a large-language model on the knowledge base of a support portal. The project is divided into data preparation, training and evaluation phase, prompt design and integration. As long as the parties only agree on a “best-efforts” improvement without defining an objectifiable target range, a service contract is the obvious choice. If, on the other hand, they agree a validated quality band on a test set, plus integration KPIs and inference cost budgets, the result is a work ready for acceptance. Experience has shown that a separation is recommended: a short, service contract-based feasibility block that tests the data reality, followed by a main project under a service contract with clear acceptance parameters.

In a games project, an external co-dev partner is to polish the Combat system and take over platform ports. Performance budgets, memory limits, load times and compliance pass rates can be defined for the porting; the service contract is ideal. For live ops tasks after launch – balancing, hotfixes, event operation – a service contract with incident and change rules makes sense. The common mistake is the undifferentiated term “development contract” with a mixture of all components. The dual model is legally clearer and economically fairer: a clear work contract section with milestones and acceptances, alongside a service SLA for live operation.

Contract modules that work in practice – without enumerated aesthetics

A convincing contract begins with definitions that not only organize terms, but also draw the boundaries: “Defect” is any deviation from the approved specifications, not just any taste preference. “Change” is any new requirement outside the scope, regardless of how “small” it appears. A clear description of roles and involvement addresses who is the product owner, who issues release approvals, who organizes access to third-party systems and the deadlines for providing feedback on drafts. Deadline logic and escalation prevent states of limbo: if feedback is not provided, a stage is considered provisionally released; if the declaration of acceptance is not provided without good reason, the acceptance fiction takes effect. Such rules are more than just formalities – they protect project schedules and budgets.

On the legal consequences side, warranty and liability only apply if they are linked to the nature of the contract. A blanket “reduction in the event of a breach of SLA” is permissible in a service contract, but does not replace the warranty rights under works law. Conversely, “bug fixes within 48 hours” are often unrealistic in works law without SLA logic; a categorization according to error classes, linked to appropriate response and rectification periods, is reasonable. Remuneration must follow these realities: Milestone payments with clear acceptance events in the works part; monthly or quarterly flat rates with ticket caps in the services part. Adjustment clauses for third-party costs, budget reserves for known risks and transparently documented changes ensure economic stability. Caps and exemptions prevent outliers without undermining the core of the service.

Editing rights deserve particular attention in AI and games projects. The right to adapt, translate, compile, integrate and port delivered code, assets or models into new environments is not a “nice to have”, but a basis for use. At the same time, moral rights protect against distorting adaptations. The contractual balance is: extensive editing rights for factually necessary transformations, flanked by protection against distorting changes. In teams with several service providers, it must also be clarified that editing rights also apply to each other so that integration remains possible.

Stumbling blocks and elegant ways around them

A common stumbling block is “acceptance avoidance” due to endless feedback loops. A cascade of defined feedback windows, the fiction of intermediate approval and an escalation path that leads to a final decision can help. A second stumbling block is “change creep”: small, seemingly harmless requests that cumulatively derail the project. Countermeasures include disciplined backlog maintenance, transparent burn-down metrics and the contractual obligation to confirm the impact in terms of time and money before implementation. Thirdly, there is the threat of a rights vacuum in distributed setups. Anyone who involves subcontractors without a clear chain of rights or ignores open source compliance risks blocking or relicensing. Mandatory SBOM (Software Bill of Materials) documentation and a lean approval process for licenses keep the situation manageable.

Finally, the danger of false expectations lurks in the border area of service/works contract. Clients expect “troubleshooting included”, although only time & material is agreed for activities; contractors calculate tightly, although acceptance logic and defect rectification are legally stipulated. Transparency in the first few pages of the contract – “These services are covered by the contract for work”, “those covered by the contract for services” – reduces misunderstandings. Those who also address termination rights at an early stage avoid hard breaks. In the law on work and services, the customer has a free right of termination (Section 648 BGB); the remuneration up to that point and the savings must be offset. In service contracts, ordinary termination by notice applies, which is more economically manageable if minimum terms and termination windows are chosen wisely.

Classification for the search intention: the “difference between a contract for work and services” at a glance

The difference we are looking for can be summarized as follows: A “managed hosting & support” contract is a service contract; operating services, response times and diligence are owed. An “implementation of a payment module according to specification X with certification Y” is a contract for work; the functional implementation including acceptance is owed. “Prompt engineering coaching” or “AI strategy sparring” is a service contract; the quality is measured by the consulting service, not by a fixed KPI success. “Fine-tuning a model to target metric Z on test set T” is a contract for work; the focus is on measurable target success. A “port to platform P with performance budgets” is a contract for work; “post-launch balancing support” is typically a service contract. It is precisely this interpretation that answers the search intention: the comparison is not made using buzzwords, but using what can be objectively tested and accepted.

Conclusion with a gentle call to action

The distinction between “contract for work and services vs. contract for services” is crucial to the success of the project because it structures the due date, acceptance, defect rights, liability and remuneration. In software, AI and games projects, a deliberate hybrid architecture is recommended: deliverables under a contract for work and services that can be accepted where the specification and acceptance criteria are clearly defined; SLAs under a contract for services where the focus is on operation, research, coaching or reactive services. Those who consistently follow the lines in definitions, participation, change procedures, remuneration logic, IP rights and liability avoid the usual frictional losses and retain economic and legal control.

Let us advise you!

Author: Marian Härtel

Marian Härtel ist Rechtsanwalt und Fachanwalt für IT-Recht mit einer über 25-jährigen Erfahrung als Unternehmer und Berater in den Bereichen Games, E-Sport, Blockchain, SaaS und Künstliche Intelligenz. Seine Beratungsschwerpunkte umfassen neben dem IT-Recht insbesondere das Urheberrecht, Medienrecht sowie Wettbewerbsrecht. Er betreut schwerpunktmäßig Start-ups, Agenturen und Influencer, die er in strategischen Fragen, komplexen Vertragsangelegenheiten sowie bei Investitionsprojekten begleitet. Dabei zeichnet sich seine Beratung durch einen interdisziplinären Ansatz aus, der juristische Expertise und langjährige unternehmerische Erfahrung miteinander verbindet. Ziel seiner Tätigkeit ist stets, Mandanten praxisorientierte Lösungen anzubieten und rechtlich fundierte Unterstützung bei der Umsetzung innovativer Geschäftsmodelle zu gewährleisten.