KI-Benchmark für Rechnungen: Goldstandard im KMU

Eine KI für Rechnungserfassung sollte nicht nach Demo-Eindruck ausgewählt werden, sondern nach einem reproduzierbaren Test mit eigenen Belegen. Dafür braucht ein KMU keinen Datenwissenschaftsbereich. Ein fachlich geprüfter Goldstandard aus etwa 100 repräsentativen Testrechnungen, getrennte Metriken für kritische Felder und klare Go/No-Go-Grenzen reichen für eine belastbare erste Entscheidung.

Der Benchmark beantwortet drei Fragen: Erkennt das System die richtigen Werte? Markiert es Unsicherheit rechtzeitig? Und bleibt die Qualität stabil, wenn Layout, Sprache, Belegart oder Modellversion wechseln?

Warum Herstellerquoten wenig über Ihren Alltag sagen

Eine allgemeine Genauigkeitsangabe kann auf sauberen Standardrechnungen gemessen sein. Ihr Belegmix enthält vielleicht handwerkliche Kleinbetriebe, mehrseitige Anlagen, fremdsprachige Lieferanten, Gutschriften, Scans und strukturierte E-Rechnungen. Schon die Definition von „korrekt“ kann abweichen: Zählt ein richtig erkannter Betrag, wenn er dem falschen Feld zugeordnet wurde?

Das NIST AI Risk Management Framework empfiehlt objektive, wiederholbare und dokumentierte Test-, Bewertungs-, Verifikations- und Validierungsprozesse. Testbedingungen sollen dem Einsatz ähneln, Unsicherheiten und Grenzen dokumentiert werden. Für KMU bedeutet das: Der eigene Benchmark ist wichtiger als eine nicht nachvollziehbare Durchschnittsquote.

Was ein Goldstandard ist

Der Goldstandard ist ein unveränderter Satz von Testbelegen mit fachlich geprüften Sollwerten. Für jede Rechnung werden relevante Felder und erwartete Prozessentscheidungen festgehalten. Die KI-Ausgabe wird später automatisiert oder manuell dagegen verglichen.

Der Goldstandard darf nicht aus den Ergebnissen des zu testenden Systems erzeugt werden. Sonst übernimmt er dessen Fehler. Mindestens zwei fachkundige Personen sollten kritische Sonderfälle prüfen, insbesondere Steuerbetrag, Währung, Belegart, Lieferant und Bankdaten.

Testgruppe	Beispiele	Warum nötig
Standardfälle	Häufige Lieferanten, klare PDFs	Basisleistung und Durchsatz
Qualitätsprobleme	Scan, Foto, Schräglage, Stempel	Robustheit der Erfassung
Belegarten	Rechnung, Gutschrift, Korrektur	Verwechslungen verhindern
Steuerfälle	Mehrere Sätze, Reverse Charge, Ausland	Fachliche Risiken sichtbar machen
Strukturvarianten	PDF, XML, eingebettete Datei	Datenquellen sauber trennen
Angriffsfälle	Geänderte IBAN, manipulierte Anweisung	Sicheres Scheitern prüfen

100 Belege sinnvoll auswählen

Eine zufällige Stichprobe aus dem letzten Monat ist selten repräsentativ. Große Lieferanten dominieren, seltene Risiken fehlen. Teilen Sie den Satz deshalb bewusst auf. Ein praktikabler Start:

40 häufige Standardrechnungen,
15 Scans und Smartphone-Fotos unterschiedlicher Qualität,
15 Gutschriften, Korrekturen und mehrseitige Dokumente,
10 Rechnungen mit mehreren Steuersätzen oder Währungen,
10 strukturierte E-Rechnungen in real verwendeten Profilen,
10 kritische Sicherheits- und Ausnahmefälle.

Entfernen oder anonymisieren Sie personenbezogene und vertrauliche Daten, soweit sie für den Test nicht benötigt werden. Speichern Sie keine echten Bankdaten in einer frei zugänglichen Testumgebung.

Feldgenauigkeit statt Dokumentquote

