Oliver GundlachAm Anfang stand die Frage, wie gut verschiedene Sprachmodelle Payroll-Fälle beurteilen können. Einen Fall in ein Chatfenster kopieren war mir zu wenig, also habe ich eine kleine Messstation gebaut: 24 fiktive Abrechnungsfälle, vier Modelle, jeder Fall jeweils fünfmal geprüft. Herausgekommen sind 480 Antworten für knapp neun Euro Token-Kosten. Getestet wurden OpenAIs GPT-5.6 Sol, Anthropics Claude Opus 4.6, Mistral Medium 3.5 und Alibabas Qwen3 235B.
Vorab: Das ist kein Benchmark und hat keinen Anspruch auf Allgemeingültigkeit, das war nicht mein Ziel. Ich wollte an einer konkreten Prüfaufgabe sehen, was verschiedene Modelle tatsächlich abliefern.
Wie der Test aufgebaut war
Die 24 Fälle sind frei erfunden, aber bewusst realistisch aufgebaut: Stammdaten, Vergütung, Ereignisse im Monat, darunter die fertige Abrechnung mit nummerierten Positionen. Zwölf Fälle sind korrekt, zwölf enthalten genau einen eingebauten Fehler, von offensichtlich bis tricky. Entworfen habe ich die Fälle mit Claude Fable, Anthropics stärkstem Modell. Im Testfeld läuft es bewusst nicht mit, weil es die Auflösungen kennt. Danach hat meine Frau Nadine die Fälle als Payroll-Fachfrau durchgesehen, zwei davon ganz verworfen und mehrere nachgeschärft. Bei den beiden verworfenen war der eingebaute Fehler in der Praxis gar nicht möglich.
Die Aufgabe war eng gefasst: genau EINE Positionsnummer für den Fehler nennen oder KEINE, dazu höchstens zwei Sätze Begründung. Lohnsteuer, Solidaritätszuschlag und die Netto-Summe galten laut Auftrag als korrekt aus dem Abrechnungsprogramm übernommen, zu prüfen waren die Ansätze und Regeln dahinter. Bewertet habe ich nur die Zahl, gegen einen vorher festgelegten Antwortschlüssel. Die Begründungen sind gespeichert, gingen aber nie in die Bewertung ein: Kein Modell hat hier ein anderes beurteilt.
An den Modellen selbst habe ich nichts justiert, gleicher Prüfauftrag für alle, sonst Anbieter-Standard. Einzige Ausnahme: Claude Opus lief mit mittlerer Denkstufe. Mit hoher habe ich es zuerst versucht, bekam die Messung so aber nicht durch: Das Modell arbeitete an einzelnen Fällen über fünf Minuten und lief wiederholt in Grenzen des Anbieters.
Ein Fall zum Mitprüfen
Die beiden Kästen zeigen einen der zwölf Fehlerfälle vollständig, genau so, wie die Modelle ihn bekommen haben: erst der Prüfauftrag, dann die Falldaten. Gesucht ist die Nummer der Zeile, in der der Fehler steckt - die Abrechnungspositionen sind dafür mit [1], [2], [3] durchnummeriert. Ein Hinweis für die Suche: Lohnsteuer und Netto rechnet in der Praxis das Programm, diese Beträge galten im Auftrag als korrekt errechnet, auch wenn sie auf einem falschen Brutto aufbauen. Gesucht war also kein Rechenfehler, sondern eine Position, die so nicht hätte angesetzt werden dürfen. Zwei Hinweise zum Fall selbst: Die 167 Stunden enthalten die bezahlten Feiertage des Monats, und die Lohnsteuer ist ein gesetzter Wert, nicht aus der Tabelle - sie war ausdrücklich nicht Teil der Prüfaufgabe.
Du prüfst als Payroll-Prüfer den folgenden Abrechnungsfall (Deutschland, Rechtsstand 2026). Die Positionen der Abrechnung sind mit [1], [2], ... nummeriert. Maschinell gerechnete Beträge (Lohnsteuer, Solidaritätszuschlag, Netto-Summenbildung) gelten als korrekt aus dem Abrechnungsprogramm übernommen - zu prüfen sind Ansätze und Regeln: Was wurde abgerechnet, und hätte es so abgerechnet werden dürfen? Der Fall enthält höchstens EINEN Fehler. Antworte auf Deutsch, ohne Vorrede, ausschließlich in diesem Format - genau eine ANTWORT-Zeile mit genau einer Positionsnummer oder dem Wort KEINE, danach kein Nachtrag: ANTWORT: (Nummer der fehlerhaften Position oder KEINE) BEGRÜNDUNG: (höchstens 2 Sätze)
STAMMDATEN Mitarbeiterin: Petra Wolkow, Personal-Nr. 10078 Geburtsdatum: 28.01.1985 Eintritt: 15.06.2019, unbefristet Tätigkeit: Maschinenbedienerin, Vollzeit Steuerklasse: I, Kinderfreibetrag 1,0 (ein Kind, geb. 2014) Kirchensteuer: keine (konfessionslos) Krankenversicherung: gesetzlich, Zusatzbeitrag 2,5 % Pflegeversicherung: ein Kind unter 25 Personengruppe: 101, Beitragsgruppe 1111 VERGÜTUNG (laufend) Stundenlohn: 16,50 € / Std. Ist-Stunden Mai: 167,0 Std. (laut Zeiterfassung) EREIGNISSE IM MAI Keine Fehlzeiten, keine Einmalzahlung. ABRECHNUNG MAI 2026 [1] Lohn 167,0 Std. × 16,50 €: 2.575,50 € [2] Steuer-Brutto: 2.575,50 € [3] SV-Brutto: 2.575,50 € [4] Lohnsteuer (Klasse I): 230,00 € [5] KV-Beitrag AN (7,3 % + 1,25 %): 220,21 € [6] RV-Beitrag AN (9,3 %): 239,52 € [7] AV-Beitrag AN (1,3 %): 33,48 € [8] PV-Beitrag AN (1,8 %): 46,36 € [9] Netto / Auszahlungsbetrag: 1.805,93 €
Der Fall ist einer der einfachsten im Set: kein Sonderfall, keine Grenzwerte, nur eine Multiplikation. Trotzdem hat ihn eines der vier Modelle in allen fünf Durchläufen übersehen, und zwar das Modell, das die korrekten Fälle am verlässlichsten freigegeben hat. Deshalb lohnt der Blick auf jedes Modell einzeln.
Was die vier Modelle geliefert haben
GPT-5.6 in der Variante Sol, dem Spitzenmodell der Reihe, gelaufen über unser Azure-Konto in der Region Schweden, hat 59 der 60 eingebauten Fehler gefunden und 56 der 60 korrekten Abrechnungen freigegeben. Interessanter als die Quote sind die vier Beanstandungen, die keine waren: kein erfundener Paragraf, keine falsch zitierte Rechengröße, sondern fachliche Einwände. Dreimal zeigte das Modell auf die Lohnsteuer in einem Fall mit Austritt zum 15. Juni und verlangte für den angebrochenen Monat die Tages- statt der Monatstabelle. Diesen Bereich hatten wir im Prüfauftrag ausgenommen, in unserer Zählung ist es also ein Fehlalarm. Fachlich hat das Modell aber recht: Endet das Arbeitsverhältnis mitten im Monat, ist der Lohnzahlungszeitraum nur der Teilmonat, und dann gilt die Tagestabelle. Für die Messung ändert das nichts: Der Fall trug keinen eingebauten Fehler, richtig war die Antwort KEINE, und die Regel galt für alle vier Modelle gleich. Drei der vier Beanstandungen dieses Modells sind solche Fälle. Dazu war es das stabilste im Feld: Nur in drei von 24 Fällen wechselte die Antwort zwischen den fünf Durchläufen.
Claude Opus 4.6 lief über AWS in Europa (Cross-region-inference) und war das zurückhaltendste Modell im Feld: 55 der 60 korrekten Abrechnungen gab es frei, mehr als jedes andere. Dafür hat es 13 Fehler übersehen, zwei davon in allen fünf Durchläufen. Einer war der Fall aus dem Kasten oben. In der Begründung stand die Rechnung sogar drin: 167,0 × 16,50 = 2.575,50 Euro, richtig sind 2.755,50 Euro. Das Modell hat die Multiplikation hingeschrieben und das falsche Ergebnis der Abrechnung übernommen, fünfmal hintereinander. Im zweiten Fall ging es um einen Minijob an der Geringfügigkeitsgrenze, und Opus setzte eine Grenze von 628 Euro an, mit der die Abrechnung aufging. Diese Grenze ist erfunden, sie liegt 2026 bei 603 Euro.
Bei Mistral lief Medium 3.5 direkt über die API des Anbieters, das neueste Modell des Hauses, in der eigenen Dokumentation als Frontier-Klasse geführt und im Output fünfmal teurer als das größere Large. Es fand 43 der 60 Fehler, zeigte dabei aber 15 Mal auf die falsche Position. Die andere Zahl ist die eigentliche: Von den 60 korrekten Abrechnungen hat Mistral keine einzige freigegeben. Jede saubere Abrechnung wurde beanstandet, in jedem Durchlauf. Die Begründungen zeigen, warum: 25 der Beanstandungen gehen auf einen veralteten Rechtsstand zurück, das Modell rechnet den Zusatzbeitrag zur Krankenversicherung komplett dem Arbeitnehmer zu. So war es bis Ende 2018, seit 2019 tragen Arbeitgeber und Arbeitnehmer ihn je zur Hälfte. Dazu kamen frei erfundene Regeln: Urlaubsabgeltung sei nicht beitragspflichtig, obwohl sie es ist; ein Sonntagszuschlag nur zu 25 Prozent steuerfrei, obwohl bis 50 Prozent des Grundlohns steuerfrei bleiben. Einen steuerfreien Höchstbetrag nannte das Modell in drei Anläufen mit drei verschiedenen Zahlen. In einem Fall nennt es in der Antwortzeile die Position [1] und schreibt zwei Sätze später: „daher ist die Berechnung hier korrekt. KEIN FEHLER.“
Qwen3 235B, ein Open-Weight-Modell des chinesischen Anbieters Alibaba, lief ebenfalls über AWS in Frankfurt, allerdings als Snapshot von Mitte 2025. Es fand 38 der 60 Fehler und gab zwei der 60 korrekten Abrechnungen frei. Auffällig war weniger die Quote als die Unruhe: In 20 von 24 Fällen wechselte die Antwort zwischen den fünf Durchläufen. Ein Fall ohne jede Besonderheit, bewusst als der langweiligste des Sets gebaut, bekam in fünf Durchläufen vier verschiedene Antworten: zweimal Position 5, einmal KEINE, dann 8, dann 9. Zehnmal hielt sich das Modell nicht an das Antwortformat, nannte erst eine Nummer, argumentierte sich zu KEINE und schrieb eine zweite Antwortzeile darunter. Und wie Mistral erfand es Rechengrößen: einen Pflegeversicherungssatz von 1,7 Prozent „bei Kind unter 23“, wo es 1,8 Prozent sind und die Altersgrenze bei 25 liegt, und einen Arbeitslosenversicherungsbeitrag von 1,2 Prozent „ab 2026“, wo es 1,3 Prozent sind.
Was lässt sich daraus ableiten?
Die erste Lehre steckt in den Wiederholungen. Kein Modell hat in allen 24 Fällen fünfmal dieselbe Antwort gegeben. Bei GPT kippten drei Fälle, bei Claude fünf, bei Mistral acht, bei Qwen zwanzig. Hätte ich jeden Fall nur einmal geprüft, wäre unter Umständen eine andere Rangfolge herausgekommen. Wie weit das reicht, zeigt eine Gegenprobe: Ein Modell habe ich vier Stunden später mit denselben Fällen und denselben Einstellungen komplett neu gemessen. Das Ergebnis wich um drei von 60 ab. Auch die Zahlen in diesem Artikel haben also eine Toleranz.
Die zweite Lehre: Trefferquoten allein führen in die Irre. Mistral hat 43 der 60 Fehler gefunden, das sind mehr als zwei Drittel und klingt erst einmal brauchbar. Zusammen mit den 59 Fehlalarmen sieht es anders aus. Ein Modell, das jede korrekte Abrechnung beanstandet, prüft nicht, es beanstandet nur. In der Praxis müsste jemand hinterher trotzdem jede Abrechnung selbst durchgehen, zusätzlich zur Zeit für die Vorprüfung.
Jede dieser Beanstandungen haben wir einzeln gegen den Fall gehalten. In einem Fall hatte tatsächlich GPT recht: In den Stammdaten stand ein falscher Beitragsgruppenschlüssel, den wir selbst eingebaut hatten, ohne es zu merken. Korrigiert, neu gemessen, danach gab es den Fall fünfmal von fünf frei.
Was der Test gekostet hat
Die 480 Antworten haben zusammen knapp neun Euro an Token-Kosten verursacht. Verteilt war das ungleich: Claude allein machte gut zwei Drittel davon aus, Mistral und Qwen zusammen keine 30 Cent. Der Abstand liegt nicht am Preis. Claude Opus ist pro Ausgabe-Token 17 Prozent billiger als GPT und kostet pro Antwort trotzdem mehr als das Doppelte, weil es im Schnitt 1.935 Ausgabe-Token schreibt, wo GPT mit 637 auskommt. Bei identischer Aufgabe. Der Kostentreiber ist also nicht der Tokenpreis, sondern die Ausführlichkeit.
Zwei Stellschrauben gehören dazu. Wer bei den Cloud-Anbietern nicht den globalen Endpunkt nimmt, sondern garantierte Verarbeitung in Europa, zahlt rund zehn Prozent Aufschlag. Und wer Anfragen asynchron einreicht und bis zu 24 Stunden auf das Ergebnis warten kann, zahlt etwa die Hälfte, kombinierbar mit der EU-Datenzone. Ich wollte das Ergebnis in diesem Fall sofort.
Wo die Grenzen liegen
Was dieser Test nicht sein soll: eine allgemeingültige Aussage über die getesteten Modelle. 24 konstruierte Fälle, eine einzige Art von Prüfauftrag, ein Durchgang. Meine Frau hat die Fälle plausibilisiert, aber nicht bis in die letzte Rechengröße nachgeprüft.
Das Feld war außerdem nicht gleich alt: GPT und Mistral in der jeweils aktuellen Spitzenvariante, eine ältere Claude Opus Version, Qwen ein Snapshot von Mitte 2025. Auf AWS habe ich genommen, was im Rahmen meiner Free Credits verfügbar war.
Bei Mistral kommt eine Unschärfe dazu. Ich habe das Modell über den Alias „medium-latest“ angesprochen, und die Schnittstelle gibt genau diesen Alias zurück, nicht die konkrete Fassung. Welche Version geantwortet hat, lässt sich aus meinen Daten nicht belegen.
Mein Fazit
Mein Fazit fällt entsprechend vorsichtig aus. Für diese Art Prüfaufgabe hat GPT-5.6 Sol in meinem Test am besten abgeschnitten und das schreibe ich als jemand, der sonst fast ausschließlich mit Claude arbeitet. Eine Empfehlung ist das nicht. Was ich hier gemacht habe, war eine Spielerei mit vier Modellen, die gerade verfügbar waren. Bei einem echten Anwendungsfall würde ich es anders aufziehen und gezielt die Spitzenmodelle gegeneinander laufen lassen, GPT Sol gegen das stärkste verfügbare Modell von Anthropic. In den EU-Regionen erscheinen neue Spitzenmodelle bei AWS allerdings oft mit etwas Verzögerung. Mistral und Qwen konnten diese konkrete Prüfaufgabe in meinem Test nicht zuverlässig lösen.
Was ich aus dem Test mitnehme, gilt unabhängig davon: Wer so etwas einsetzen will, sollte den eigenen Anwendungsfall selbst prüfen, mit Wiederholungen und dabei die Fehlalarme mitzählen, nicht nur die Treffer. Ein Modell, das nichts durchlässt, ist keine Hilfe. Und keines der vier war an einem Punkt, an dem die menschliche Prüfung überflüssig würde - das ist wahrscheinlich die wichtigste Erkenntnis.
← Zurück zum Maschinenraum