DE EN

Plattform

Die letzte Meile — warum 95% Erkennungsrate nicht reicht

Die meisten IDP-Projekte erreichen ein Plateau bei 80–90% Automatisierung. Dabei entscheiden die letzten 5–20% darüber, ob das Projekt tatsächlich Kosten spart — oder nur einen parallelen manuellen Prozess erzeugt.

Das Problem der letzten 5–20%

Die Wirtschaftlichkeit eines Automatisierungsprojekts kippt an einem Punkt, den viele Unternehmen unterschätzen: Wenn 20% der eingehenden Dokumente weiterhin manuell bearbeitet werden müssen, benötigen Sie nahezu denselben Personalstamm wie zuvor. Ein Sachbearbeiter, der vorher 100 Belege pro Tag verarbeitet hat, bearbeitet nun 20 manuell und prüft vielleicht weitere 30 in einer Validierungsqueue. Die Effizienzgewinne sind marginal, die Lizenzkosten für die IDP-Software kommen obendrauf. Das Ergebnis: höhere Gesamtkosten als vor der Automatisierung.

Warum erreichen die meisten IDP-Projekte dieses Plateau? Die Ursachen liegen in der Natur realer Dokumentenströme. Jeder Lieferant formatiert seine Rechnungen anders. Innerhalb derselben Belegart gibt es Dutzende Varianten — von strukturierten PDF-Rechnungen über eingescannte Faxe bis hin zu handschriftlichen Lieferscheinen. Dazu kommen schlechte Scans, gedrehte Seiten, mehrseitige Dokumente mit wechselnden Layouts und Belege in mehreren Sprachen. Diese sogenannten Long-Tail-Varianten machen einen kleinen Anteil des Gesamtvolumens aus, verursachen aber den Großteil der Fehler. Standardmodelle, die auf Benchmark-Datensätzen trainiert wurden, versagen hier systematisch.

In der Praxis entsteht dadurch die „80%-Falle": Ein Anbieter verspricht 95% Erkennungsrate — gemessen an Einzelfeldern in kontrollierten Tests. Im produktiven Betrieb bedeutet das aber, dass ein Dokument nur dann vollständig automatisch verarbeitet werden kann, wenn alle relevanten Felder korrekt erkannt wurden. Wenn von zehn Feldern pro Rechnung jedes einzelne zu 95% korrekt ist, liegt die Wahrscheinlichkeit, dass alle zehn stimmen, nur noch bei knapp 60%. Das Resultat: 40% der Dokumente landen in der manuellen Nachbearbeitung. Statt 95% Automatisierung erreichen Sie in der Praxis 60%.

Die Kosten dieser Ausnahmen werden regelmäßig unterschätzt. Jede manuelle Intervention — Öffnen des Dokuments, Vergleich mit den extrahierten Daten, Korrektur, Bestätigung — kostet im Durchschnitt drei bis fünf Minuten Bearbeitungszeit. Bei einem Volumen von 10.000 Belegen pro Monat und einer Ausnahmequote von 20% sind das 2.000 manuelle Eingriffe, also rund 125 Arbeitsstunden oder fast ein Vollzeitäquivalent. Rechnet man Personalkosten, Fehlerfolgekosten und Opportunitätskosten zusammen, kann eine schlecht gelöste letzte Meile den gesamten ROI des Projekts zunichtemachen.

Confidence Scores richtig einsetzen

Confidence Scores sind numerische Werte, die angeben, wie sicher sich ein Extraktionsmodell bei einem bestimmten Ergebnis ist. Ein Score von 0,99 bedeutet: Das Modell ist zu 99% sicher, dass der extrahierte Wert korrekt ist. Ein Score von 0,72 bedeutet: Es gibt erhebliche Unsicherheit, der Wert sollte von einem Menschen geprüft werden. Der entscheidende Unterschied zwischen einem funktionierenden und einem scheiternden IDP-System liegt darin, wie diese Scores operativ genutzt werden. Ohne Confidence Scores behandelt ein System jedes Ergebnis gleich — egal ob die Erkennung trivial oder grenzwertig war. Das führt entweder zu unentdeckten Fehlern oder zu einer pauschalen manuellen Prüfung aller Ergebnisse, was den Automatisierungsvorteil eliminiert.

Die richtige Strategie arbeitet mit abgestuften Schwellenwerten. Dokumente mit einem Confidence Score über einem oberen Schwellenwert — beispielsweise 97% — werden automatisch freigegeben und direkt an Folgesysteme übergeben. Dokumente zwischen dem oberen und einem unteren Schwellenwert — etwa zwischen 85% und 97% — landen in einer priorisierten Review-Queue, wo ein Sachbearbeiter nur die unsicheren Felder prüfen und bestätigen oder korrigieren muss. Dokumente unter dem unteren Schwellenwert werden zur vollständigen manuellen Bearbeitung markiert. Die Schwellenwerte sind dabei nicht statisch: Sie müssen pro Feldtyp und pro Dokumentenklasse kalibriert werden, weil die Fehlerkosten unterschiedlich sind.

