Dokumentenprüfung automatisieren: prüfen statt nur auslesen.

Auslesen, validieren und freigeben sind drei verschiedene Entscheidungen

OCR erkennt Zeichen, ein Extraktionsmodell ordnet Inhalte Feldern zu und eine Klassifikation bestimmt den vermuteten Dokumenttyp. Keiner dieser Schritte beantwortet bereits, ob die Unterlage vollständig, in sich schlüssig, zum Geschäftsvorgang passend und für die nächste Aktion freigegeben ist.

Diese Trennung verhindert eine gefährliche Abkürzung: Ein technisch sauber gelesener Betrag kann fachlich falsch sein, zu einer anderen Bestellung gehören oder einer erforderlichen Freigabe widersprechen. Das System sollte deshalb jeden erkannten Wert als Kandidaten mit Herkunft behandeln, bis die vorgesehenen Prüfungen bestanden sind.

Mit Prüfziel und Folgeentscheidung beginnen

Die Frage „Ist das Dokument korrekt?“ ist für eine Automatisierung zu unscharf. Ein Prüfziel beschreibt konkret, welche Entscheidung vorbereitet wird: Darf eine Rechnung zur sachlichen Prüfung weiterlaufen, ist ein Nachweis vollständig, passt ein Servicebericht zum Auftrag oder muss eine Unterlage zurückgefragt werden?

Danach werden die möglichen Folgen festgelegt. Ein fehlendes Pflichtfeld kann eine Rückfrage auslösen, ein technischer Defekt einen erneuten Import und ein Widerspruch zur Bestellung eine fachliche Prüfung. Ohne diese Zuordnung produziert das System zwar Hinweise, aber keinen beherrschbaren Ablauf.

• Dokumentklasse und konkrete Geschäftsentscheidung benennen
• verbindliche Pflichtangaben und zulässige Varianten festlegen
• Referenzsysteme und deren Aktualitätsstand bestimmen
• Fehlerklassen mit Schweregrad und Folgeaktion definieren
• Freigabe, Rückfrage, Korrektur und Abbruch als Prozesszustände modellieren

Sechs Prüfschichten vom Eingang bis ins führende System

Eine robuste Prüfarchitektur arbeitet von der technischen Verlässlichkeit zur fachlichen Wirkung. Jede Schicht kann den Vorgang weitergeben, mit einem konkreten Hinweis zur Prüfung vorlegen oder kontrolliert stoppen.

• Eingang und Integrität: Quelle, Empfangszeit, Dateityp, technische Lesbarkeit, Seitenzahl und eindeutige Dokumentkennung erfassen.
• Dokumenttyp und Kontext: Version, Absender, Vorgangsbezug und erwartete Unterlagen gegen den bekannten Geschäftsfall abgleichen.
• Extraktion mit Herkunft: Werte nicht nur speichern, sondern mit Seite, Position und verwendetem Extraktionsstand verknüpfen.
• Vollständigkeit und Formate: Pflichtfelder, erwartete Anlagen, Datums- und Nummernformate sowie dokumentinterne Summen prüfen.
• Plausibilität und Abgleich: Werte gegen Bestellung, Vertrag, Stamm- oder Bewegungsdaten im jeweils führenden System vergleichen.
• Entscheidung und Übergabe: geprüfte Ergebnisse freigeben, Abweichungen gezielt vorlegen und jede Schreibaktion in DMS, ERP oder Fachverfahren bestätigen lassen.

Ein Prüfkatalog macht Fachwissen ausführbar

Der Prüfkatalog ist die Verbindung zwischen Fachabteilung und Technik. Für jedes relevante Feld oder Dokumentmerkmal beschreibt er nicht nur eine Regel, sondern auch deren Quelle und betriebliche Konsequenz. So bleibt unterscheidbar, ob ein Hinweis aus einer formalen Prüfung, einem Fachsystem oder einer unsicheren Modellbewertung stammt.

Ein sinnvoller Eintrag enthält Prüfobjekt, Regel, maßgebliche Referenz, Toleranz, Schweregrad, Ergebnistext und Folgeaktion. Bei einer Rechnung könnte das beispielsweise der Abgleich von Lieferant und Bestellnummer mit dem ERP sein; bei einem Wartungsnachweis die Zuordnung von Anlage, Zeitraum und geforderten Bestandteilen.

