Abnahmeprotokoll Software: Vorlage und Ablauf der Abnahme

Die Unterschrift unter einem Abnahmeprotokoll dauert zehn Sekunden. Sie verändert die rechtliche Lage des Projekts mehr als jeder andere Moment. Mit der Abnahme wird die Vergütung fällig, die Beweislast für Mängel wechselt in der Regel zum Auftraggeber, und für bekannte Mängel, die nicht im Protokoll stehen, können Rechte verloren gehen.

Trotzdem wird die Abnahme in vielen Projekten nebenbei erledigt, oft per E-Mail mit dem Satz „Sieht gut aus“. Das ist für beide Seiten riskant.

Was § 640 BGB regelt

Ein Softwareprojekt mit geschuldetem Ergebnis ist meist ein Werkvertrag, und dann gilt § 640 BGB. Drei Absätze, drei Kernregeln:

1. Der Besteller muss das vertragsgemäß hergestellte Werk abnehmen. Wegen unwesentlicher Mängel darf er die Abnahme nicht verweigern.
2. Setzt der Unternehmer nach Fertigstellung eine angemessene Frist und der Besteller verweigert die Abnahme nicht unter Angabe mindestens eines Mangels, gilt das Werk als abgenommen. Bei Verbrauchern nur mit Hinweis in Textform.
3. Wer ein mangelhaftes Werk abnimmt, obwohl er den Mangel kennt, behält bestimmte Mängelrechte nur, wenn er sie sich bei der Abnahme vorbehält.

Absatz 3 ist die Falle. Wer einen bekannten Fehler sieht, die Software trotzdem abnimmt und den Fehler nicht ins Protokoll schreibt, kann seine Ansprüche auf Nacherfüllung, Selbstvornahme und Rücktritt oder Minderung verlieren.

Was sich mit der Abnahme ändert

Bei der Verjährung gibt es eine Besonderheit. Nach § 634a BGB verjähren Mängelansprüche in zwei Jahren ab Abnahme, wenn der Erfolg des Werks in der Herstellung oder Veränderung einer Sache besteht, Wartung eingeschlossen (Abs. 1 Nr. 1). Im Übrigen gilt die regelmäßige Verjährungsfrist (Abs. 1 Nr. 3), die nicht mit der Abnahme beginnt. Welche Variante für Software greift, ist umstritten. Sinnvoll ist deshalb, die Gewährleistungsfrist im Vertrag ausdrücklich zu regeln.

Ablauf einer Softwareabnahme

Der erste Schritt entscheidet über alle anderen. Wenn die Kriterien erst bei der Abnahme diskutiert werden, wird die Abnahme zur Verhandlung. Wer seine Anforderungen als User Stories mit Akzeptanzkriterien oder in einem sauber gegliederten Lastenheft formuliert hat, hat die Testfälle schon in der Hand.

Achte auch auf die Frist. Setzt der Auftragnehmer eine angemessene Frist zur Abnahme, musst du innerhalb dieser Frist reagieren. Sonst greift die fiktive Abnahme, auch wenn noch niemand richtig getestet hat. Plane also Testkapazität ein, bevor die Fertigmeldung kommt.

Mängelklassen: nicht jeder Fehler ist gleich

Bewährt hat sich eine Einteilung in drei Klassen. Sie macht aus einer langen Fehlerliste eine Entscheidungsgrundlage.

Verweigern lässt sich die Abnahme nur bei wesentlichen Mängeln, also typischerweise bei Klasse 1. Eine Häufung von Klasse-2-Mängeln kann in Summe ebenfalls wesentlich sein. Das sollte im Protokoll begründet werden.

Vorlage: Abnahmeprotokoll für Software

Diese Felder gehören in jedes Protokoll. Übernimm die Tabelle in dein Dokument.

Für das Feld „Vorbehalte“ eignet sich eine schlichte Formulierung: „Der Auftraggeber behält sich hinsichtlich der unter Nr. 1 bis 4 aufgeführten Mängel sämtliche Rechte vor.“ Das ist nicht elegant. Es ist eindeutig.

Bei hohen Projektvolumen lohnt es sich, Vorlage und Vertrag einmal von einer Anwältin für IT-Recht prüfen zu lassen.

Vier Fehler, die bei Abnahmen immer wieder passieren

• Abnahme durch Nutzung: Die Software läuft seit Wochen produktiv, ein Protokoll gibt es nicht. Gerichte können darin eine stillschweigende Abnahme sehen, und dann fehlen die Vorbehalte.
• Getestet wird mit drei Beispieldatensätzen. Fehler, die erst bei 50.000 Kunden oder bei Umlauten in Namen auftreten, bleiben unentdeckt.
• Neue Wünsche werden als Mängel deklariert. Was nie vereinbart war, ist kein Mangel, sondern eine Änderung. Dafür gibt es den Change Request, nicht das Abnahmeprotokoll.
• Die Dokumentation wird vergessen. Ohne Zugangsdaten, Betriebshandbuch und Quellcode ist eine abgenommene Software schwer weiterzuentwickeln.

Der dritte Punkt sorgt für die meisten Konflikte. Er lässt sich nur vermeiden, wenn der vereinbarte Umfang schriftlich und prüfbar vorliegt.

Teilabnahmen bei agilen Projekten

Eine einzige große Abnahme am Ende eines Jahresprojekts ist riskant. Besser sind Teilabnahmen pro Release oder Meilenstein, wenn der Vertrag das vorsieht. Jede Teilabnahme ist überschaubar, Fehler fallen früher auf, und der Auftragnehmer bekommt Teilzahlungen, was seine Planung entlastet. Wie man ein Projekt in solche Etappen schneidet, beschreibt der Vergleich Agil vs. Wasserfall.

Bei Teilabnahmen sollte klar sein, ob am Ende zusätzlich eine Gesamtabnahme stattfindet, etwa für das Zusammenspiel aller Module. Steht das nicht im Vertrag, gibt es später Streit.

Wer ein Projekt mit einem externen Studio plant, sollte Abnahmekriterien und Ablauf schon beim Angebot ansprechen. Bei einem Partner wie OnlineBuilders gehört das zur technischen Erstberatung, und es spart am Projektende Zeit und Nerven.

Nächster Schritt: Prüf deinen aktuellen Vertrag auf drei Punkte. Sind Abnahmekriterien definiert, ist eine Frist für den Abnahmetest geregelt, und steht dort, wer abnehmen darf? Fehlt einer davon, ergänze ihn, bevor die Fertigmeldung kommt.