Eine Schadenmeldung ist selten ein sauberes Dokument. Sie ist ein Bündel: ein teilweise ausgefülltes Formular, drei Handyfotos vom Schadenbild, eine handschriftliche Ergänzung am Seitenrand, ein weitergeleiteter E-Mail-Verlauf mit Anhängen und eine Rechnung, die jemand schräg eingescannt hat. Wer diesen Eingang automatisieren will, stellt schnell fest: Texterkennung allein löst das Problem nicht.
Dieser Beitrag beschreibt, wie sich Schadenmeldungen strukturiert erfassen lassen, ohne die Kontrolle über den Vorgang abzugeben — und warum der Konfidenzwert pro Feld dabei die entscheidende Steuerungsgröße ist. Nicht als Kennzahl für die Außendarstellung, sondern als Schalter im Prozess.
Der Weg einer Schadenmeldung durch den Posteingang
Bevor über Automatisierung gesprochen wird, lohnt der nüchterne Blick auf das Material. In der Praxis kommen Schadenmeldungen über vier Kanäle, die sich technisch grundlegend unterscheiden — auch wenn am Ende ein einziger Vorgang daraus werden soll.
Das strukturierte Formular
Der freundlichste Fall: ein bekanntes Schadenanzeigeformular, ausgefüllt und eingescannt. Vertragsnummer, Schadendatum, Schadenart stehen dort, wo sie erwartet werden. Aber schon hier gilt: ausgefüllt heißt oft handschriftlich ausgefüllt, angekreuzt heißt manchmal durchgestrichen und daneben kommentiert.
Fotos vom Schadenbild
Aufgenommen mit dem Smartphone, schräg, mit Reflexionen, teils bei schlechtem Licht. Häufig sind darin Dokumente abfotografiert statt gescannt: das Kennzeichen, ein Kostenvoranschlag, eine Quittung auf dem Küchentisch. Perspektivische Verzerrung und ungleichmäßige Ausleuchtung sind hier der Normalfall, nicht die Ausnahme.
Handschrift
Der Schadenhergang wird selten in Blockbuchstaben geschrieben. Ergänzungen stehen am Rand, Korrekturen sind überschrieben, Zahlen und Buchstaben vermischen sich. Handschrift ist im Schadeneingang kein Randfall, sondern regelmäßig genau der Teil, der die fachlich wichtigste Information trägt.
Der E-Mail-Anhang
Ein PDF mit 14 Seiten, in dem eine Schadenanzeige, zwei Rechnungen, ein Lichtbild und ein Behördenschreiben zusammengefasst sind. Häufig weitergeleitet, mehrfach ausgedruckt und wieder eingescannt, in beliebiger Reihenfolge.
Warum reine OCR im Schadenprozess scheitert
Klassische Texterkennung liefert eine Zeichenkette. Für den Schadenprozess ist das zu wenig — aus vier Gründen.
1. Handschrift ist nicht der Sonderfall
Systeme, die auf gedruckten Text optimiert sind, brechen bei handschriftlichen Passagen ein oder liefern still falsche Zeichen. Still falsch ist dabei das eigentliche Problem: Ohne eine Aussage darüber, wie sicher die Erkennung war, sieht ein falscher Wert genauso aus wie ein richtiger.
2. Freitextfelder tragen die Fachinformation
“Beim Rückwärtsausparken gegen den Poller, Stoßfänger hinten links” ist kein Feldwert, sondern ein Sachverhalt. Daraus müssen Schadenart, betroffenes Bauteil und ein möglicher Hinweis auf Fremdverschulden abgeleitet werden. Zeichenerkennung leistet das nicht; dafür braucht es eine semantische Einordnung des erkannten Textes.
3. Der Anlagen-Mix
Ein eingehendes PDF ist kein Dokument, sondern ein Stapel. Bevor extrahiert werden kann, muss getrennt und klassifiziert werden: Wo endet die Schadenanzeige, wo beginnt die Werkstattrechnung, welche Seite ist nur ein Deckblatt? Wird dieser Schritt übersprungen, landen Beträge aus dem Kostenvoranschlag in Feldern, die eigentlich zur Anzeige gehören.
4. Volltext ist kein Vorgang
Das Schadensystem nimmt keinen Fließtext entgegen. Es erwartet Felder: Versicherungsscheinnummer, Schadendatum, Schadenort, Meldeweg, Bankverbindung, Schadenhöhe. Solange die Verarbeitung bei einer Textseite endet, ist die eigentliche Arbeit — das Übertragen in Felder — nur verschoben, nicht erledigt.
Feldbasierte Extraktion statt Volltext
Der tragfähige Ansatz ist ein anderer: Das Dokument wird klassifiziert, anschließend werden gezielt die fachlich definierten Felder extrahiert — jedes mit einem eigenen Konfidenzwert und einer Fundstelle im Original.
Eine Ausgabe sieht dann strukturell so aus (Werte exemplarisch, rein zur Illustration des Formats):
{
"dokumenttyp": "schadenanzeige",
"modellstand": "gocr-schaden-2026-07",
"felder": {
"versicherungsscheinnummer": {
"wert": "KH-4471-8823", "konfidenz": 0.99, "seite": 1, "quelle": "druck"
},
"schadendatum": {
"wert": "2026-07-14", "konfidenz": 0.97, "seite": 1, "quelle": "handschrift"
},
"schadenort": {
"wert": "Frankfurt am Main", "konfidenz": 0.88, "seite": 1, "quelle": "handschrift"
},
"schadenhergang": {
"wert": "Beim Rueckwaertsausparken gegen Poller",
"konfidenz": 0.64, "seite": 2, "quelle": "handschrift"
},
"iban": {
"wert": "DE00000000000000000000", "konfidenz": 0.93, "seite": 3, "quelle": "druck"
}
},
"anlagen": [
{ "seiten": "4-6", "typ": "kostenvoranschlag" },
{ "seiten": "7", "typ": "lichtbild" }
]
}Entscheidend ist nicht die Feldliste — die ist bei jedem Haus anders und wird fachlich definiert. Entscheidend ist, dass jedes Feld drei Dinge mitbringt: einen Wert, eine Sicherheitsangabe und einen Verweis auf die Stelle im Originaldokument.
Der Konfidenzwert als Steuerungsgröße
Ein Konfidenzwert ist die Aussage des Modells darüber, wie sicher es sich bei genau diesem Feld in genau diesem Dokument ist. Er ist keine Garantie und kein Qualitätsversprechen — und er sollte auch nicht als solches verkauft werden. Sein Wert liegt woanders: Er macht Unsicherheit sichtbar, bevor sie im Schadensystem landet.
Damit lässt sich der Eingang in Zonen aufteilen:
| Zone | Verhalten im Prozess | Was die Sachbearbeitung sieht |
|---|---|---|
| Sicher | Feld wird ohne Eingriff übernommen, Vorgang läuft dunkel weiter | Nichts — der Fall taucht nicht in der Arbeitsliste auf |
| Unsicher | Feld wird vorbelegt, aber als Prüfvorschlag markiert | Vorgeschlagener Wert neben dem Bildausschnitt aus dem Original, Bestätigung mit einem Klick |
| Nicht verwertbar | Feld bleibt leer, kein Wert wird übernommen | Der Bildausschnitt zur manuellen Erfassung, ohne irreführende Vorbelegung |
Der wichtigste Punkt steht in der letzten Zeile: Ein Modell, das bei Unsicherheit lieber nichts liefert als einen plausibel aussehenden Fehlwert, spart der Sachbearbeitung mehr Zeit als eines, das immer etwas ausgibt. Falsche Vorbelegungen kosten mehr Prüfaufwand als leere Felder.
Schwellen sind eine fachliche Entscheidung
Es gibt keinen sinnvollen Produktdefault für alle Felder. Eine Bankverbindung, an der eine Auszahlung hängt, verträgt eine andere Schwelle als ein Freitextfeld, das ohnehin gelesen wird. Deshalb werden Schwellen je Feld gesetzt und am eigenen Bestand kalibriert:
SCHWELLEN = {
"versicherungsscheinnummer": 0.98,
"schadendatum": 0.97,
"iban": 0.99,
"schadenort": 0.90,
"schadenhergang": 0.80,
}
def routing(feld: str, ergebnis: dict) -> str:
schwelle = SCHWELLEN.get(feld, 0.95)
konfidenz = ergebnis["konfidenz"]
# Konfidenz UND fachliche Plausibilitaet muessen stimmen
if konfidenz >= schwelle and plausibel(feld, ergebnis["wert"]):
return "automatisch"
if konfidenz >= schwelle - 0.15:
return "pruefvorschlag"
return "manuell"Die zweite Bedingung ist mindestens so wichtig wie die erste. Ein Modell kann sich sehr sicher sein und trotzdem fachlich falsch liegen. Deshalb greifen zusätzlich die Regeln, die Ihr Haus ohnehin kennt: IBAN-Prüfziffer, Vertragsnummer gegen den Bestand, Schadendatum nicht vor Versicherungsbeginn und nicht in der Zukunft, Schadenort im Deckungsgebiet. Konfidenz und Plausibilität sind zwei unabhängige Filter — erst gemeinsam tragen sie eine Dunkelverarbeitung.
Dunkelverarbeitung heißt nicht Blackbox
Der häufigste Einwand gegen Automatisierung im Schadeneingang lautet: “Dann wissen wir nicht mehr, warum etwas so im System steht.” Der Einwand ist berechtigt — aber er richtet sich gegen eine bestimmte Bauart, nicht gegen Automatisierung an sich.
Ein dunkel verarbeiteter Fall bleibt nachvollziehbar, wenn zu jedem übernommenen Feld dokumentiert ist, woher der Wert stammt: Seite, Position im Dokument, Konfidenz, angewandte Schwelle und der Modellstand, der die Erkennung geliefert hat. In der Prüfmaske bedeutet das ganz praktisch, dass neben jedem Feld der Bildausschnitt aus dem Original steht. Die Sachbearbeitung prüft dann nicht abstrakt einen Wert, sondern vergleicht ihn mit dem, was tatsächlich auf dem Papier steht.
Wer das ernst meint, braucht ein Modell, dessen Stand er kennt und selbst versioniert. Ein Dienst, der im Hintergrund still aktualisiert wird, liefert für denselben Beleg heute ein anderes Ergebnis als vor drei Monaten — und niemand kann später erklären, warum. Genau das ist der praktische Grund, Modell und Verarbeitung im eigenen Haus zu betreiben.
Vier-Augen-Prinzip an den richtigen Stellen
Nicht jeder Vorgang braucht eine zweite Person. Aber einige brauchen sie zwingend, und das System sollte diese Fälle erzwingen statt empfehlen. Typische Auslöser, die jedes Haus für sich festlegt:
- Zahlungsrelevante Änderungen: eine von den Vertragsstammdaten abweichende Bankverbindung in der Schadenmeldung
- Betragsgrenzen: Schadenhöhen oberhalb einer definierten Schwelle
- Auffälligkeitsmuster: Konstellationen, die Ihre Betrugsabwehr als prüfwürdig definiert hat
- Korrigierte Automatikfelder: Fälle, in denen jemand einen automatisch übernommenen Wert nachträglich ändert
Zwei Details entscheiden über die Wirksamkeit. Erstens: Die zweite Person muss den Originalausschnitt sehen, nicht nur den bereits übernommenen Wert — sonst bestätigt sie eine Übertragung, die sie gar nicht prüfen kann. Zweitens: Erfassung und Freigabe müssen technisch getrennt und protokolliert sein. Ein Vier-Augen-Prinzip, das dieselbe Kennung zweimal akzeptiert, ist eine Prozessbeschreibung, keine Kontrolle.
Auditierbarkeit: Was protokolliert werden sollte
Automatisierte Erfassung wird früher oder später Gegenstand einer internen Revision, einer Prüfung durch die Innenrevision oder einer Nachfrage aus dem Beschwerdemanagement. Dann zählt, was mitgeschrieben wurde. Sinnvoll ist ein Protokolleintrag je Vorgang mit mindestens:
- Referenz und Prüfsumme des verarbeiteten Dokuments
- Zeitpunkt der Verarbeitung
- Modell- und Adapterstand, mit dem extrahiert wurde
- alle Felder mit Wert, Konfidenz und Fundstelle
- die zum Zeitpunkt gültigen Schwellen und Plausibilitätsregeln
- die Routing-Entscheidung je Feld: automatisch, Prüfvorschlag, manuell
- jede manuelle Änderung mit altem und neuem Wert sowie Bearbeiterkennung
- Freigabe und — wo einschlägig — die zweite Freigabe
Der oft vergessene Punkt ist der Modellstand. Ohne ihn lässt sich ein zwei Jahre alter Vorgang nicht mehr reproduzieren, weil niemand weiß, welche Version welches Ergebnis erzeugt hat. Mit ihm ist die Frage “Warum stand hier dieser Wert?” beantwortbar.
Übergabe ins Schadensystem
Die extrahierten Daten sind kein Selbstzweck. Sie müssen in das Bestands- und Schadensystem, in die Dokumentenablage und je nach Haus in die Betrugsabwehr. Dafür sind offene Exportformate — JSON, CSV, XML — die pragmatische Grundlage: Sie lassen sich ohne Anbieterwerkzeug lesen, in bestehende Schnittstellen einbinden und im Zweifel auch dann noch auswerten, wenn die Verarbeitungsstrecke längst ersetzt wurde.
Ein Hinweis aus der Praxis: Geben Sie die Konfidenzwerte mit in das Zielsystem, nicht nur in die Prüfmaske. Sie sind später die einzige Grundlage, um auszuwerten, welche Felder tatsächlich dunkel liefen, wo die Ausnahmen entstehen und an welcher Stelle sich eine Nachschärfung lohnt.
Warum der Betrieb im eigenen Haus dazugehört
Schadenakten enthalten regelmäßig genau die Daten, bei denen Versicherer keinen Interpretationsspielraum haben: Namen, Adressen, Bankverbindungen, oft auch Gesundheitsangaben aus Attesten und Rechnungen. Eine Verarbeitungsstrecke, die diese Dokumente an einen externen Dienst gibt, verlagert die Kontrolle über den Datenfluss — unabhängig davon, wie gut die Vertragslage ist.
German-OCR ist für den umgekehrten Weg gebaut: ein eigenes lokales Modell, das on-premise in Ihrem Rechenzentrum läuft, Handschrift ebenso verarbeitet wie gedruckte Vorlagen und Fotos, pro Feld einen Konfidenzwert ausgibt und die Ergebnisse in offenen Formaten übergibt. Entwickelt und betrieben in Deutschland, mit einem Modellstand, den Sie kennen und versionieren. Warum das aus Datenschutz- und Aufsichtssicht mehr als eine Betriebsfrage ist, behandelt der Folgebeitrag zu Gesundheitsdaten in der Schadenakte.
Fazit
Automatisierte Schadenerfassung scheitert selten an der Texterkennung. Sie scheitert daran, dass ein System Werte liefert, ohne zu sagen, wie sicher es sich ist — und dass niemand später rekonstruieren kann, wie ein Wert zustande kam. Feldbasierte Extraktion mit Konfidenzwert pro Feld dreht das um: Sichere Fälle laufen ohne Eingriff durch, unsichere gehen gezielt und mit Bildausschnitt in die Sachbearbeitung, zahlungsrelevante Entscheidungen bleiben im Vier-Augen-Prinzip, und jeder Schritt ist protokolliert. Dunkelverarbeitung und Nachvollziehbarkeit sind kein Widerspruch — sie sind dieselbe Architekturentscheidung.
Schadeneingang gemeinsam durchsprechen — Kontakt auf german-ocr.de