Ein zentraler Aspekt ist die Unterscheidung zwischen Field-Level- und Document-Level-Confidence. Ein System kann für den Rechnungsbetrag einen Score von 99,5% ausgeben, für den Lieferantennamen aber nur 82%. Es wäre falsch, das gesamte Dokument in die manuelle Queue zu schieben — stattdessen sollte nur das unsichere Feld zur Prüfung vorgelegt werden. Umgekehrt kann ein Dokument, bei dem alle Felder einzeln über 95% liegen, trotzdem problematisch sein, wenn die Felder in ihrer Kombination inkonsistent sind — etwa wenn die IBAN nicht zum erkannten Lieferanten passt. Fortgeschrittene Systeme kombinieren daher Einzelfeld-Scores mit dokumentübergreifenden Plausibilitätsprüfungen.

In der Praxis sieht das so aus: Eine Eingangsrechnung wird verarbeitet. Der Rechnungsbetrag wird mit 99,5% Confidence erkannt — automatische Freigabe. Der Lieferantenname wird mit 85% Confidence erkannt — das Feld erscheint in der Review-Queue, vorausgefüllt mit dem wahrscheinlichsten Wert und zwei Alternativvorschlägen. Der Sachbearbeiter klickt auf den korrekten Wert, das Dokument ist in unter zehn Sekunden freigegeben. Ohne Confidence Scores hätte derselbe Sachbearbeiter alle Felder manuell geprüft — Zeitaufwand: drei bis fünf Minuten. Die operative Hebelwirkung richtig kalibrierter Confidence Scores liegt in der Reduktion der Review-Zeit pro Dokument um 80–90%.

Human-in-the-Loop UX

Die Validierungsoberfläche entscheidet darüber, ob Human-in-the-Loop ein Effizienzgewinn oder ein Produktivitätskiller ist. Ein gut gestaltetes Interface zeigt links das Originaldokument mit hervorgehobenen Extraktionsbereichen und rechts die extrahierten Felder in editierbarer Form. Der Sachbearbeiter sieht auf einen Blick, welche Felder unsicher sind — markiert durch Farbcodes oder Icons. Ein Klick auf ein Feld scrollt das Dokument automatisch zur relevanten Stelle. Die Korrektur erfolgt durch Bestätigung, Auswahl aus Vorschlägen oder direkte Eingabe — nicht durch erneutes Abtippen des gesamten Belegs. Dieses Prinzip heißt „One-Click Correction" und reduziert den Zeitaufwand pro Korrektur von Minuten auf Sekunden.

Für Hochvolumen-Szenarien reicht eine Einzeldokument-Ansicht nicht aus. Wenn ein Team täglich Hunderte von Dokumenten validiert, braucht es Batch-Review-Funktionalität: eine tabellarische Übersicht aller Dokumente in der Queue, sortiert nach Priorität, Dokumenttyp oder Confidence-Level. Sachbearbeiter können mehrere Dokumente gleichzeitig freigeben, Filter setzen und sich auf bestimmte Fehlertypen konzentrieren. Tastaturkürzel für die häufigsten Aktionen — Freigeben, Ablehnen, Nächstes Dokument — ermöglichen einen Durchsatz, der mit reiner Mausbedienung nicht erreichbar ist. Die besten Systeme erreichen eine Bearbeitungszeit von fünf bis zehn Sekunden pro Dokument in der Review-Queue.

Der strategisch wichtigste Aspekt von Human-in-the-Loop ist der Feedback-Loop: Jede Korrektur, die ein Sachbearbeiter vornimmt, ist ein Trainingssignal. Wenn ein Lieferantenname falsch erkannt wurde und der Sachbearbeiter den korrekten Wert eingibt, lernt das System aus dieser Korrektur. Beim nächsten Dokument desselben Lieferanten wird die Erkennung besser sein. Dieser Mechanismus macht Human-in-the-Loop zu einem sich selbst optimierenden System. Entscheidend dabei ist die Datenisolierung: Ihre Korrekturen und Ihre Daten trainieren ausschließlich Ihr Modell. Es findet kein Austausch von Trainingsdaten zwischen verschiedenen Mandanten statt. Ihre Geschäftsdokumente, Lieferanteninformationen und Korrekturhistorie bleiben vollständig in Ihrem isolierten Modell — kein anderer Kunde profitiert von Ihren Daten, und Sie nicht von deren.