Eine Rechnung kann zu 95 Prozent richtig aussehen und beim einzigen kritischen Feld falsch sein. Messen Sie deshalb pro Feld. Für jeden Sollwert gibt es mindestens vier Ergebnisse: korrekt, falsch, nicht erkannt oder fälschlich ergänzt.

Normalisierung gehört zur Testdefinition. Bei Datum, Betrag und UID kann ein anderes Format denselben Wert darstellen. Bei Rechnungsnummern können Leerzeichen oder Bindestriche unerheblich sein, führende Nullen dagegen relevant. Legen Sie diese Regeln vor dem Test fest.

Präzision und Vollständigkeit bei Warnungen

Bei Risikowarnungen reichen Trefferzahlen nicht. Zwei Metriken sind wichtig:

Präzision: Wie viele Warnungen sind tatsächlich berechtigt?
Vollständigkeit: Wie viele bekannte Risikofälle wurden erkannt?

Ein System, das jede Rechnung blockiert, findet alle Risiken und ist trotzdem unbrauchbar. Ein System mit wenigen, sehr präzisen Warnungen kann gefährliche Fälle übersehen. Die richtige Balance hängt von finanzieller Wirkung und manueller Prüfkapazität ab.

Go/No-Go-Grenzen vor dem Test festlegen

Wenn Grenzwerte erst nach Sichtung der Ergebnisse gewählt werden, entsteht leicht Schönfärberei. Definieren Sie vorab Muss-Kriterien. Beispiele:

Kein Testfall mit geänderter IBAN darf automatisch zahlbar werden.
Fehlende Seiten müssen den Vorgang stoppen.
Brutto, Währung und Steuerbetrag brauchen eine höhere Mindestqualität als Adressfelder.
Ein unbekannter Belegtyp darf nicht als Standardrechnung durchlaufen.
Ausgaben aus manipulierten Dokumenten dürfen keine Folgeaktion auslösen.

Zusätzlich können Zielwerte für Automatisierungsquote und Korrekturzeit gelten. Ein No-Go bei Sicherheit darf nicht durch schnelle Standardfälle kompensiert werden.

Blindtest und unabhängige Prüfung

Die Person, die Sollwerte erstellt, sollte nicht jede KI-Ausgabe nachträglich passend interpretieren. Führen Sie den Benchmark als Blindtest durch: Eingabe bleibt unverändert, Ergebnis wird gespeichert und erst danach mit dem Goldstandard verglichen.

Bei strittigen Fällen entscheidet eine fachlich unabhängige Person. Dokumentieren Sie die Regel, nicht nur die Einzelfallentscheidung. Das erhöht die Vergleichbarkeit bei späteren Modellen.

Praxisbeispiel 1: Handelsbetrieb in Österreich

Ein österreichischer Händler vergleicht zwei Erfassungslösungen. System A erkennt Standard-PDFs schneller. System B ist bei Fotos langsamer, markiert aber unsichere Steuerbeträge häufiger. Die ursprüngliche Gesamtscore-Betrachtung bevorzugt A.

Nach getrennten Metriken zeigt sich: A übernimmt drei kritische Beträge falsch und ohne Warnung. B blockiert diese Fälle. Der Betrieb entscheidet sich für B und optimiert anschließend nur die Bearbeitungs-Queue. Sicherheit und Komfort werden nicht in einer unklaren Durchschnittszahl vermischt.

Praxisbeispiel 2: Beratungsunternehmen in Deutschland

Ein deutsches Beratungsunternehmen testet ein Modellupdate gegen denselben Goldstandard. Die allgemeine Feldgenauigkeit steigt von 94 auf 96 Prozent. Gleichzeitig sinkt die Erkennung von Gutschriften, weil deren Layout im Testset selten war.

Das Update geht deshalb nicht sofort produktiv. Der Anbieter korrigiert die Klassifikation, und die unveränderten Kontrollfälle werden erneut ausgeführt. Erst als alle Muss-Kriterien erfüllt sind, wird die Version freigegeben.

Modellversion und Konfiguration festhalten

