Softwareagentur-Angebot im Check: 12 Klauseln, die Preis, Scope und Eigentum verändern

Um ein Softwareentwicklungsangebot richtig zu prüfen, leg die Hochglanzpräsentation für zehn Minuten beiseite. Lies das Dokument als Landkarte dafür, wer zahlt, wenn eine Annahme bricht, wer entscheidet, ob eine Leistung fertig ist, und wer das Produkt betreiben kann, wenn die Agentur nicht mehr da ist. Erst wenn diese drei Fragen beantwortet sind, ist der Angebotspreis wirklich vergleichbar.

Dieser Beitrag ist eine kommerzielle und technische Prüfhilfe, keine Rechtsberatung. Das Beispiel ist vollständig fiktiv und kombiniert typische Formulierungen aus Softwareangeboten. Lass Haftung, Gewährleistung, IP, Kündigung und Durchsetzbarkeit von qualifizierter Rechtsberatung für das anwendbare Recht prüfen.

Kostenloses 24-Punkte-Prüfraster als PDF herunterladen. Es enthält Scorecard, Hard Stops, Preisvergleich und zwölf Rückfragen. Das PDF ist derzeit auf Englisch; die vollständige Erläuterung findest du hier auf Deutsch.

So prüfst du ein Softwareangebot in vier Durchgängen

1. Kommerzieller Durchgang: Was löst eine Zahlung aus, was ist ausgeschlossen und wodurch kann der Preis steigen?
2. Lieferdurchgang: Welche Artefakte entstehen, wie werden sie abgenommen und was bedeutet „fertig“?
3. Eigentums- und Betriebsdurchgang: Wem gehören Code, Daten, Accounts, Infrastruktur und Lizenzen, und kann dein Team sie übernehmen?
4. Ausnahme-Durchgang: Was passiert bei Verzögerung, Sicherheitsvorfall, Streit, Personalwechsel oder Kündigung?

Markiere in jedem Durchgang unbestimmte Wörter wie „angemessen“, „branchenüblich“, „zeitnah“, „wesentlich“ und „nach Aufwand“. Sie sind nicht automatisch schlecht, aber sie brauchen eine benannte Person, einen Nachweis, einen Zeitpunkt und eine Folge. Sonst entscheidet die stärkere Verhandlungsposition erst dann, wenn bereits Geld und Zeit gebunden sind.

Warum dieser Check nicht mit der Agenturauswahl konkurriert

Unser Leitfaden zur Auswahl einer Softwareagentur beantwortet, welches Unternehmen du beauftragen solltest: Seniorität, Referenzen, Arbeitsweise, Kommunikation und Übergabe. Dieser Beitrag beginnt einen Schritt später. Er beantwortet, wie du das Dokument prüfst, das die ausgewählte Agentur schickt. Erst wählst du den Lieferpartner. Danach prüfst du Scope, Preis und Rechte in seinem Angebot oder Statement of Work.

Das fiktive Angebot: „Northstar Kundenportal“

Das Angebot wirkt präzise: Zahl, Dauer, vier Feature-Gruppen. Trotzdem können die offenen Klauseln den realen Preis um Monate Arbeit, zusätzliche Plattformkosten und einen kompletten späteren Migrationsaufwand verschieben.

Die zwölf Klauseln im Schnellcheck

1. Abnahmekriterien: Was löst Zahlung aus?

Im Angebot steht: „Der Kunde nimmt jeden Meilenstein innerhalb von fünf Werktagen ab. Erfolgt keine Rückmeldung, gilt der Meilenstein als abgenommen.“

Warum das ein Red Flag ist: Die Frist ist klar, der Prüfmaßstab nicht. Ohne Testfälle, Daten, Umgebung, Toleranz und Fehlerklassen kann die Agentur eine Demo als Lieferung betrachten, während der Kunde noch auf ein belastbares Ergebnis wartet. Eine fingierte Abnahme verschärft dieses Problem.

Redline: Verknüpfe jeden Meilenstein mit benannten Akzeptanzszenarien, Testdaten, Zielumgebung, Verantwortlichem und Prüffenster. Definiere blocker-, kritische und geringfügige Fehler, Nachbesserung und Retest. Sag ausdrücklich, welche Zahlung nach erfolgreicher Abnahme fällig wird und was bei berechtigter Ablehnung passiert.

Zwei-Punkte-Test: Eine fremde Person kann anhand der Klausel feststellen, ob der Meilenstein bestanden hat, ohne die Stimmung im Meeting interpretieren zu müssen.