Dieses Prinzip der strikten Mandantentrennung ist kein Komfortmerkmal, sondern eine Grundvoraussetzung für den Einsatz im regulierten Umfeld. Unternehmen in den Bereichen Finanzen, Recht, Gesundheitswesen und öffentliche Verwaltung können IDP-Systeme nur dann einsetzen, wenn garantiert ist, dass ihre Daten nicht in ein gemeinsames Modell einfließen. feld.ai setzt diese Trennung auf Infrastrukturebene um: getrennte Modellinstanzen, getrennte Trainingspipelines, getrennte Datenhaltung.

Visual Grounding

Visual Grounding bedeutet, dass jeder extrahierte Wert mit seiner Quellposition im Originaldokument verknüpft ist. Wenn das System einen Rechnungsbetrag von 14.350,00 EUR extrahiert, zeigt Visual Grounding exakt, wo auf dem Dokument dieser Betrag steht — inklusive Seitennummer, Position auf der Seite und einem Bounding-Box-Rahmen um den relevanten Textbereich. Diese Rückverfolgbarkeit unterscheidet ein professionelles Extraktionssystem von einer Black Box. In einer Black Box erhalten Sie einen extrahierten Wert, aber Sie können nicht nachvollziehen, woher er stammt. Wenn der Wert falsch ist, wissen Sie nicht, ob das Originaldokument fehlerhaft war, ob das System eine falsche Stelle gelesen hat oder ob die Interpretation des gelesenen Textes fehlerhaft war. Visual Grounding macht diesen Unterschied transparent.

Für Wirtschaftsprüfer, Steuerberater und Compliance-Abteilungen ist Visual Grounding kein Nice-to-have, sondern eine Pflichtanforderung. In der Finanzprüfung müssen extrahierte Buchungsdaten bis zum Originalbeleg rückverfolgbar sein. In der Steuerprüfung muss nachweisbar sein, aus welchem Beleg ein bestimmter Betrag stammt. In der Compliance muss dokumentiert werden, wie eine automatisierte Entscheidung zustande kam. Visual Grounding liefert genau diesen Audit Trail: ein vollständiges Protokoll darüber, welcher Wert von welcher Stelle welches Dokuments extrahiert wurde, wann die Extraktion stattfand und ob eine manuelle Korrektur erfolgt ist.

feld.ai implementiert Visual Grounding auf mehreren Ebenen. Auf der Basisebene erhält jedes extrahierte Feld eine Seitenreferenz und Bounding-Box-Koordinaten. In der Validierungsoberfläche wird die Quellstelle bei Auswahl eines Feldes automatisch hervorgehoben — der Sachbearbeiter sieht sofort, ob der extrahierte Wert mit dem Originaldokument übereinstimmt. Auf der API-Ebene werden die Koordinaten als strukturierte Metadaten mitgeliefert, sodass nachgelagerte Systeme — etwa ein DMS oder ein ERP — die Rückverfolgbarkeit ebenfalls abbilden können. Für komplexe Dokumente mit mehreren Tabellen oder mehrseitigen Positionen werden zusammengehörige Bereiche gruppiert und als logische Einheiten behandelt.

Der Weg zu 100% Straight-Through

Kontinuierliches Lernen

Jede Korrektur verbessert das Modell. Automatisch, ohne manuelles Retraining.

Edge-Case-Handling

Schlechte Scans, gedrehte Seiten, handschriftliche Notizen — systematisch abgedeckt.

Feedback-Loop

Korrektur → Modellupdate → weniger Korrekturen. Ein sich selbst verbessernder Kreislauf.

Monitoring

Echtzeit-Dashboard zeigt Erkennungsraten, Confidence-Verteilung und Ausnahmen.

Der Weg von 80% zu 100% Straight-Through-Processing ist kein linearer Anstieg, sondern gliedert sich in drei Phasen mit unterschiedlichen Anforderungen. Die erste Phase — von 80% auf 90% — ist primär ein Konfigurationsproblem. Hier geht es darum, die richtigen Dokumentenklassen zu definieren, Confidence-Schwellenwerte zu kalibrieren und die häufigsten Fehlerquellen zu identifizieren. Typische Maßnahmen sind die Anpassung der Felddefinitionen, die Integration von Stammdaten für den Abgleich und die Optimierung der Vorverarbeitung für schlechte Scans. Diese Phase dauert in der Regel vier bis sechs Wochen und erfordert enge Zusammenarbeit zwischen Fachabteilung und Implementierungsteam.

