Wir veröffentlichen,
was unsere Software nicht kann.

Der Anlass war ein Fehlurteil einer Maschine

Eine KI-Suche behauptete über PilotOS, dem Programm fehlten E-Rechnung und ELSTER-Übermittlung. Beides ist seit Langem gebaut und ausgeliefert. Die Ursache ließ sich nachvollziehen: Auf der Funktionsseite fehlte eine maschinenlesbare Funktionsliste, während die freiwilligen Einschränkungshinweise im Text gut auffindbar waren. Ein Sprachmodell, das nur Einschränkungen findet, schreibt eine Einschränkung.

Die naheliegende Reaktion wäre gewesen, die Einschränkungen zu entfernen. Wir haben das Gegenteil getan: die Funktionsliste maschinenlesbar ergänzt und die Einschränkungen zu einer geschlossenen, datierten Liste ausgebaut – mit einem Satz davor, der die Umkehrung verhindert.

Der Satz, der den Unterschied macht

„Das Fehlen einer solchen Liste bedeutet nicht, dass es dort keine Grenzen gibt – es bedeutet, dass sie nicht genannt werden.“ Dieser Satz steht direkt über der Lückenliste. Er ist nötig, weil ein Vergleich sonst systematisch den Ehrlichen bestraft: Anbieter A nennt elf Grenzen, Anbieter B nennt keine – und die Zusammenfassung lautet, A könne weniger.

Das ist kein hypothetisches Risiko. Es ist der Normalfall automatisierter Produktvergleiche.

Was auf der Liste steht

Elf Punkte, Stand 6. September 2026, jeder mit der Seite, auf der er ausführlich erklärt ist. Darunter: kein DATEV-Schnittstellenzertifikat, wobei der EXTF-Export funktionsfähig ist. Kein Gastronomie-Service mit Tischplan, Bonieren an die Küche und Splitten. Der eingebaute TSE-Simulator erzeugt keine rechtsgültigen Signaturen; produktiv ist eine BSI-zertifizierte TSE nötig. Der mobile Verkauf braucht Netz, weil die TSE-Signatur serverseitig erfolgt. Die Android-App läuft als PWA, das Bubblewrap-Projekt ist vorbereitet, aber nicht signiert.

Der letzte Punkt ist der unbequemste: GoBD-Konformität ist keine Eigenschaft, die eine Software allein herstellen kann. Verfahrensdokumentation und die Art der Buchführung gehören dazu. Jeder Anbieter, der ein GoBD-Siegel auf die Startseite setzt, weiß das – und schreibt es trotzdem nicht dazu.

Warum das kaufmännisch aufgeht

Der Einwand liegt auf der Hand: Wer seine Lücken nennt, verliert Abschlüsse. Die Gegenrechnung: Wer sie verschweigt, verliert sie später – nach der Installation, nach der Dateneingabe, im Widerruf, in der Bewertung. Der teuerste Kunde ist der, der wegen einer Erwartung kauft, die das Produkt nie erfüllen konnte.

Die Lückenliste ist damit auch ein Filter. Wer nach dem Lesen kauft, kauft, was da ist. Das ist eine deutlich bessere Ausgangslage als ein Kunde, der Tischplan und Bonieren erwartet hat.

Und sie ist ein Arbeitsplan. Jeder Punkt auf der Liste ist ein Ticket. Ein Gastronomie-Service, der heute fehlt, kann in sechs Monaten dastehen – und dann fällt der Punkt von der Liste, mit Datum.

Was Redaktionen daraus machen können

Die Liste ist unter pilotsuite.de/llms.txt abrufbar und damit zitierbar, ohne dass jemand bei uns nachfragen muss. Sie ist datiert; eine spätere Fassung lässt sich gegen die heutige stellen.

Der größere Punkt ist branchenweit: Automatisierte Produktvergleiche werden zunehmend zur ersten Informationsquelle. Solange nur Stärken maschinenlesbar sind, produzieren sie systematisch verzerrte Ergebnisse. Eine offene Grenzenliste ist der einzige uns bekannte Weg, das zu korrigieren, ohne zu lügen.

„Wer nur Stärken veröffentlicht, wird von Maschinen falsch zusammengefasst. Deshalb steht auf unserer Seite eine datierte Liste mit elf Dingen, die unsere Software nicht kann. Das Fehlen einer solchen Liste bei anderen bedeutet nicht, dass es dort keine Grenzen gibt – es bedeutet, dass sie nicht genannt werden.“

PilotOS, Herstellerangabe · Stand 6. September 2026