2. IP-Eigentum: Kaufst du das Produkt oder nur Zugriff darauf?

Im Angebot steht: „Alle kundenspezifischen Deliverables gehen nach vollständiger Bezahlung auf den Kunden über. Vorbestehende Werkzeuge und generisches Know-how bleiben Eigentum der Agentur.“

Warum das ein Red Flag ist: Die Grundidee kann funktionieren, aber „Deliverables“, „Werkzeuge“ und „generisch“ sind undefiniert. Unklar bleibt, ob Quellcode, Infrastruktur, Tests, Designs, Prompts, Datenmodelle, Dokumentation und Zwischenstände übertragen werden. Bei Kündigung vor vollständiger Zahlung kann der Kunde trotz bezahlter Meilensteine ohne nutzbares Recht enden.

Redline: Trenne Client Materials, Background IP, Foreground IP und Third-party IP. Liste die übertragenen Artefakte, den Übertragungszeitpunkt, Territorium, Dauer, Bearbeitungs- und Unterlizenzierungsrechte. Für notwendiges Background IP braucht der Kunde eine dauerhafte, ausreichend breite Lizenz. Verlange Zusicherungen zur Rechtekette von Mitarbeitenden und Subunternehmern.

Die European IP Helpdesk unterscheidet genau zwischen Übertragung und Lizenz. Die Wortwahl muss zum gewünschten wirtschaftlichen Ergebnis passen.

3. Change Requests: Wie wird Mehrarbeit genehmigt?

Im Angebot steht: „Änderungen und zusätzliche Anforderungen werden nach Aufwand zum jeweils gültigen Tagessatz verrechnet.“

Warum das ein Red Flag ist: Es gibt keinen Baseline-Scope, kein Formular, keine Auswirkungsanalyse und keinen benannten Genehmiger. Damit kann eine Fehlerbehebung als neue Anforderung erscheinen oder Arbeit beginnen, bevor der Kunde Preis und Zeitfolge kennt.

Redline: Jede Änderung beschreibt Ausgangsscope, neue Leistung, Annahmen, Preis, Zeitplan, Abhängigkeiten und Abnahmekriterien. Nur benannte Personen dürfen schriftlich freigeben, bevor begonnen wird. Fehlerbehebung zur Erfüllung bereits vereinbarter Kriterien ist kein Change Request.

Wie sich Vertragsmodell und Scope-Risiko gegenseitig beeinflussen, zeigt Fixpreis vs T&M: Scope Creep in Zahlen.

4. Gewährleistung: Wer bezahlt die Reparatur?

Im Angebot steht: „Die Agentur behebt kritische Bugs für 30 Tage nach Go-live ohne Zusatzkosten.“

Warum das ein Red Flag ist: „Kritisch“, „Bug“ und „Go-live“ sind nicht definiert. Die Klausel sagt nichts über Reaktionszeit, Abhilfe, Retest oder Fehler aus früheren Meilensteinen. Außerdem kann jede Abweichung als Wartung oder neue Anforderung umetikettiert werden.

Redline: Definiere einen Mangel als Abweichung von Spezifikation, Abnahmekriterium oder vereinbarter Definition of Done. Lege Start und Dauer, Schweregrade, Reaktions- und Behebungsziele, Retest und Eskalation fest. Trenne Mängelbeseitigung klar von Maintenance und Enhancements.

5. Abhängigkeiten: Wer besitzt welches Verzögerungsrisiko?

Im Angebot steht: „Der Zeitplan setzt zeitnahe Mitwirkung des Kunden voraus. Kundenbedingte Verzögerungen verschieben alle Termine entsprechend.“

Warum das ein Red Flag ist: Die Pflicht ist einseitig und unbegrenzt. Jede verspätete Antwort kann theoretisch den gesamten Plan verschieben, auch wenn sie nicht auf dem kritischen Pfad liegt. Die Agentur hat keine entsprechende Pflicht, früh zu warnen oder Folgen zu mindern.

Redline: Erstelle eine Verantwortungsmatrix mit Owner, konkretem Artefakt, Fälligkeitsdatum und blockiertem Meilenstein. Verlange sofortige Verzögerungsanzeige, dokumentierte Auswirkung und angemessene Mitigation. Nur nachweisbare Auswirkungen auf den kritischen Pfad dürfen Termine verschieben.

6. Hosting: Wer besitzt Produktion und die laufende Rechnung?