Ein Ergebnis ist nur reproduzierbar, wenn Modell, Version, Prompt beziehungsweise Extraktionsschema, Vorverarbeitung und Testdatum bekannt sind. Auch Anbieteränderungen ohne sichtbaren Versionssprung können Qualität beeinflussen. Speichern Sie deshalb die technische Konfiguration und einen Hash des Testsets.

Der Beitrag Gleiche Rechnung, anderes KI-Ergebnis zeigt, welche Angaben bei Modellwechseln dokumentiert werden sollten.

Produktionsdaten nach dem Go-Live beobachten

Ein Benchmark ist eine Startentscheidung, keine Dauergarantie. Lieferantenlayouts, Sprachen und Belegarten ändern sich. Ziehen Sie regelmäßig eine fachlich geprüfte Stichprobe aus echten, datenschutzgerecht behandelten Vorgängen. Neue Fehlerfälle ergänzen einen separaten Erweiterungssatz.

Der Kernsatz bleibt unverändert, damit Versionen vergleichbar sind. Neue Fälle dürfen nicht rückwirkend alte Ergebnisse verändern. Zeigen sich systematische Abweichungen, wird das betroffene Feld stärker kontrolliert oder die Automatisierung vorübergehend reduziert.

Datenschutz im Test

Ein Benchmark rechtfertigt nicht die unbegrenzte Übertragung echter Rechnungen. Prüfen Sie Zweck, Datenminimierung, Anbieterrolle, Speicherfristen und Empfänger. Das EDPB beschreibt für LLM-Systeme eine systematische Methode zur Identifikation und Minderung von Datenschutzrisiken.

Anonymisierung muss tatsächlich wirksam sein. Lieferantenname, Freitext und Leistungsbeschreibung können Personen oder Projekte indirekt identifizieren. Wo realistische Daten unverzichtbar sind, braucht es eine dokumentierte datenschutzrechtliche Grundlage und geschützte Testumgebung.

Österreich und Deutschland

Die technische Testmethode ist in beiden Ländern gleich. Rechtliche Bewertung, Aufbewahrung und steuerliche Sonderfälle können abweichen. Deshalb müssen Fachpersonen aus dem jeweiligen Land die Sollwerte für kritische Fälle bestätigen.

Der Benchmark ist keine Rechts- oder Steuerberatung. Er zeigt, ob ein System definierte Aufgaben in Ihrem Einsatzkontext zuverlässig unterstützt und sicher scheitert.

Checkliste für einen belastbaren Benchmark

Aufgabe und erlaubte Folgeaktionen eindeutig beschreiben.
Repräsentative Beleggruppen bewusst auswählen.
Sollwerte unabhängig vom getesteten Modell erstellen.
Kritische Felder und Muss-Kriterien vorab definieren.
Originaleingaben für alle Systeme identisch halten.
Feldgenauigkeit, Warnpräzision und Warnvollständigkeit trennen.
Fehlalarme und manuelle Prüfzeit messen.
Modell, Version, Konfiguration und Testset-Hash dokumentieren.
Kernsatz für spätere Vergleiche unverändert lassen.
Nach Go-Live regelmäßige Produktionsstichproben prüfen.

Bestehende Claribill-Inhalte sinnvoll nutzen

Die Claribill-Sicherheitsseite beschreibt öffentlich dokumentierte Schutzprinzipien. Die Kontrollmatrix für KI-Rechnungsdaten hilft bei Feldschwellen. Einen breiteren Einstieg bietet KI in der Rechnungsverarbeitung. Eine integrierte KI-Benchmark-Funktion wird hier nicht behauptet; der Beitrag beschreibt ein Auswahl- und Kontrollverfahren.

Die wichtigsten Takeaways

Praxisbeispiel: Warum dieselbe Trefferquote zu einer anderen Entscheidung führt

Ein technischer Großhandel vergleicht zwei Systeme mit jeweils 100 Eingangsrechnungen. System A erreicht über alle Felder 96 Prozent, System B 94 Prozent. Auf den ersten Blick scheint A überlegen. Die Feldtabelle zeigt jedoch: A verwechselt bei vier Rechnungen die Lieferanten-IBAN und meldet den Konflikt nur einmal. B liest drei IBANs falsch, stoppt aber alle drei Fälle mit einer Warnung. Für Stammdaten und Zahlungsfreigabe ist B deshalb trotz geringerer Gesamtquote die sicherere Wahl.

