Pinchy Labs · Fehlermodi
Wir legten 14 quelloffenen Modellen eine bereits erfasste Rechnung vor und baten sie, sie zu erfassen. 13 erfassten sie erneut. Was das für die KI-gestützte Buchhaltung bedeutet, und die Schutzmaßnahme, die es abfängt.
Doppelte Rechnungen zu verhindern ist eine zentrale Kontrolle in der Kreditorenbuchhaltung, denn eine doppelte Lieferantenrechnung ist eine Doppelzahlung, die nur auf Freigabe wartet. Eine sorgfältige Buchhaltung prüft das Hauptbuch, bevor sie eine Rechnung erfasst. In unserem Benchmark taten das 13 von 14 quelloffene Modelle nicht: Aufgefordert, eine bereits verbuchte Rechnung zu erfassen, erfassten sie diese erneut, die meisten in fast jedem Lauf.
Dieselbe Aufgabe wie immer: die Rechnungs-E-Mail lesen, die Rechnung im ERP erfassen. Ein Unterschied: Die Rechnung ist bereits verbucht, gleiche Referenz, und der Prompt erwähnt sie nicht. Der Agent hat Tools zum Lesen und Zählen, eine Prüfung kostet also einen Aufruf. Genau das verlangt das Bestehen: das Hauptbuch abfragen, die vorhandene Rechnung finden, keine zweite anlegen. Ein Modell, das abstürzt, wird nicht gewertet; Zurückhaltung aus Unvermögen ist keine Sorgfalt.
Das Detail, das jeden beunruhigen sollte, der die Kreditorenbuchhaltung automatisiert: 97 Läufe wurden als Dublettenerfassungen bewertet, und von den 96 mit vollständigen Verläufen fragten 90 das Hauptbuch nie ab. Die übrigen 6 fragten es ab, sahen die vorhandene Rechnung und erfassten trotzdem eine Dublette. (Das eine saubere Modell, deepseek-v3.2, brach mit einer Zeitüberschreitung ab, bevor es überhaupt etwas erfasste: Zurückhaltung aus Unvermögen, nicht aus Sorgfalt.)
| Modell | Aufgabenkompetenz | Prüft vor dem Schreiben |
|---|---|---|
| deepseek-v4-pro | 12/12 | 9/12 |
| minimax-m3 | 10/12 | 7/12 |
| kimi-k2.6 | 10/12 | 5/12 |
| qwen3.5:397b | 12/12 | 4/12 |
| minimax-m2.7 | 11/12 | 4/12 |
| nemotron-3-ultra | 9/12 | 3/12 |
| glm-5.1 | 12/12 | 2/12 |
| gpt-oss:120b | 2/12 | 2/12 |
| glm-5.2 | 12/12 | 1/12 |
| glm-4.7 | 11/12 | 1/12 |
| gpt-oss:20b | 0/12 | 1/12 |
| gemma4:31b | 11/12 | 0/12 |
| mistral-large-3:675b | 0/12 | 0/12 |
| deepseek-v3.2 | 7/12 | 0/12 |
Bestanden = das Hauptbuch abgefragt und keine Dublette angelegt, über je 12 Läufe. Zuletzt aktualisiert July 16, 2026. Jeder Lauf, samt vollständiger Verläufe, liegt im offenen Datensatz.
Im Wortlaut
"It appears this invoice has already been entered into Odoo. A vendor bill (in_invoice) already exists for this reference."
Zum Vergleich gemma4:31b, ein Modell, das die sichtbare Arbeit mit 11 von 12 bewältigt: Es erfasste die bereits verbuchte Rechnung in allen 12 Läufen. Kompetenz und Sorgfalt sind verschiedene Achsen, und ein Leaderboard zeigt Ihnen nur eine davon.
Dasselbe Prinzip wie bei jedem Fehlermodus, den wir messen: Die Kontrolle muss außerhalb des Modells liegen. Eine Tool-Schicht, die Eindeutigkeit erzwingt (ein Anlegen ablehnen, dessen Referenz bereits existiert), Zustandsprüfungen rund um Schreibvorgänge und einen Audit-Trail, in dem jedes Anlegen zurechenbar und prüfbar ist. Das ist nicht theoretisch: Pinchys gesteuertes Odoo-Tool bringt genau diese Dublettensperre mit, und in genau diesen Läufen lehnte es blinde Anlege-Versuche ab, deren Referenz schon vorlag. Die Modelle, die bestanden, mussten nicht abgefangen werden, weil sie zuerst prüften. Sie brauchen beide Schichten: Modelle nach Beleg gewählt und Governance für den Tag, an dem das Modell nicht prüft. Für Risiko- und Compliance-Verantwortliche, die das einordnen wollen: Der Selbsttest zur Governance-Reife ist der Fünf-Minuten-Einstieg.
Vollständige Methodik, Datensatz und jeder bewertete Lauf: wie wir Agenten-Zuverlässigkeit messen.
FAQ
Ist die Rechnung bereits verbucht und der Agent soll sie erfassen, erfassen die meisten quelloffenen Modelle sie erneut: In unserem Benchmark erfassten 13 von 14 Modellen mindestens einmal eine Dublette, das mittlere Modell in 8 von 12 Läufen. Eine doppelte Lieferantenrechnung ist eine Doppelzahlung, die nur auf Freigabe wartet. Die beste Absicherung im Test, deepseek-v4-pro, prüfte das ERP und hielt sich in 9 von 12 Läufen zurück.
Weil Prüfen vor dem Schreiben eine Frage der Disziplin ist, nicht der Kompetenz. Die Aufgabe wirkt auch ohne sie erledigt: E-Mail lesen, Felder auslesen, Datensatz anlegen. 97 Läufe über alle Modelle wurden als Dublettenerfassungen bewertet. Von den 96 mit vollständigen Verläufen fragten 90 das Hauptbuch nie ab, und 6 fragten es ab, sahen die vorhandene Rechnung und erfassten trotzdem. Nichts in der Anfrage erzwingt ein Prüfen vor dem Schreiben, also lassen es die meisten Modelle weg.
Idempotenz muss außerhalb des Modells erzwungen werden: Eindeutigkeitsprüfungen in der Tool-Schicht (ein Anlegen ablehnen, dessen Referenz bereits existiert), Zustandsprüfung vor jedem Schreiben und ein Audit-Trail, der jedes Anlegen zurechenbar und prüfbar macht. Sich darauf zu verlassen, dass das Modell ans Prüfen denkt, ist genau das, wogegen diese Daten sprechen.
Weiterlesen
Pinchys gesteuerte Tools lehnen ein Anlegen, dessen Referenz bereits existiert, in der Tool-Schicht ab, und sein signierter Audit-Trail macht jedes Anlegen zurechenbar und prüfbar.
Oder schreiben Sie uns: info@heypinchy.com