Im Angebot steht: „Die Lösung wird in der Managed Cloud der Agentur gehostet. Infrastrukturkosten werden monatlich weiterverrechnet.“

Warum das ein Red Flag ist: Region, Services, Budget, Marge, Zugriff, Backups, Monitoring und Exit fehlen. Liegen Cloud, DNS, Domain, App-Store oder Logs im Agentur-Account, kann ein späterer Wechsel zur Neuimplementierung werden.

Redline: Produktion möglichst ab Tag eins im Kundenaccount. Definiere Region, Services, Budgetgrenzen, Billing Owner, Backups, Restore-Test, Monitoring, Admin-Zugriff und Migration. Infrastruktur muss per Code reproduzierbar sein. Falls die Agentur vorübergehend hostet, vereinbare Exportformat, Transferfrist und einen getesteten Migrationspfad.

Preisregel: Addiere zwölf realistische Monate Hosting, Monitoring und Support. „Usage based“ ist nicht null.

7. Drittanbieter-Lizenzen: Welche weiteren Rechte und Kosten hängen am Produkt?

Im Angebot steht: „Zur Beschleunigung dürfen branchenübliche Open-Source- und kommerzielle Komponenten eingesetzt werden.“

Warum das ein Red Flag ist: Open Source ist oft richtig, aber Lizenzen haben Bedingungen und kommerzielle Dienste verlängern sich. Der Kunde muss wissen, ob Distribution, Source Disclosure, Nutzerzahl, Transaktionskosten oder Übertragbarkeit betroffen sind.

Redline: Verlange Komponentenregister oder SBOM mit Version, Quelle, Lizenz und bekannter laufender Gebühr. Restriktive oder schwer ersetzbare Komponenten brauchen Vorabfreigabe. Kommerzielle Rechte müssen direkt beim Kunden liegen oder übertragbar sein. Die ICT-IP-Klauseln der Europäischen Kommission nutzen genau diesen Ansatz.

Hard Stop: Ein Kernservice, der nur auf die Agentur lizenziert ist und keinen realistischen Ersatz hat, ist Lock-in - selbst wenn der Custom Code sauber übergeht.

8. Übergabe: Kann ein kompetentes Ersatzteam nächste Woche deployen?

Im Angebot steht: „Bei Projektabschluss stellt die Agentur Quellcode und angemessene Dokumentation bereit.“

Warum das ein Red Flag ist: Ein Repository-Snapshot ist keine Übergabe. Ohne Historie, CI/CD, Infrastruktur, Zugangsdaten, Datenmodell, Runbooks und bekannte Probleme zahlt das nächste Team für die erneute Entdeckung des Systems.

Redline: Liste kunden-eigenes Repository mit Historie, Build- und Deployment-Pipeline, Infrastructure as Code, Architektur- und Datenflussdiagramme, Migrationen, Tests, Betriebs- und Support-Runbooks, Backup und Restore, Account- und Credential-Inventar, Komponentenregister, bekannte Probleme, Entscheidungen und Trainings. Ein sauberer Deploy oder Restore durch Kunde oder Ersatzteam ist Teil der Übergabe-Abnahme.

Die vollständige Artefaktliste findest du in der Software-Übergabe-Checkliste.

9. Kündigung: Was erhältst du bei einem Stopp in Woche neun?

Im Angebot steht: „Beide Parteien können mit 30 Tagen Frist kündigen. Gezahlte Beträge sind nicht erstattbar, offene Rechnungen werden sofort fällig.“

Warum das ein Red Flag ist: Die Klausel erklärt die Nachricht, nicht den Exit. Work in Progress, Teilmeilensteine, Datenexport, Zugänge, Transition, Löschung, Lizenzen und nicht abgenommene Arbeit fehlen.

Redline: Trenne ordentliche Kündigung, nicht geheilten Vertragsbruch und Insolvenz. Definiere Zahlung für abgenommene Arbeit, Umgang mit Zwischenständen, Artefakt- und Datenpaket, Transferfrist, Credential Rotation, Löschungsnachweis, fortbestehende Lizenzen und gedeckelten Transition-Satz. Benenne fortgeltende IP-, Vertraulichkeits-, Datenschutz-, Gewährleistungs- und Zahlungsklauseln.

Exit-Test: „Wenn wir nach dem nächsten Meilenstein stoppen: Welche Dateien, Accounts, Rechte und Hilfe kommen binnen zehn Werktagen, und was schulden wir?“ Die Antwort sollte in eine Tabelle passen.