• Prüfobjekt: welches Feld, welche Seite oder welche Dokumentkombination betroffen ist
• Regel: welche Bedingung als bestanden, unklar oder verletzt gilt
• Referenz: aus welchem System und welchem Datenstand der Vergleichswert stammt
• Toleranz: welche Abweichung fachlich zulässig ist und wer sie festgelegt hat
• Aktion: automatisch fortsetzen, zur Prüfung vorlegen, Rückfrage erzeugen oder stoppen
• Nachweis: welche Eingangsdaten, Regelversion und Entscheidung protokolliert werden

Regel, Modell und Fachsystem prüfen unterschiedliche Dinge

Nicht jede Prüfung braucht KI. Eindeutige Formate, Pflichtfelder, Rechenbeziehungen und bekannte Identifikatoren lassen sich meist deterministisch prüfen. Modelle helfen dort, wo Layouts variieren, Inhalte sprachlich beschrieben werden oder ein Dokument zunächst klassifiziert werden muss. Der fachliche Wahrheitsabgleich bleibt Aufgabe des führenden Systems oder einer ausdrücklich freigegebenen Referenz.

Diese drei Prüfarten sollten im Ergebnis nicht zu einem einzigen Score verschmelzen. Ein Feld kann sicher extrahiert und formal gültig sein, aber trotzdem einer gesperrten Bestellung widersprechen. Umgekehrt darf eine niedrige Modellkonfidenz nicht als fachlicher Fehler ausgegeben werden. Für jeden Hinweis muss daher sichtbar bleiben, welche Prüfung ihn ausgelöst hat und welche Folge daraus entsteht.

• Deterministische Regel: Format, Pflichtfeld, erlaubter Wertebereich, Summe oder dokumentinterne Abhängigkeit prüfen.
• Modellbewertung: Dokumenttyp, Textbedeutung, variable Positionen oder schwer strukturierbare Inhalte als Kandidat erkennen.
• Fachsystemabgleich: Bestellstatus, Vertragsstand, Lieferant, Anlage oder Vorgang gegen die verbindliche Quelle prüfen.
• Menschliche Entscheidung: unklare, widersprüchliche oder folgenreiche Fälle anhand des Originaldokuments freigeben oder zurückweisen.

Plausibilität braucht verlässliche Referenzdaten

Eine KI kann sprachliche Zusammenhänge erkennen, aber keine fehlende betriebliche Wahrheit ersetzen. Für Lieferantenstamm, Bestellstatus, Vertragsversion oder Anlagenkennung muss feststehen, welches System den verbindlichen Wert führt. Eine alte Exportdatei und eine aktuelle ERP-Abfrage dürfen nicht gleichbehandelt werden.

Referenzdaten erhalten deshalb Quelle, Zeitstempel und fachliche Gültigkeit. Bei widersprüchlichen oder nicht erreichbaren Quellen sollte das System keinen passenden Wert erfinden oder stillschweigend korrigieren. Es erzeugt einen erklärbaren Prüfgrund und erhält den ursprünglich extrahierten Wert für die Bearbeitung.

Beispielprozess: Einen Servicebericht gegen Auftrag und Anlage prüfen

Ein Servicebericht eignet sich als Demonstrationsbeispiel, weil Dokumentinhalt, Vorgangsdaten und technische Anlage zusammengeführt werden müssen. Das Ziel lautet nicht pauschal „Bericht korrekt“, sondern: Darf der dokumentierte Einsatz dem Auftrag zugeordnet und zur weiteren Abrechnung oder Nachbearbeitung freigegeben werden?

Der Ablauf beginnt im Eingangskanal oder DMS. Dort werden Originaldatei, Eingangszeit, technische Kennung und Dokumentversion registriert. Die Extraktion liefert unter anderem Auftragsnummer, Anlagenkennung, Einsatzdatum, ausgeführte Arbeiten und dokumentierte Abweichungen – jeweils mit Fundstelle im Original. Anschließend fragt die Automatisierung die verbindlichen Auftrags- und Anlagendaten aus dem ERP oder Service-System ab.