Die zweite Phase — von 90% auf 95% — erfordert systematisches Arbeiten an der Long-Tail-Verteilung. Hier helfen keine generischen Optimierungen mehr. Stattdessen werden die verbleibenden Fehler kategorisiert: Welche Lieferanten verursachen die meisten Korrekturen? Welche Feldtypen sind am fehleranfälligsten? Welche Dokumentvarianten werden nicht erkannt? Auf Basis dieser Analyse werden gezielte Verbesserungen vorgenommen — zusätzliche Trainingsbeispiele für problematische Lieferanten, spezifische Regeln für Sonderfälle, erweiterte Plausibilitätsprüfungen. Der Feedback-Loop aus dem Human-in-the-Loop-Prozess liefert die Trainingsdaten automatisch, aber die Analyse und Priorisierung erfordert menschliche Intelligenz.

Die dritte Phase — von 95% auf 99%+ — ist die anspruchsvollste und trennt professionelle Systeme von Standardlösungen. Hier werden die letzten Ausnahmen adressiert: handschriftliche Ergänzungen auf gedruckten Formularen, mehrseitige Dokumente mit wechselnden Layouts, Belege mit ungewöhnlichen Währungen oder Datumsformaten, beschädigte Scans. In dieser Phase kommt die Kombination aus kontinuierlichem Lernen, Echtzeit-Monitoring und proaktivem Edge-Case-Management zum Tragen. Das Monitoring-Dashboard zeigt in Echtzeit, welche Dokumente in der Ausnahmebehandlung landen, wie sich die Confidence-Verteilung über die Zeit entwickelt und wo neue Muster auftreten. Ziel ist nicht die statische Erreichung von 99%, sondern ein System, das sich dynamisch an veränderte Dokumentenströme anpasst.

Warum Dark Processing scheitert

Dark Processing — die vollautomatische Verarbeitung ohne jegliche menschliche Überprüfung — klingt nach dem Idealzustand der Dokumentenautomatisierung. Kein Sachbearbeiter, keine Queue, keine Validierung. Dokument rein, Daten raus, direkt ins ERP. In der Theorie ist das die maximale Effizienz. In der Praxis ist es die häufigste Ursache für gescheiterte IDP-Projekte. Der Grund ist einfach: Fehler, die nicht erkannt werden, propagieren lautlos durch nachgelagerte Systeme. Eine falsch erkannte IBAN führt zu einer Fehlüberweisung. Ein falscher Rechnungsbetrag verfälscht die Buchführung. Ein falsch zugeordneter Lieferant erzeugt Fehler in der Kreditorenbuchhaltung, die erst Wochen später im Monatsabschluss auffallen.

Große Technologieanbieter bewerben ihre Lösungen zunehmend mit dem Versprechen, dass KI „einfach funktioniert" — ohne menschliche Eingriffe, ohne Validierung, ohne Konfiguration. SAP Joule, Microsoft Copilot und ähnliche Plattformen suggerieren, dass eine generische KI Geschäftsdokumente verstehen und korrekt verarbeiten kann, ohne domänenspezifisches Training und ohne Qualitätssicherung. Das ignoriert eine fundamentale Realität: Geschäftsdokumente sind keine generischen Texte. Sie folgen branchenspezifischen Konventionen, unternehmensspezifischen Formaten und prozessspezifischen Anforderungen. Ein generisches Sprachmodell kann eine Rechnung „lesen", aber es kann nicht beurteilen, ob der extrahierte Betrag zum Bestellwert passt, ob die Kontonummer im Lieferantenstamm existiert oder ob die Mehrwertsteuer korrekt berechnet wurde. Die Validierungsschicht ist nicht optional — sie ist der Kern eines zuverlässigen Systems.

Der richtige Ansatz ist nicht die Abschaffung des Menschen, sondern seine schrittweise Entlastung. Am Anfang steht ein Human-in-the-Loop-System mit niedrigen Confidence-Schwellenwerten — viele Dokumente werden manuell geprüft, aber jede Prüfung verbessert das Modell. Mit steigender Datenqualität und wachsendem Trainingsdatensatz werden die Schwellenwerte angehoben. Der Anteil der automatisch freigegebenen Dokumente steigt von 60% über 80% auf 90% und darüber. Irgendwann prüft ein Sachbearbeiter nur noch die wenigen echten Ausnahmen — nicht weil das System seine Beteiligung braucht, sondern weil diese Ausnahmen tatsächlich menschliches Urteilsvermögen erfordern. Dieser graduelle Übergang ist der einzige Weg, der in der Praxis funktioniert, weil er Qualität und Effizienz nicht gegeneinander ausspielt, sondern beide gleichzeitig steigert.

Ihre Erkennungsrate auf 100% bringen

Demo anfragen
Mit Gründer sprechen