Purpose
The creation of custom software is regularly a contract for work and services: what is owed is a result — the functional, agreed software — not mere activity. This skill determines the scope of duties, reviews acceptance and rights for defects, and classifies agile process models (Scrum) legally. The aim is to make remuneration, acceptance and warranty risks visible at an early stage.
Inputs
- Contractual role (client / contractor)
- Process model (classic according to functional specification / agile according to Scrum)
- Requirements specification and functional specification or Product Backlog
- Acceptance and remuneration arrangement (fixed price / time & material / sprints)
- Dispute status (default, defects, refusal of acceptance, termination)
Sub-agent architecture
The processing follows three roles acting in sequence. A Scope-of-services agent reconstructs from the requirements specification, functional specification and backlog the owed quality under § 633 BGB — the most important step, because without a clear target no defect can be established. An Acceptance agent reviews whether, when and in what form acceptance took place, since acceptance under § 640 BGB triggers the limitation period, the burden of proof and the due date for remuneration. A Warranty agent finally classifies the rights for defects under § 634 BGB and assesses the prospects of success. In agile projects, a cross-sectional view supplements this, showing how iterative requirement changes affect the scope of services. Only structured findings are handed over; the contractual documentation remains the basis.
Procedure
1. Contract type and scope of services
The creation of custom software is a contract for work and services under § 631 BGB. The owed quality follows under § 633 BGB primarily from the agreement. The decisive document is the functional specification (the contractor's implementation view) on the basis of the requirements specification (the client's requirements view). If there is no agreement on quality, suitability for ordinary use or the use presupposed by the contract applies.
2. Agile development (Scrum)
Even agile development according to Scrum remains in essence a contract for work and services if a functional result is owed; here the scope of services is specified iteratively via the Product Backlog and sprint acceptances. If, by contrast, only the provision of developer capacity (time & material) is owed, a service contract may exist. The Definition of Done, handling of change requests and partial acceptances per sprint/increment must be regulated.
3. Acceptance (§ 640 BGB)
The Acceptance Under § 640 BGB, physical acceptance combined with approval as substantially in accordance with the contract. It brings about: the remuneration becoming due, the transfer of the burden of proof for defects to the client, the start of the limitation period and the loss of rights due to known defects that were not reserved. A deemed acceptance under § 640(2) BGB can occur if the client, despite a request, does not accept the work within a reasonable period without naming a defect.
4. Rights in respect of defects (§ 634 BGB)
In the event of defects, the client is entitled to the rights under § 634 BGB: subsequent performance (§ 635 BGB), self-remedy, withdrawal or reduction, and damages. Subsequent performance with a deadline is regularly given priority. A contractual shortening of the rights in respect of defects by standard terms is to be measured against §§ 307 et seq. BGB.
Risks
- Acceptance not regulated or effected implicitly — the client unnoticedly loses rights and from then on bears the burden of proof for defects (§ 640 BGB).
- Specifications missing or incomplete — without a clear scope of performance under § 633 BGB, no defect can be established; dispute over "owed or Change Request".
- agile projects without a Definition of Done and a Change Request process — creeping expansion of the scope, fixed price becomes incalculable.
- Scrum as a pretext for unclear remuneration — the distinction between a contract for work and a service contract remains open, liability for success disputed.
- Fixed price without an additional remuneration rule for subsequent requirements — the contractor bears the quantity risk.
Output format
SOFTWAREERSTELLUNG — WERKVERTRAGSPRÜFUNG — <Projekt> — <Datum>
I. Vertragstyp [Werkvertrag § 631 BGB / Dienstvertrag]
Vorgehensmodell: [klassisch / agil — Scrum]
II. Leistungssoll (§ 633 BGB) [Lastenheft + Pflichtenheft vorhanden? ✓/❌]
III. Abnahme (§ 640 BGB) [erfolgt / verweigert / fiktiv]
Folgen (Vergütung, Beweislast): <…>
IV. Mängelrechte (§ 634 BGB) [Nacherfüllung / Rücktritt / Minderung / SE]
Fristsetzung erfolgt: [✓ / ❌]
V. Vergütung / Change Requests [Festpreis / T&M — Mehrvergütung geregelt?]
Empfehlung: <…>