10. Security: Welche Controls und Nachweise sind im Scope?

Im Angebot steht: „Die Agentur befolgt branchenübliche Best Practices für Security und Datenschutz.“

Warum das ein Red Flag ist: Es gibt keinen einheitlichen Satz „Best Practices“, kein Verifikationsniveau und keinen Nachweis. Die Formulierung verrät nicht, ob Threat Modelling, Zugriffsprüfungen, Dependency Scans, Secrets Management, Incident Notification oder Penetrationstest im Preis enthalten sind.

Redline: Beginne mit Datenklassifizierung und Verantwortungsmatrix. Benenne Baseline und Version, etwa ein vereinbartes Level oder Subset von OWASP ASVS, und nutze NIST SSDF für Secure-Development-Verantwortung. Definiere Tests, Nachweise, Remediation, Secrets, Verschlüsselung, Logging, Vorfallsfrist und unabhängige Prüfung. Bei personenbezogenen Daten braucht der AVV dokumentierte Weisungen, Vertraulichkeit, technische und organisatorische Maßnahmen, Unterstützung und Subprozessor-Regeln nach Art. 28 DSGVO.

Scope-Warnung: „Pen-test ready“ ist kein Penetrationstest. „DSGVO-konform“ ist keine Liste von Verarbeitungsvorgaben.

11. Subunternehmer: Wer baut tatsächlich und wer sieht die Daten?

Im Angebot steht: „Die Agentur darf bei Bedarf qualifizierte Spezialisten einsetzen und bleibt für die Lieferung verantwortlich.“

Warum das ein Red Flag ist: Der Kunde kennt Rolle, Ort, Datenzugriff und Flow-down-Pflichten nicht. Ebenso unklar ist, ob die Agentur die Rechte am Output des Subunternehmers überhaupt wirksam weitergeben kann.

Redline: Wesentliche Subunternehmer mit Rolle, Standort und System- oder Datenzugriff offenlegen. Für risikorelevante Änderungen Anzeige plus sinnvolles Widerspruchs- oder Zustimmungssystem vorsehen. Vertraulichkeit, Security, Datenschutz, Audit und IP-Übertragung weiterreichen. Die Agentur bleibt verantwortlich. Bei personenbezogenen Daten verlangt Art. 28 DSGVO vorherige spezifische oder allgemeine schriftliche Genehmigung für weitere Auftragsverarbeiter.

Unterscheidung: Ein früh benannter Spezialist für ein konkretes Problem ist ein gutes Zeichen. Eine unsichtbare Bench, die die Seniors aus dem Pitch ersetzt, ist ein Lieferungsrisiko.

12. Definition of Done: Welche Qualitätsarbeit ist vor der Abnahme enthalten?

Im Angebot steht: „Ein Feature ist abgeschlossen, wenn es im Wesentlichen implementiert und dem Kunden demonstriert wurde.“

Warum das ein Red Flag ist: Eine Demo zeigt den Happy Path einmal. Sie beweist nicht, dass Review, Tests, Accessibility, Security, Dokumentation, Deployment, Observability oder Cleanup erledigt sind. Diese Arbeit taucht später als kostenpflichtiges „Hardening“ wieder auf.

Redline: Fertig heißt: Code reviewed und gemerged; vereinbarte automatisierte Tests grün; Abnahmekriterien erfüllt; Security Checks sauber; relevante Accessibility- und Browserchecks erledigt; Doku aktualisiert; in benannte Umgebung deployed; Monitoring und Fehlerbehandlung aktiv; keine Blocker offen. Versioniere die Definition und benenne den Genehmiger für Änderungen.

Der offizielle Scrum Guide bindet die Definition of Done als Qualitätsversprechen an das Increment. Das Prinzip funktioniert auch ohne Scrum: „fertig“ beschreibt den Qualitätszustand, nicht das Gefühl nach einer Demo.

"Der Preis in einem Softwareangebot ist nicht eine Zahl. Er ist die Angebotssumme plus jede Unklarheit, die der Kunde später finanzieren muss. Gute Klauseln machen die Zusammenarbeit nicht feindselig. Sie verhindern, dass normale Unsicherheit unter Zeitdruck zur Verhandlung wird."

Abnahmekriterien, Definition of Done und Übergabe sind drei verschiedene Prüfungen