Deterministische Regeln prüfen Pflichtangaben, Datumsbeziehungen und die Zuordnung von Auftrag und Anlage. Eine semantische Bewertung kann erkennen, ob beschriebene Arbeiten zum erwarteten Leistungstyp passen; sie ersetzt jedoch nicht den Fachabgleich. Fehlt die Anlage, widerspricht das Datum dem Auftrag oder ist die Beschreibung uneindeutig, landet nur dieser konkrete Prüfgrund bei der zuständigen Person. Nach deren Entscheidung schreibt die Schnittstelle den Status idempotent ins führende System und legt Prüfprotokoll sowie freigegebene Dokumentversion im DMS ab.

• Eingang: Original und technische Metadaten unverändert registrieren
• Extraktion: Kandidatenwerte samt Seite und Fundstelle erfassen
• Referenz: Auftrag und Anlage aus dem führenden System abrufen
• Prüfung: formale, semantische und fachliche Ergebnisse getrennt ausweisen
• Ausnahme: nur die konkrete Abweichung mit benötigtem Kontext vorlegen
• Übergabe: Entscheidung bestätigen, Dubletten verhindern und Protokoll verknüpfen

Menschliche Prüfung nach Wirkung und Unsicherheit steuern

Ein Konfidenzwert beschreibt die Sicherheit eines Modells innerhalb seiner technischen Bewertung. Er beschreibt nicht automatisch die Folgen einer falschen Freigabe. Eine schwer rückgängig zu machende Buchung, eine Zahlung oder die Ablehnung eines Nachweises benötigt daher strengere Kontrollen als eine interne Vorstrukturierung.

Für die Freigabematrix werden mindestens Prüfresultat, Datenart, mögliche Auswirkung, Umkehrbarkeit und Neuartigkeit des Falls kombiniert. Die Prüfoberfläche zeigt Originalausschnitt, erkannten Wert, Vergleichswert, verletzte Regel und vorgesehene Aktion nebeneinander. Menschen sollten nicht das gesamte Dokument erneut durchsuchen müssen, sondern die konkrete Abweichung entscheiden können.

• automatisch weiterführen: bekannte, folgenarme Fälle mit vollständig bestandenen Muss-Prüfungen
• gezielt vorlegen: unsichere Extraktion, fehlende Referenz, zulässige Toleranzüberschreitung oder neuer Dokumenttyp
• immer freigeben lassen: finanzielle, rechtliche oder sonst schwer umkehrbare Folgeschritte
• kontrolliert stoppen: beschädigte Dateien, unauflösbare Widersprüche oder fehlende Berechtigung

Ausnahmewege gehören in den Sollprozess

Produktive Dokumente sind selten so gleichförmig wie ein Demonstrationsdatensatz. Leere oder doppelte Seiten, nachgereichte Anlagen, handschriftliche Ergänzungen, mehrere Vorgänge in einer Datei, veraltete Formulare und widersprüchliche Dokumentversionen müssen als erwartbare Varianten behandelt werden.

Jede Ausnahme erhält einen verständlichen Grund, einen verantwortlichen Bearbeitungsweg und einen sicheren Wiederanlauf. Nach einer Korrektur wird nicht ungeprüft der gesamte Prozess wiederholt: Das System weiß, welche Prüfungen bereits gültig sind, welche Regel betroffen war und welche nachgelagerten Schritte erneut bestätigt werden müssen.

Qualität je Fehlerklasse testen und im Betrieb nachführen

Ein repräsentatives Testset enthält nicht nur häufige Standarddokumente, sondern bewusst Grenzfälle und kritische Abweichungen. Die erwarteten Ergebnisse werden von der zuständigen Fachseite festgelegt. Gemessen wird je Dokumentklasse und Prüfregel: Wurde ein Fehler erkannt, korrekt begründet, an die richtige Stelle geleitet und ohne unzulässige Systemaktion behandelt?

