Auf dem Tisch liegen zwei Stapel kleiner Papierscheine. Auf jedem steht ein Code aus elf Zeichen, daneben ein QR-Code. Jeder einzelne Schein muss auf einer Webseite eingetragen werden, damit er meinem Sportverein gutgeschrieben wird.
Es sind 504 Scheine. Ein Eingabefeld. Und eine Frist am Sonntag.
Ich habe die Arbeit automatisiert: fotografieren, lokal erkennen, im Browser eintragen. Am Freitag und am Samstagvormittag waren alle 504 Scheine zugeordnet.
Die eigentliche Überraschung lag woanders: Der klassische QR-Decoder hat jeden Code richtig gelesen. Das KI-Modell, das ihn kontrollieren sollte, lag bei gut 9 von 100 Codes daneben.
Die Aufgabe: 504 Codes, ein Feld nach dem anderen
Bei der Aktion „Scheine für Vereine“ gibt es beim Einkauf Vereinsscheine. Jeder Schein wird einem Verein zugeordnet, und ab bestimmten Mengen kann der Verein Prämien wählen.
Mein Verein hatte Sammelboxen in zwei Märkten aufgestellt, Kunden warfen ihre Scheine nach dem Einkauf dort ein. Die Boxen kamen mit der Post, verschickt im Auftrag des Veranstalters für genau diesen Zweck.
Für die Zuordnung gibt es genau einen Weg: Code eintippen oder per Handykamera scannen, einen nach dem anderen. Einen Upload für viele Codes oder eine Schnittstelle habe ich nicht gefunden. Natürlich hätte ich jeden Schein auch einzeln mit dem Handy scannen können: draufhalten, zweimal bestätigen, Rückmeldung abwarten. 504 Mal.
Vor dem Start stand der Vereinszähler bei 59. Zwei Prämien, die der Verein gern hätte, gibt es ab 310 und ab 480 Scheinen.
Gestoppt habe ich die Handeingabe nicht. Hochgerechnet wären es drei bis vier Stunden gewesen.
Drei Schritte, klare Rollen
Die Arbeit zerfällt in drei Schritte, und in jedem ist klar geregelt, wer was tut. Fotografieren war meine Aufgabe. Die Erkennung lief vollständig lokal, ohne Cloud-Dienst. Die Eingabe auf der Webseite übernahm ein Skript, das Claude Code geschrieben hat. Eingetragen wurde erst nach meiner Freigabe.
| Schritt | Wer | Was |
|---|---|---|
| Fotografieren | ich | Scheine geschuppt auf einer Schneidematte, nur die QR-Felder sichtbar, bis zu 15 Scheine je Foto, Übertragung per USB-Kabel |
| Erkennen | lokal auf eigener Hardware | QR-Decoder liest den Code, ein KI-Modell liest den Aufdruck zur Kontrolle |
| Übertragen | Skript im Browser | trägt Code für Code ein und prüft am Vereinszähler, ob er angekommen ist |
| Entscheiden | ich | alle Freigaben vor dem Absenden, Entscheidung nach jedem Abbruch |
Ein Einzugsscanner wäre bequemer gewesen. Ich habe es versucht, aber die Scheine sind zu klein und verdrehen sich im Einzug. Sie auf A4-Bögen zu kleben, hätte mehr Zeit gekostet als das Fotografieren.
Am Ende waren es 38 Fotos mit 510 gelesenen QR-Codes. Sechs Lesungen davon waren Dubletten aus Testfotos. Übrig blieben 504 verschiedene Codes.
Der Weichzeichner-Trick
Der erste Versuch mit dem QR-Decoder war ernüchternd. Auf manchen Fotos erkannte er keinen einzigen Code.
Der Grund liegt im Druck. Die Module der QR-Codes sind als einzelne Punkte gedruckt, nicht als geschlossene Flächen. Für den Decoder sieht das aus wie Rauschen.
Die Lösung ist fast banal: Das Foto in Graustufen umwandeln und leicht weichzeichnen. Die Punkte verschwimmen zu Flächen, und der Decoder findet die Codes.
Ein zweiter Trick half bei der Auflösung: Ich habe die Kamera auf das Seitenverhältnis 4:3 umgestellt. Damit war jeder QR-Code im Bild rund 35 Prozent breiter. Außerdem passte so eine Reihe Scheine mehr aufs Foto.
| Ergebnis | Anzahl |
|---|---|
| direkt gelesen | 189 |
| erst nach dem Weichzeichnen gelesen | 315 |
| nicht gelesen | 0 |
Ohne den Weichzeichner hätte der Decoder also gut 60 Prozent der Codes im ersten Durchgang nicht gelesen. Mit ihm dauerte die Erkennung rund eine Sekunde je Foto. Der vorherige Ansatz, das Bild in Kacheln zu zerlegen und zu vergrößern, brauchte rund 14 Sekunden.
Als Werkzeug diente die freie Bibliothek zxing-cpp. Ein Filter ließ nur QR-Codes durch, die auf die Aktionsseite verweisen. Den Strichcode auf der Schneidematte hat die Erkennung so zuverlässig ignoriert.
KI als Gegenprobe, nicht als Quelle
Parallel zum Decoder lief ein KI-Modell, das Bilder lesen kann. Es lief lokal über Ollama, auf einem eigenen KI-Rechner im Netzwerk, ohne dass ein Foto das Haus verließ. Seine Aufgabe: den aufgedruckten Code lesen und mit dem QR-Ergebnis vergleichen.
Die Regel stand von Anfang an fest: Kein Code stammt aus dem Bildmodell. Es darf nur widersprechen.
Im ersten Versuch bekam das Modell das ganze Foto. Das Ergebnis: Von 24 Codes las es keinen einzigen exakt richtig. Selbst beim Zählen lag es auf dichten Fotos daneben, fünf statt acht Scheine, zehn statt zwölf.
Im zweiten Versuch bekam es nur einen Ausschnitt je Schein, in voller Auflösung und gerade gedreht. Die Lage des QR-Codes zeigte, wo der Aufdruck steht. Jetzt las das Modell 458 von 504 Codes exakt, das sind 90,9 Prozent. Pro Code brauchte es zwei bis drei Sekunden.
Das klingt nach viel. Für eine Liste, die ohne Nacharbeit stimmen soll, sind 46 falsche Codes aber 46 Fehler zu viel. Ein Blick auf die Fehler zeigt, warum das Modell danebenlag. Es sind die klassischen Verwechslungen ähnlich aussehender Zeichen.
Bei 12 der 46 falschen Codes lag nur die Groß- und Kleinschreibung falsch. Das eingefügte G stammt vermutlich aus dem Präfix „G-“, das vor jedem Code steht und das Modell mitgelesen hat.
Fair ist allerdings: Diese Zeichen sind auch für Menschen nicht eindeutig. Wer die Codes selbst abliest, stolpert über dieselben Stellen. Ich habe mich bei einem Test selbst vertippt.
Für meine Aufgabe hieß das: Der QR-Decoder ist die Quelle. Die KI ist eine zweite Meinung, die man sich anhört, wenn sie widerspricht.
Langsam mit Absicht
Die ersten drei Codes hat Claude in Chrome eingetragen, jeden einzeln von mir freigegeben. Danach übernahm ein Skript mit dem Werkzeug Playwright. Es lief in einem gewöhnlichen Chrome-Browser mit eigenem Profil, ohne zusätzliche Kennungen.
Das Skript hatte ein einfaches Erfolgskriterium: Der Vereinszähler auf der Seite steigt um eins. Stieg er nicht, musste im Statusbereich „bereits zugeordnet“ stehen. Bei jeder anderen Meldung hielt es an.
Eine Eingabe dauerte im Mittel 3,9 Sekunden. Für alle Scheine sind das rund 33 Minuten reine Eingabezeit.
Zwischen den Codes lagen trotzdem Pausen von 6 bis 10 Sekunden, später bis 20 Sekunden. Im weiteren Verlauf kam nach je zehn Minuten eine Blockpause von drei bis fünf Minuten dazu. Mit Pausen lief die Übertragung rund 2 Stunden 27 Minuten in vier Läufen, einer davon am Samstag. Das lief dann ohne mein Zutun und ich konnte mich derweil einem anderen Thema zuwenden.
Der Zähler stieg von 59 auf 565. Die Schwelle von 310 Scheinen war am Freitag um 13:36 Uhr erreicht, die von 480 um 15:05 Uhr. Kein Code wurde doppelt gesendet. Dass der Zähler etwas stärker stieg als meine 504 Scheine, liegt vermutlich an Eingaben anderer Unterstützer in derselben Zeit.
Wo die Grenzen liegen
Eine Regel galt für die ganze Arbeit: Es wird kein Schutzmechanismus umgangen, kein CAPTCHA gelöst, nichts getarnt. Bei Verdacht hält das Skript an.
Dreimal hat es genau das getan. Auf der Seite erkannte es ein eingebettetes Prüffenster von Cloudflare Turnstile, einem Dienst, der automatisierte Zugriffe erkennen soll. Das Skript stoppte jeweils sofort. In allen drei Fällen war der letzte Code trotzdem angekommen.
Später zeigte sich: Das Prüffenster ist schon beim bloßen Laden der Seite vorhanden. Vermutlich handelt es sich um eine unsichtbare Prüfung im Hintergrund, nicht um einen ausgelösten Test. Belegen kann ich das nicht.
An einer Stelle kam der Wunsch auf, Tipp-, Maus- und Pausenmuster zu variieren, damit das Skript menschenähnlicher wirkt. Claude Code hat das abgelehnt. Der Zweck wäre gewesen, eine Erkennung zu umgehen.
Stattdessen lief das Skript langsamer und mit Blockpausen, um die Seite weniger zu belasten. Das ist keine Tarnung, sondern offen automatisiert, nur rücksichtsvoller getaktet. Ob Turnstile dadurch seltener anschlug, weiß ich nicht. Den Rest übertrug es am nächsten Tag in einer Viertelstunde, ohne Abbruch.
Ehrlich gesagt: Da noch Zeit bis zur Frist war, hat mich das nicht gestresst. Alles in einem Rutsch abzuschließen, wäre mir aber deutlich lieber gewesen. Und die Ablehnung? Mir ging es um eine schnelle Übertragung, ohne selbst Hand anlegen zu müssen.
Ich lese die Teilnahmebedingungen so, dass eine langsame, offen automatisierte Eingabe im normalen Browser kein „unerlaubtes Hilfsmittel“ im Sinne der Ziffer 4.13 ist, auch wenn die Bedingungen den Begriff nicht definieren.
Was schiefging
Nicht alles lief glatt. Die meisten Pannen hatten mit dem Drumherum zu tun, nicht mit der Erkennung.
| Panne | Lehre |
|---|---|
| Die Arbeit lief zuerst im Browser des falschen Rechners | Bei mehreren verbundenen Browsern das Gerät prüfen |
| Zeiten im Protokoll waren geschätzt statt gemessen | Zeiten nur aus Systemuhr und Zeitstempeln |
| Ein zu grobes Suchmuster meldete ein CAPTCHA, wo keines war | Erst den Erfolg prüfen, dann den Verdacht; Muster eng fassen |
| Zwei Erfassungen liefen versehentlich parallel und erzeugten doppelte Einträge in der Codeliste | Sperrdatei gegen Parallelläufe; gesendet wurde trotzdem kein Code doppelt |
| Eine Liste wurde beim Umschreiben abgeschnitten, weil im Meldungstext ein Trennzeichen stand | Vor jeder Korrektur sichern, keine Trennzeichen in Freitext |
Am meisten Nerven hat mich etwas ganz anderes gekostet: das Übertragen der Fotos vom Handy. Deshalb bin ich von 6 auf 15 Scheine je Foto hochgegangen.
Dazu kamen die Unterbrechungen bei der Übertragung. Und dass es überhaupt ein Browser-Werkzeug brauchte, wo eine Upload-Seite oder eine Schnittstelle gereicht hätte. Ich möchte nicht wissen, wie viele andere Vereine vor der gleichen Situation standen.
Der Prüfschritt für Ihre nächste Erfassung
Mein Schluss aus diesem Projekt: KI ist nicht immer das beste Werkzeug zum Lesen von Daten. Wenn ein Verfahren existiert, das eindeutig dekodiert statt schätzt, schlägt es in solchen Fällen jedes Modell.
Wenn in Ihrem Verein oder Ihrem Betrieb eine Erfassung per KI vorgeschlagen wird, stellen Sie zwei Fragen:
- Gibt es für diese Daten einen Weg, der nicht schätzt? Ein QR-Code, ein Barcode, ein Export, eine Schnittstelle.
- Wer prüft das Ergebnis, und woran merkt er einen Fehler? In meinem Fall war es der Vereinszähler, der bei jedem Code um eins steigen musste.
Lautet die Antwort auf die erste Frage ja, gehört die KI in die zweite Reihe: als Gegenprobe, die sich meldet, wenn etwas nicht passt.
Fazit
Im Verein war damit niemand beschäftigt außer mir, mit dem Aufbau und dem Anstoßen der Läufe. Vielen Dank an alle, die ihre Scheine in die Boxen geworfen haben. Die erreichte Menge hat beide Prämienschwellen überschritten, der Verein hat sich für eine der Prämien entschieden.
„Durch die automatische Verarbeitung war niemand mit einer stupiden Aufgabe belastet, und die Zeit ließ sich sinnvoller nutzen.“
| Kennzahl | Wert |
|---|---|
| Scheine | 504 aus zwei Märkten |
| Fotos | 38, bis zu 15 Scheine je Foto |
| QR-Decoder | 504 von 504 richtig, 315 davon erst nach Weichzeichner |
| KI-Modell, Ausschnitt je Schein | 458 von 504 richtig (90,9 Prozent) |
| KI-Modell, ganzes Foto | 0 von 24 richtig |
| Eingabe | 3,9 Sekunden je Code, rund 2 Stunden 27 Minuten mit Pausen |
| Vereinszähler | von 59 auf 565, beide Prämienschwellen erreicht |
| Doppelt gesendet | 0 |
| Abbrüche | 3, jeweils durch Regel, Code trotzdem angekommen |
Wenn Sie in Ihrem Verein oder Unternehmen eine ähnliche Fleißarbeit haben und wissen wollen, ob sie sich automatisieren lässt: Schreiben Sie mir. Wir schauen gemeinsam, wo der Mensch in der Schleife bleiben muss.
Quellen
- zxing-cpp, QR- und Barcode-Bibliothek: https://github.com/zxing-cpp/zxing-cpp
- Playwright, Browser-Automatisierung: https://playwright.dev/
- Ollama, lokale Ausführung von KI-Modellen: https://ollama.com/
- Cloudflare Turnstile: https://developers.cloudflare.com/turnstile/
- Teilnahmebedingungen „Scheine für Vereine“ 2026 (abgerufen 26.10.2026)