Alles in „Kundenfreigabe“ zusammenzufassen ist teuer. Ein Feature kann den Business-Test bestehen, obwohl der Code nicht wartbar ist. Sauberer Code kann existieren, obwohl der Kunde nicht deployen kann. Prüfe alle drei Zustände separat.

So vergleichst du den echten Preis zweier Angebote

Vergleichspreis = Build-Preis + ausgeschlossene Pflichtarbeit + laufende Kosten im ersten Jahr + bewerteter Kundenaufwand + erwartete Exit-Arbeit.

Die Zahlen sind erfunden und keine Wavect-Preisbenchmarks. Die Methode ist der Punkt: Ein niedrigeres Angebot wird teurer, wenn Pflichtarbeit außerhalb seiner Grenze liegt. Lass jede Agentur dieselbe Inclusion Matrix ausfüllen.

Score: 0, 1 oder 2 Punkte pro Klausel

• 0 - fehlt. Die Klausel fehlt oder ein referenzierter Anhang wurde nicht geliefert.
• 1 - subjektiv. Die Klausel existiert, verlässt sich aber auf „angemessen“, „standardmäßig“ oder „zeitnah“ ohne Owner, Test oder Folge.
• 2 - operativ. Owner, Artefakt oder Test, Timing, Abhängigkeiten und Folge bei Nichterfüllung sind benannt.

Unabhängig vom Score stoppen, wenn die IP-Kette unklar ist, personenbezogene Daten ohne tragfähige Security- und Processor-Regeln verarbeitet werden, Kernhosting oder Lizenzen nicht übertragbar sind oder eine Kündigung dich ohne Code und Daten zurücklässt.

Was nach dem Teardown passieren sollte

1. Eine konsolidierte Redline schicken, nicht zwölf getrennte E-Mail-Threads.
2. Jede Ausnahme und Annahme mit der Person besprechen, die später Delivery führt.
3. SoW und Anhänge aktualisieren. Meeting-Notizen sind nicht der Vertrag.
4. Feasibility, Abhängigkeiten, Security-Scope und Übergabe technisch prüfen lassen.
5. Rechtssprache von qualifizierter Beratung für Jurisdiktion und Risiko anpassen lassen.

Eine gute Agentur sollte die meisten Fragen begrüßen. Präzise Grenzen schützen ihre Marge genauso wie dein Budget. Widerstand gegen jedes Detail ist das Signal; eine begründete Diskussion über eine konkrete Risikoverteilung ist normale Verhandlung.

Quellen und weiterführende Lektüre

1. UK Cabinet Office (2025), Model Services Contract guidance, Version 2.2. Leitlinien zu Abnahme, Tests, IP, Change Control und Exit Management. gov.uk (abgerufen am 13. Juli 2026).
2. Europäische Kommission (2021), Additional IP clauses for ICT contracts. Quellcode, Objektcode, Dokumentation, Open-Source-Freigabe und Komponentenlisten. commission.europa.eu (abgerufen am 13. Juli 2026).
3. European IP Helpdesk, Frequently asked questions on IP assignment and licences. Übertragungsumfang, Zusicherungen, Freistellung und Unterlizenzierung. intellectual-property-helpdesk.ec.europa.eu (abgerufen am 13. Juli 2026).
4. Europäische Kommission, Can someone else process data on my organisation's behalf? Auftragsverarbeiter, Subprozessoren und Mindestinhalte nach Art. 28 DSGVO. commission.europa.eu (abgerufen am 13. Juli 2026).
5. NIST (2022), Secure Software Development Framework, SP 800-218 v1.1. Gemeinsames Vokabular für Security-Anforderungen und Lieferantenbeschaffung. csrc.nist.gov (abgerufen am 13. Juli 2026).
6. OWASP, Application Security Verification Standard v5.0.0. Testbare Security-Baseline für Beschaffung und Verträge. owasp.org (abgerufen am 13. Juli 2026).
7. OWASP, Secure Software Contract Annex. Verhandlungsfragen zu Security-Anforderungen, Verifikation und Deployment. owasp.org (abgerufen am 13. Juli 2026).
8. WIPO GREEN (2016), Licensing Checklist. Prüfpunkte zu SoW, Deliverables, Spezifikationen, Tests, Abnahme und IP. wipo.int (abgerufen am 13. Juli 2026).
9. Schwaber, K. und Sutherland, J. (2020), The Scrum Guide. Definition of Done als Qualitätsversprechen für das Increment. scrumguides.org (abgerufen am 13. Juli 2026).