Abnahme im Softwareprojekt: wann ein Modul als geliefert gilt

Mit der Billigung des Werks wechseln Vergütungsanspruch, Risiko und Beweislast die Seite. § 640 BGB macht daraus einen Termin, den ein Softwareprojekt vorbereiten muss.

Aktualisiert am

Die Abnahme ist die Erklärung des Auftraggebers, dass ein Werk vertragsgemäß erbracht ist; § 640 BGB macht sie zur Pflicht, sobald keine wesentlichen Mängel mehr vorliegen. In einem Web- oder Softwareprojekt betrifft sie ein konkretes Modul, ein Release oder eine Anbindung — nicht das Projekt als Gefühl.

Vier Rechtsfolgen der Abnahme nach § 640 BGB

Den allgemeinen Rahmen dieser Vertragsform beschreibt der Artikel Werkvertrag; hier geht es um den einen Termin, an dem sich die Lage beider Seiten ändert. Mit der Billigung des Werks verschieben sich vier Positionen gleichzeitig.

  • Fälligkeit der Vergütung. Erst danach darf abgerechnet werden (§ 641 BGB). Eine Rechnung ohne diesen Schritt ist nicht durchsetzbar, auch wenn die Arbeit sichtbar fertig ist.
  • Gefahrübergang. Ab jetzt trägt der Besteller das Risiko für den Bestand des Werks (§ 644 BGB) — bei einer Anwendung heißt das: für ihren Betrieb in seiner Umgebung.
  • Umkehr der Beweislast. Vorher belegt der Unternehmer, dass er mangelfrei geliefert hat; danach muss der Besteller den Mangel darlegen und beweisen.
  • Beginn der Verjährung. Erst mit diesem Datum laufen die Fristen für Mängelansprüche (§ 634a BGB) — ein Termin ohne Beleg ist deshalb für beide Seiten teuer.

Diese Kopplung erklärt, warum in Softwareprojekten selten über Technik gestritten wird und fast immer über einen Zeitpunkt. Wer den Termin nicht vorbereitet, verhandelt ihn — und verhandelt dabei gleichzeitig über Geld, Risiko und Fristen.

Ausdrücklich, konkludent, fiktiv: Formen der Abnahme

Das Gesetz kennt mehrere Wege. Ausdrücklich erklärt der Besteller, dass er das Werk als vertragsgemäß billigt — schriftlich, per E-Mail, im Protokoll. Konkludent geschieht dasselbe durch Verhalten: Wer eine Anwendung produktiv schaltet, darüber Bestellungen entgegennimmt und die Rechnung ohne Vorbehalt zahlt, hat erklärt, was er nie ausgesprochen hat.

Der dritte Weg steht in § 640 Absatz 2 BGB. Setzt der Unternehmer eine angemessene Frist und verweigert der Besteller die Billigung darin nicht unter Angabe mindestens eines Mangels, gilt das Werk als abgenommen — die fiktive Abnahme. Sie ist kein Trick, sondern die gesetzliche Antwort auf Projekte, die nach dem Livegang niemand mehr formell beendet. Für Auftraggeber folgt daraus eine schlichte Pflicht: auf eine solche Frist antworten, und zwar mit einem benannten Mangel statt mit Schweigen.

Prüfbare Kriterien statt „läuft stabil“

Ein Kriterium taugt, wenn zwei Bedingungen erfüllt sind: Es ist beobachtbar, und es steht fest, bevor jemand mit der Umsetzung beginnt. Beobachtbar heißt, dass ein Dritter ohne Projektwissen zum selben Ergebnis kommt. Im Web- und Softwareprojekt sieht das so aus:

  • Ein benannter Satz Testfälle läuft vollständig durch; die Liste liegt beiden Seiten vor der Prüfung vor.
  • Die Oberfläche ist auf den im Lastenheft und Pflichtenheft genannten Browsern und Endgeräten bedienbar.
  • Ein Import verarbeitet einen festgelegten Bestand vollständig: Zahl der Datensätze und Summen je Konto stimmen mit dem Quellsystem überein.
  • Rollen und Rechte verhalten sich wie beschrieben — eine Rolle sieht genau die Bereiche, die ihr zugeordnet sind, und keinen weiteren.
  • Jede Schnittstelle liefert für definierte Eingaben die vereinbarte Antwort, auch im Fehlerfall und bei fehlenden Pflichtfeldern.

Unbrauchbar sind Formeln, deren Maßstab erst nach der Lieferung entsteht: „läuft stabil“, „das Design gefällt“, „performant“, „benutzerfreundlich“. Sie verlagern die Entscheidung auf den, der zahlt, und machen aus einem Rechtsakt eine Geschmacksfrage. Wie aus fachlichen Anforderungen eine belastbare Leistungsbeschreibung entsteht, gehört deshalb in dieselbe Vorbereitung.

Release für Release: Etappen einzeln prüfen

Ein großes Werk am Stück zu billigen ist die teuerste Variante: Der Besteller sieht das Ergebnis spät, der Unternehmer arbeitet lange ohne Fälligkeit. § 641 Absatz 1 Satz 2 BGB lässt für abgrenzbare Teile eine gesonderte Vergütung zu, wenn die Parteien das vereinbart haben. In der Praxis heißt das: Jede Etappe hat einen eigenen Liefergegenstand — ein Datenmodell samt Migrationsskript, ein Modul mit Oberfläche, eine Anbindung an ein Fremdsystem — und eigene Kriterien.

Zwei Dinge gehören dann geregelt. Erstens: Was eine Etappe abschließt, ist erledigt und wird am Ende nicht noch einmal aufgemacht. Zweitens: Für den Rest bleibt es beim gemeinsamen Schlusstermin. Ohne diese Trennung entsteht der häufigste Streit im Projekt — der Besteller hält gelieferte Teile für vorläufig, der Unternehmer für bezahlt.

Das Protokoll: was beim Übergang festgehalten wird

Ein Abnahmeprotokoll ist kein Formular, sondern der Beweis für ein Datum. Hinein gehören der Tag, der genau bezeichnete geprüfte Stand mit Version oder Commit, die Liste der Kriterien mit Ergebnis, die offenen Punkte mit Einordnung als wesentlich oder unwesentlich sowie die Namen derer, die geprüft haben.

Der wichtigste Satz darin ist der Vorbehalt. Wer ein Werk billigt, obwohl er einen Mangel kennt, und sich seine Rechte nicht vorbehält, verliert einen Teil davon (§ 640 Absatz 3 BGB). Genau deshalb ist die Liste der offenen Punkte kein Zeichen von Misstrauen, sondern der Grund, warum beide Seiten das Papier später noch gebrauchen können. Welche Rechte danach bleiben, behandelt der Artikel Mängelhaftung.

Wie wir Kriterien im Angebot festhalten

Wir schreiben die Kriterien in das Angebot, bevor die Arbeit beginnt, und schneiden Vorhaben in Etappen mit je einem eigenen Liefergegenstand. Geprüft wird gegen die Liste, nicht gegen den Eindruck; Code, Dokumentation und Zugänge stehen dem Auftraggeber vom ersten Tag an offen, fachliche Weisungen an unsere Entwickler laufen über unsere Projektleitung. Wie ein solches Vorhaben aufgebaut ist, zeigt die Leistung Softwareentwicklung.

Passende Leistungen

Verwandte Begriffe

Sagen Sie uns, was am Ende da sein soll

Sie schildern die Aufgabe, wir sagen offen, ob sie zu uns passt. Passt sie nicht, nennen wir Ihnen den Grund.

Projekt besprechen