Im Betrieb verändern neue Vorlagen, Lieferanten, Scaneinstellungen, Fachregeln, Modelle oder Schnittstellen die Ergebnisqualität. Extraktionsmodell, Regelwerk, Referenzschema und Übergabelogik werden daher gemeinsam versioniert. Stichproben, Korrekturen, offene Ausnahmefälle und ungewöhnliche Veränderungen einzelner Fehlerklassen dienen als Freigabe- und Überwachungssignale.

• Erkennungs- und Prüfqualität getrennt je Dokumenttyp und Fehlerklasse
• falsch freigegebene Fälle mit ihrer möglichen Auswirkung
• korrekt eskalierte Abweichungen und unnötige Prüfvorlagen
• Bearbeitungszeit und Rückfragen je Ausnahmegrund
• Schnittstellenfehler, Dubletten und bestätigte Wiederanläufe
• Änderungen nach Regel-, Modell- oder Datenquellenversion

Den Abnahmedatensatz aus realen Varianten und kritischen Fehlern bauen

Ein Testbestand aus gut lesbaren Standarddokumenten belegt nur, dass der Normalfall funktioniert. Für eine belastbare Abnahme werden reale Eingangskanäle, Layoutfamilien, Seitenzahlen, Sprachen, Scanqualitäten und bekannte Sonderfälle zunächst inventarisiert. Seltene Fehler mit hoher Wirkung – etwa eine falsche Vorgangszuordnung oder eine übersehene Betragsabweichung – gehören gezielt in den Bestand, auch wenn sie im Tagesvolumen nur selten auftreten.

Entwicklungs-, Abnahme- und Regressionstest sollten getrennt bleiben. Das Entwicklungsteam darf mit dem ersten Bestand Regeln und Modelle verbessern. Die fachlich verantwortete Abnahme erfolgt anschließend auf zuvor nicht verwendeten Fällen mit festgelegtem Sollergebnis. Ein unveränderlicher Regressionstest prüft bei jeder neuen Modell-, Regel- oder Schnittstellenversion, ob bereits beherrschte Fälle weiterhin korrekt verarbeitet werden.

Das BSI ordnet im QUAIDAL-Katalog Qualitätskriterien systematisch Maßnahmen und überprüfbaren Metriken für Trainingsdaten im KI-Lebenszyklus zu. Für die Dokumentenprüfung ist das eine methodische Orientierung, kein pauschaler Konformitätsnachweis: Relevant sind immer der konkrete Dokumenttyp, die vorgesehene Folgeaktion und die Risiken einer falschen Entscheidung.

• Variantenmatrix: Eingangskanal, Dokumentklasse, Layout, Sprache, Seitenumfang und technische Qualität erfassen
• Goldstandard: erwartete Werte, Prüfgründe und Folgeaktionen fachlich festlegen und versionieren
• Risikofälle: seltene, aber folgenreiche Abweichungen bewusst höher gewichten
• Unbekannte Varianten: neue Vorlagen und unklare Dokumenttypen als eigenen Testbereich behandeln
• Datentrennung: Entwicklungsfälle nicht zugleich als unabhängigen Abnahmenachweis verwenden
• Regression: nach jeder relevanten Änderung dieselben kritischen Fälle erneut gegen die freigegebene Version prüfen

Die Abnahme muss Fehlfreigaben und Fehlalarme getrennt bewerten

Eine einzige Trefferquote reicht für die Abnahme nicht aus. Entscheidend ist, welche Fehlerart hinter einem falschen Ergebnis steckt. Eine unzulässige Freigabe kann wesentlich schwerer wiegen als ein korrektes Dokument, das unnötig zur Prüfung vorgelegt wird. Deshalb erhält jede Muss-Regel vor dem Pilotbetrieb ein fachlich beschlossenes Ziel und eine definierte Reaktion bei Nichterreichen.

Das Testset wird nach Dokumentklasse, Quelle, Layoutvariante und kritischer Fehlerart ausgewertet. Für jede Version von Modell, Regelwerk und Schnittstelle wird festgehalten, welche Fälle automatisch freigegeben, korrekt eskaliert, fälschlich freigegeben oder unnötig gestoppt wurden. Der KI-Prüfkatalog des Fraunhofer IAIS empfiehlt entsprechend, anwendungsspezifische Risiken zu bestimmen, messbare Ziele festzulegen, Maßnahmen über den Lebenszyklus zu dokumentieren und ihre Wirksamkeit nachvollziehbar zu begründen.