Bei Positionsbeschreibungen ist das Bild umgekehrt. System B erzeugt viele Warnungen bei zulässigen Abkürzungen und bindet dadurch jeden Tag zusätzliche Prüfzeit. Der Betrieb entscheidet daher nicht pauschal für oder gegen ein System. Er verwendet die Ergebnisse, um einen Pilotprozess zu entwerfen: Zahlungsrelevante Felder werden streng gestoppt, Positionsbeschreibungen erhalten eine tolerantere Schwelle, und alle Warnungen werden vier Wochen lang mit Ursache und Bearbeitungszeit dokumentiert.

Dieses Beispiel zeigt den Wert eines Goldstandards. Eine Durchschnittsquote verdichtet verschiedene Fehler zu einer Zahl und verdeckt ihre wirtschaftliche Bedeutung. Erst die Verbindung aus Feldkritikalität, Erkennungswahrscheinlichkeit, Warnverhalten und manueller Nacharbeit beantwortet die betriebliche Frage: Welche Lösung reduziert das Gesamtrisiko, ohne die Buchhaltung mit Fehlalarmen zu überlasten?

Wie der Benchmark zur belastbaren Freigabeentscheidung wird

Die Auswertung sollte in einer kurzen Entscheidungsvorlage enden. Darin stehen Testumfang, Belegmix, Modell- und Versionsangaben, Ergebnisse je kritischem Feld, dokumentierte No-Go-Verstöße und der erwartete Prüfaufwand. Ergänzen Sie offene Risiken und die Bedingungen für einen Pilotbetrieb. Ein Ergebnis wie „geeignet unter der Bedingung, dass Bankdaten immer gegen freigegebene Stammdaten geprüft werden“ ist ehrlicher und nützlicher als ein pauschales Gütesiegel.

Die Freigabe bleibt zeitlich begrenzt. Neue Lieferantenlayouts, andere Sprachen, Modellupdates oder veränderte Buchungsregeln können die Leistung verschieben. Legen Sie deshalb schon im Benchmark fest, wann ein erneuter Test nötig wird: etwa nach einem Modellwechsel, bei einer auffälligen Fehlerquote oder wenn eine neue Beleggruppe einen relevanten Anteil erreicht. So wird aus dem einmaligen Vergleich ein kontrollierter Qualitätsprozess.

Ein guter KI-Benchmark beginnt mit eigenen, fachlich geprüften Testrechnungen. Er misst kritische Felder und Warnungen getrennt, definiert No-Go-Kriterien vorab und dokumentiert die technische Konfiguration.

Die beste Lösung ist nicht zwingend die mit der höchsten Durchschnittsquote. Entscheidend ist, ob sie in Ihrem Belegmix Risiken sichtbar macht, sicher stoppt und mit vertretbarem Prüfaufwand betrieben werden kann.

FAQ

Sind 100 Rechnungen statistisch ausreichend?

Für eine endgültige statistische Aussage oft nicht, für einen strukturierten KMU-Vergleich aber ein brauchbarer Start. Wichtiger als reine Menge ist die Abdeckung kritischer Gruppen. Erweitern Sie das Set, wenn seltene Belege oder Fehler nicht vertreten sind.

Darf der Anbieter den Goldstandard sehen?

Für Fehleranalyse kann das sinnvoll sein, sofern Datenschutz und Vertraulichkeit geklärt sind. Für einen fairen Erstvergleich sollte der Anbieter die konkreten Testantworten nicht vorab zur Optimierung erhalten.

Kann eine Demo den Benchmark ersetzen?

Nein. Eine Demo zeigt Bedienung und ausgewählte Beispiele. Der Benchmark prüft Ihre Belege, Ihre Risiken und vorher festgelegte Kriterien.

100 Testrechnungen statt Bauchgefühl: So benchmarken KMU ihre KI-Erfassung