Das Leistungsverzeichnis entscheidet, ob Sie vergleichbare Angebote erhalten, ob Ihr Verfahren angefochten werden kann und ob das IT-Projekt später so läuft wie geplant. Dieser Guide zeigt, was rechtssichere IT-Leistungsverzeichnisse enthalten müssen, welche Formulierungen das Verfahren gefährden und wie Sie typische Fehler von Anfang an vermeiden.
Zuletzt aktualisiert: Mai 2026 · ca. 12 Min. Lesezeit
Das Leistungsverzeichnis ist das zentrale Dokument jeder IT-Ausschreibung. Es ist gleichzeitig die rechtlich bindende Grundlage des späteren Vertrags, die Basis für alle Angebote der Bieter und der Maßstab für die spätere Leistungsabnahme. Was im LV fehlt, undeutlich formuliert oder rechtlich angreifbar ist, wirkt sich in jeder dieser drei Dimensionen aus.
Erfahrungsgemäß entstehen die meisten Probleme in IT-Projekten der öffentlichen Hand nicht während der Umsetzung, sondern davor: bei einem Leistungsverzeichnis, das zu vage formuliert, zu produktorientiert aufgebaut oder in entscheidenden Punkten lückenhaft ist. Das LV ist die Investition, die am meisten lohnt.
Leistungsbeschreibung und Leistungsverzeichnis sind nicht dasselbe: Die Leistungsbeschreibung (LB) ist das übergeordnete Dokument, das den Auftragsgegenstand festlegt (§ 31 VgV). Das Leistungsverzeichnis (LV) ist eine positionsbasierte Form der Leistungsbeschreibung mit Mengen, Einheiten und Einzelpositionen. Das LV ist also eine konkrete Ausprägung der LB, nicht deren Bestandteil. Für IT-Ausschreibungen sollte ein vollständiges LV folgende Kernpositionen umfassen:
Einzelne, klar abgrenzbare Leistungseinheiten mit Bezeichnung, Menge und Einheit. Jede Position muss so beschrieben sein, dass Bieter sie eindeutig kalkulieren können.
Anzahl Nutzer, Standorte, Geräte, Transaktionen, Lizenzen. Ohne Mengengerüst können Bieter keine realistische Preiskalkulation erstellen — und kalkulieren dann auf Risiko.
Kompatibilitätsanforderungen zur bestehenden IT-Infrastruktur, Betriebssysteme, Datenbankversionen, Browserkompatibilität, Barrierefreiheit (BITV 2.0).
Welche bestehenden Systeme muss die neue Lösung anbinden? Format, Protokoll, Übergabepunkt und Verantwortlichkeit je Schnittstelle klar benennen.
Verfügbarkeitsanforderungen, Reaktionszeiten, Wartungsfenster, Support-Zeiten. Je präziser hier formuliert wird, desto klarer sind Vertragsgrundlage und Abnahmekriterien.
Wann gilt die Leistung als erbracht? Welche Tests und Abnahmekriterien gelten? Ein fehlender Abnahmerahmen ist die häufigste Ursache für späteren Nachtragsstreit.
Das Mengengerüst ist der am häufigsten vernachlässigte Bestandteil von Leistungsverzeichnissen. Bieter, die nicht wissen, wie viele Nutzer, Standorte oder welches Datenmigrations-Volumen gemeint ist, kalkulieren entweder zu hoch (Sicherheitspuffer) oder zu niedrig (Nachträge). Beides schadet dem Auftraggeber. Lieber ungenaue Schätzwerte angeben als gar keine.
§ 31 Abs. 6 VgV verbietet Verweise auf bestimmte Marken, Hersteller, Produkte oder Verfahren, wenn dadurch bestimmte Anbieter bevorzugt oder ausgeschlossen werden. Produktneutralität ist kein formales Gebot, sondern ein wettbewerbsrechtlicher Grundsatz: Jeder Marktteilnehmer soll eine faire Chance haben, ein passendes Angebot abzugeben.
Eine Produktnennung ist ausnahmsweise zulässig, wenn der Auftragsgegenstand nicht mit hinreichender Genauigkeit und Verständlichkeit beschrieben werden kann. Dann muss der Zusatz "oder gleichwertig" zwingend ergänzt und die Ausnahme im Vergabevermerk begründet werden.
Achtung: Vergabekammern prüfen nicht nur den Wortlaut, sondern den Effekt. Ein formal neutral formuliertes LV ist unzulässig, wenn die Kombination der Anforderungen faktisch nur ein Produkt ermöglicht. Die Beweislast liegt beim Auftraggeber.
Für IT-Ausschreibungen empfiehlt sich in der Praxis der Wechsel von produktorientierten Formulierungen hin zu offenen Standards und Protokollen. Wer statt "SAP-Schnittstelle" eine "RFC- oder REST-basierte Anbindung an ein ERP-System" ausschreibt, öffnet den Wettbewerb ohne Qualitätsverlust.
Die folgenden Fehler finden sich erfahrungsgemäß in einem Großteil der Leistungsverzeichnissen öffentlicher Auftraggeber. Keiner davon entsteht aus Böswilligkeit, sondern fast immer aus Zeit- oder Ressourcenmangel und fehlender IT-Beschaffungserfahrung.
Formulierungen wie "moderne IT-Lösung", "aktueller Sicherheitsstandard" oder "intuitive Bedienbarkeit" sind nicht prüfbar. Bieter interpretieren sie unterschiedlich, Angebote werden unvergleichbar, die Wertung ist angreifbar.
Besser: Konkrete, messbare Anforderungen nennen: "Reaktionszeit unter 2 Sekunden bei 500 gleichzeitigen Nutzern", "ISO 27001-zertifizierter Betrieb".
Kein Hinweis auf Nutzerzahl, Standorte, Datenmenge oder Transaktionsvolumen. Bieter können nicht realistisch kalkulieren. Ergebnis: Entweder Risikoaufschläge oder spätere Nachträge, wenn der tatsächliche Umfang abweicht.
Besser: Auch Schätzwerte helfen. "Ca. 150 Nutzer an 3 Standorten, ca. 50.000 Datensätze zur Migration" ermöglicht eine Kalkulation, auf die der Auftraggeber später zurückgreifen kann.
IT-Systeme funktionieren selten isoliert. Wenn unklar bleibt, welche Drittsysteme angebunden werden müssen, wer für die Schnittstelle verantwortlich ist und welches Format erwartet wird, entstehen nach Zuschlag sofort Nachfragen und Nachträge.
Besser: Für jede Schnittstelle: System, Format/Protokoll, Richtung (eingehend/ausgehend), Frequenz und Verantwortung (AN, AG oder Drittanbieter) angeben.
Wenn das LV nicht definiert, wann die Leistung als vertragsgemäß erbracht gilt, hat der Auftraggeber im Abnahmestreit keine starke Position. Abnahmen können verzögert, verweigert oder vom AN erzwungen werden.
Besser: Abnahmetest-Prozedur, Testszenarien und Abnahmekriterien bereits im LV festlegen. "Abnahme gilt als erteilt, wenn alle definierten Testszenarien ohne kritische Fehler bestanden sind."
LVs aus früheren Vergaben werden ohne Anpassung übernommen. Veraltete technische Anforderungen, falsche Mengenangaben und nicht mehr gültige Normenreferenzen gefährden das neue Verfahren und verzerren den Wettbewerb.
Besser: Vorhandene LVs als Strukturvorlage nutzen, aber jeden inhaltlichen Abschnitt auf Aktualität prüfen. Normen, Schwellenwerte und Technologiereferenzen immer neu recherchieren.
Das LV nennt keinen Hersteller, aber die Kombination aus Anforderungen — bestimmte proprietäre Dateiformate, ein konkretes Lizenzmodell, eine herstellerspezifische API — schließt faktisch alle außer einem Anbieter aus.
Besser: Anforderungen auf Interoperabilität und offene Standards prüfen. Wenn ein bestimmter Anbieter zwingend erforderlich ist: Ausnahme dokumentieren, "oder gleichwertig" ergänzen und Vergabevermerk pflegen.
Das Leistungsverzeichnis ist eine positionsbasierte, konstruktive Form der Leistungsbeschreibung. Für viele IT-Beschaffungen ist das genau richtig: Hardware, Lizenzen, Wartungsverträge lassen sich gut in Positionen mit Mengen und Einheiten abbilden. Für komplexe Projekte mit offenem Lösungsraum — individuelle Softwareentwicklung, Digitalisierungsvorhaben, Cloud-Migrationen — kann stattdessen eine funktionale Leistungsbeschreibung geeigneter sein.
Beschreibt die Leistung in Einzelpositionen mit Menge, Einheit und konkreten technischen Anforderungen. Der Auftraggeber gibt vor, was zu liefern ist. Bieter kalkulieren Einheitspreise.
Beschreibt Ziel und Leistungsparameter, nicht den Weg. Der Bieter entwickelt das Lösungskonzept. Zulässig nach § 31 Abs. 2 VgV. Typisch bei Vorhaben mit offenem technischen Lösungsraum.
Viele erfolgreiche IT-Vergaben kombinieren beide Ansätze: Mindestanforderungen, Schnittstellen und SLA im LV konstruktiv und messbar festschreiben — die technische Umsetzung und das Lösungsdesign dem Bieter überlassen. Pflichtanforderungen (Must) klar von optionalen Anforderungen (Should/Nice-to-have) trennen und im LV kennzeichnen.
| Anforderungstyp | Beschreibungsform | Beispiel IT |
|---|---|---|
| Pflicht (Must) | Konstruktiv + messbar | "System muss LDAP/Active Directory-Anbindung unterstützen" |
| Optional (Should) | Funktional beschrieben | "Mobile Nutzbarkeit über browserbasierte Oberfläche" |
| Lösungsdesign | Dem Bieter überlassen | Datenbankarchitektur, Skalierungsstrategie, Deployment-Modell |
| Schnittstellen | Konstruktiv (Standard angeben) | "REST-API-Anbindung an SAP IS-U, Datenaustausch im JSON-Format" |
Ein IT-Leistungsverzeichnis von Grund auf neu zu erstellen kostet Zeit und setzt Fachwissen voraus, das in Vergabestellen nicht immer vorhanden ist. Zwei Quellen helfen, schneller zu einem qualitativ hochwertigen LV zu kommen:
Professionell aufgebaute LV-Vorlagen für konkrete IT-Beschaffungen: strukturiert nach Must/Should/Nice-to-have, mit Mengengerüst-Platzhaltern, produktneutral formuliert und auf aktuelle Normen geprüft. Für Tablets, EDR/XDR, Cloud-Dienste und weitere IT-Kategorien verfügbar.
Muster-LVs ansehen →Wie haben vergleichbare Behörden und Kommunen ähnliche IT-Beschaffungen ausgeschrieben? Das Vergabe-Archiv enthält reale Vergabeunterlagen öffentlicher Auftraggeber. Formulierungen, Strukturen und Anforderungsprofile aus der Praxis als Orientierung für das eigene LV.
Vergabe-Archiv entdecken →Vorlagen und Archiv-Dokumente sind Ausgangspunkt, kein Ersatz für die inhaltliche Auseinandersetzung mit dem eigenen Bedarf. Jede Vorlage muss auf die konkrete Beschaffung angepasst werden: Mengengerüst, Schnittstellen und Abnahmekriterien sind immer projektspezifisch. Ein ungeprüft übernommenes LV ist einer der häufigsten Fehler — auch wenn die Vorlage selbst gut ist.
Wir unterstützen öffentliche Auftraggeber bei der Erstellung rechtssicherer, produktneutraler IT-Leistungsverzeichnisse: von der Anforderungserhebung über die Strukturierung bis zur Abnahmedokumentation.
Quellen