Die Freigabeentscheidung sollte daraus nicht nur einen Grenzwert, sondern einen zulässigen Betriebsbereich ableiten: bekannte Dokumentvarianten, verbindliche Datenquellen, erlaubte Folgeaktionen und ein getesteter Ausnahmeweg. Neue Vorlagen, geänderte Referenzfelder oder ein Modellwechsel verlassen diesen Bereich zunächst und werden gezielt geprüft, bevor sie automatisch weiterlaufen.

• kritische Fehlfreigaben je Regel und Dokumentklasse
• unnötige Prüfvorlagen und ihr Bearbeitungsgrund
• nicht auflösbare Fälle wegen fehlender oder veralteter Referenzdaten
• Schnittstellenfehler, Dubletten und falsch bestätigte Schreibvorgänge
• Ergebnisvergleich vor und nach Modell-, Regel- oder Schemaänderungen

Ein Freigabepaket macht die Automatisierungsgrenze überprüfbar

Am Ende der Abnahme steht nicht nur ein Testergebnis, sondern eine eindeutige Betriebsfreigabe. Sie benennt Dokumentklassen, zugelassene Eingangskanäle, verbindliche Referenzsysteme, erlaubte Folgeaktionen, Grenzwerte je kritischer Fehlerart und den getesteten Ausnahmeweg. So ist erkennbar, welche Fälle automatisch verarbeitet werden dürfen und wann zwingend ein Mensch übernimmt.

Zum Freigabepaket gehören außerdem die Versionen von Modell, Regelwerk, Prüfkatalog und Schnittstellenvertrag, der verwendete Abnahmedatensatz, die gemessenen Ergebnisse sowie verantwortliche Rollen. Eine Änderung an Vorlagen, Referenzfeldern, Berechtigungen oder Schreiblogik löst anhand dieser Basis eine gezielte Neubewertung aus, statt die Freigabe stillschweigend auf einen veränderten Prozess zu übertragen.

• Geltungsbereich mit Dokumentklassen, Varianten und ausdrücklich ausgeschlossenen Fällen
• Qualitätsziele je Fehlerklasse statt eines einzigen Gesamtscores
• zulässige Systemaktionen und erforderliche menschliche Freigaben
• bestätigter Ausnahme-, Wiederanlauf- und Rückfallprozess
• Versionen, Verantwortliche, Freigabedatum und Anlass für eine erneute Prüfung

Nachvollziehbarkeit am Dokument und am Anwendungsfall ausrichten

Die BSI-Richtlinie TR-03138 RESISCAN beschreibt Anforderungen an beweiswerterhaltendes ersetzendes Scannen, darunter Integrität, Nachvollziehbarkeit und dokumentierte Prozessschritte. Sie ist kein pauschaler Rechtsnachweis für jede Dokumentenautomatisierung. Ob Originale vernichtet werden dürfen oder besondere Formvorschriften gelten, muss für die konkrete Dokumentart separat geklärt werden.

Für steuerlich relevante Unterlagen verlangen die GoBD unter anderem Nachvollziehbarkeit, Vollständigkeit, Richtigkeit, zeitgerechte Erfassung, Ordnung und Unveränderbarkeit. Auch dieser Anwendungsbereich darf nicht ungeprüft auf sämtliche Unternehmensdokumente übertragen werden. Praktisch sinnvoll bleibt jedoch ein zusammenhängender Nachweis aus Eingang, Original oder führender Version, extrahierten Werten, Regel- und Referenzstand, menschlichen Änderungen und finaler Systemaktion.

Die DSK betont für KI-Systeme Datenschutz durch Technikgestaltung, Datenminimierung, Rollen und Berechtigungen sowie Prüfungen über den Lebenszyklus. Welche Rechtsgrundlage, Aufbewahrung, Löschung oder Datenschutz-Folgenabschätzung erforderlich ist, hängt vom konkreten Einsatz ab. Stand dieser fachlichen Einordnung ist der 6. September 2026; sie ersetzt keine Rechts- oder Steuerberatung.