Extraktion von Versicherungsdokumenten:
Was ein Tool abdecken muss

Vier Dokumentenfamilien, eine Extraktionslücke

Versicherungsunternehmen verarbeiten Dokumente aus vier verschiedenen Familien, jede mit unterschiedlichen Formaten, Quellen und nachgelagerten Systemen. Der häufigste Fehler von Betriebsteams bei der Bewertung von Extraktionstools ist, dass sie nur gegen eine Familie testen – meist Schadensformulare – und annehmen, das Tool würde die anderen drei ebenso gut verarbeiten.

Ein mittelgroßer P&C-Versicherer mit 50.000 laufenden Policen hat täglich mit Dokumenten aus allen vier Familien zu tun. Das Underwriting-Team prüft Anträge und Inspektionsberichte. Das Schadenteam bearbeitet Schadensmeldungen und beigefügte Nachweise. Das Compliance-Team verfolgt COIs von Auftragnehmern und Dienstleistern der Versicherungsnehmer. Das Finanzteam gleicht Prämienprüfungen und Bordereaux ab. Keine Abteilung besitzt die „Dokumentenextraktion“ – aber jede Abteilung hat denselben Engpass: Jemand überträgt Daten aus einem PDF in ein System, das sie strukturiert hätte empfangen können.

Deshalb führt die Bewertung eines Extraktionstools allein nach der Genauigkeit bei Schadensmeldungen zu einem irreführenden Ergebnis. Ein Tool, das bei ACORD-Schadensmeldungen 98 % erreicht, aber einen handschriftlichen Außendienstbericht oder eine mehrseitige Krankenakte des behandelnden Arztes nicht lesen kann, lässt drei der vier Dokumentenfamilien unberücksichtigt. Für einen umfassenderen Überblick über die Unterscheidungsmerkmale von Extraktionstools bietet unser Bewertungsrahmen eine Aufschlüsselung der branchenübergreifend relevanten Kriterien – in der Versicherungsbranche ist jedoch die Abdeckung der Dokumententypen das wichtigste Kriterium.

Warum ACORD-Formulare der einfache Teil der Versicherungsdatenextraktion sind

Die Association for Cooperative Operations Research and Development (ACORD) definiert die Datenstandards, die Versicherungstransaktionen weltweit zugrunde liegen. Ihre Formularbibliothek – ACORD 25 (Versicherungsbescheinigung), ACORD 125 (Antrag auf gewerbliche Versicherung), ACORD 130 (Antrag auf Arbeitsunfallversicherung), ACORD 140 (Sachversicherungsteil) – ist das, was der Versicherungsbranche am nächsten an einem universellen Dokumentenformat kommt.

ACORDs eigenes Produkt, ACORD Transcriber, kann Daten aus allen über 800 Formularen der Bibliothek extrahieren. Für Versicherer, die große Mengen standardisierter ACORD-Einreichungen verarbeiten, löst Transcriber ein echtes Problem: Es eliminiert die manuelle Neueingabe von Anträgen, Schadenmeldungen und Bescheinigungen, die im ACORD-Format eingehen. Enterprise-IDP-Plattformen wie ABBYY Vantage bieten ähnliche ACORD-spezifische Extraktionsfähigkeiten.

Die Lücke zeigt sich, sobald ein Dokument eingeht, das keine ACORD-Formularnummer hat.

Bei einem typischen Sach- oder Haftpflichtschaden ist das ACORD-Schadenformular (Formular 1) nur eines von fünf bis fünfzehn Dokumenten in der Akte: ein Polizeibericht der örtlichen Polizei (kein Standardformat), ein Reparaturkostenvoranschlag eines unabhängigen Sachverständigen (formatiert durch dessen Schadenssoftware – Xactimate, Symbility oder eine Word-Vorlage), medizinische Unterlagen des Leistungsanbieters des Geschädigten (formatiert durch das Krankenhaus-KIS – Epic, Cerner, Athenahealth – jedes mit einem anderen PDF-Layout), Schadensfotos und Korrespondenz des Anwalts des Geschädigten. Keines dieser Dokumente ist ein ACORD-Formular. Alle enthalten Daten, die der Sachbearbeiter in ClaimCenter oder das Schadenmanagementsystem eingeben muss, bevor der Schaden weiterbearbeitet werden kann.

Diese Frage unterscheidet Werkzeuge, die für die Verarbeitung von Versicherungsdokumenten konzipiert sind, von solchen, die das Problem tatsächlich lösen. Ein vorlagenbasierter Extraktor benötigt eine vorkonfigurierte Vorlage für jedes Dokumentenformat, das ihm begegnet. In der Versicherung, wo derselbe Dokumententyp (ein medizinischer Bericht, ein Kostenvoranschlag, ein Polizeibericht) von jeder Quelle in einem anderen Format eingeht, schafft die vorlagenbasierte Extraktion einen Wartungsaufwand, der die manuelle Dateneingabe, die sie ersetzen sollte, übertreffen kann. Für einen tieferen Vergleich dieser Ansätze siehe Document AI vs. IDP vs. OCR.

Der Engpass vor dem Kernsystem: Extraktion vor Guidewire, nicht als Ersatz

Versicherer, die Guidewire, Duck Creek, Majesco oder OneShield einsetzen, verfügen bereits über Systeme, die den Lebenszyklus eines Vertrags oder Schadensfalls verwalten, sobald die Daten im System sind. Guidewire ClaimCenter steuert Zuweisung, Untersuchung, Bewertung, Verhandlung und Abwicklung. Duck Creek Policy verwaltet Tarifierung, Ausstellung, Nachträge und Verlängerungen. Diese Plattformen sind keine Dokumentextraktions-Tools – sie sind Workflow- und Datenverwaltungssysteme, die davon ausgehen, dass strukturierte Daten an ihrer Schnittstelle eingehen.

Der Engpass liegt nicht im Kernsystem. Er liegt davor. Ein Schadenssachbearbeiter erhält eine E-Mail mit drei PDF-Anhängen – einer Schadenmeldung, einem Polizeibericht und einer Arztrechnung. Die Daten der Schadenmeldung müssen in die FNOL-Felder von ClaimCenter eingegeben werden. Der Polizeibericht enthält den Schadenshergang, den einschreitenden Beamten und das Aktenzeichen. Die Arztrechnung enthält den Leistungserbringer, die Kosten, Diagnosecodes und Behandlungsdaten. Der Sachbearbeiter öffnet jedes PDF, liest jedes Feld und tippt die Werte in ClaimCenter – Feld für Feld, drei Dokumente nacheinander, für jeden neuen Schadensfall.

Die Dokumentextraktion schließt diese Lücke. Sie liest die drei PDFs, bevor der Sachbearbeiter es tut, extrahiert die Felder in ein strukturiertes Format (Excel, CSV oder JSON) und übergibt dem Sachbearbeiter einen prüfbaren Datensatz statt drei zu transkribierender Dokumente. Die Daten gelangen weiterhin in Guidewire oder Duck Creek. Der Sachbearbeiter prüft sie weiterhin. Der Unterschied liegt darin, ob er 15 Minuten mit Tippen oder 90 Sekunden mit Prüfen verbringt.

Diese Positionierung ist wichtig bei der Bewertung von Tools. Ein Extraktionstool, das für die Funktion eine Guidewire-Integration benötigt, löst ein anderes Problem (und verlangt Enterprise-Preise dafür). Ein Tool, das strukturierte Daten ausgibt – Excel, CSV, JSON – funktioniert mit jedem Kernsystem, denn jedes Kernsystem kann strukturierte Daten importieren. Die Frage lautet nicht „Integriert das mit Guidewire?“, sondern „Liefert das saubere Daten, die mein Team prüfen und in jedem von meinen Systemen akzeptierten Format importieren kann?“. Mehr zu dieser Architekturentscheidung finden Sie unter API vs. codefreie Dokumentenextraktion.

Schadensdokumente: Formatvielfalt innerhalb einer einzigen Schadensakte

Ein einzelner Kfz-Versicherungsfall kann acht bis zwölf Dokumente aus sechs verschiedenen Quellen generieren. Der Versicherungsnehmer reicht Fotos und eine schriftliche Beschreibung ein. Die zuständige Polizeidienststelle erstellt einen Bericht. Die Werkstatt sendet einen Kostenvoranschlag. Der medizinische Leistungserbringer des Geschädigten übermittelt Behandlungsunterlagen und Rechnungen. Der eigene Sachbearbeiter des Versicherers verfasst einen Außenbesichtigungsbericht. Ein Anwalt, falls beteiligt, sendet ein Aufforderungsschreiben.

Jedes dieser Dokumente beantwortet eine Version derselben drei Fragen: Was ist passiert, wann und wie viel? Aber jedes kodiert diese Antworten in einem anderen Format. Der Polizeibericht setzt das Schadensdatum in ein Kopfzeilenfeld mit der Bezeichnung „Datum des Vorfalls“. Die Arztrechnung setzt das Leistungsdatum in eine Tabellenspalte mit der Bezeichnung „DOS“. Der Reparaturkostenvoranschlag setzt das Datum der Schadensbewertung in eine Fußzeile. Ein vorlagenbasierter Extraktor benötigt für jedes eine separate Vorlage – und eine neue Vorlage, sobald eine Werkstatt ihre Kalkulationssoftware wechselt oder ein Krankenhaus sein Abrechnungssystem aktualisiert.

Der Extraktionsansatz, der diese Vielfalt ohne formatspezifische Vorlagen bewältigt, ist die semantische Extraktion: Anstatt Feldkoordinaten auf einem bekannten Formular abzubilden, liest die KI das Dokument und lokalisiert Felder anhand ihrer Bedeutung. Sie definieren die benötigten Spalten – „Schadensdatum“, „Name des Geschädigten“, „Gesamtforderungsbetrag“, „Diagnoseschlüssel“, „Reparaturkostenvoranschlag Gesamt“ – und die KI findet die passenden Werte, unabhängig davon, wo sie auf der Seite stehen oder welche Bezeichnung das Quelldokument verwendet. ImageToTable.ai nennt dies Benutzerdefinierte Spaltenextraktion: Sie geben Ihre Spaltennamen ein, und die KI lokalisiert die entsprechenden Daten, indem sie versteht, was jedes Feld bedeutet, nicht indem sie sich merkt, wo es normalerweise erscheint. Dieselben Spaltendefinitionen verarbeiten einen Polizeibericht, eine Arztrechnung und einen Reparaturkostenvoranschlag in einem einzigen Durchlauf.

Für Schadensabteilungen, die monatlich hunderte Fälle bearbeiten, ist der praktische Nutzen messbar. Branchendaten von Inovalon beziffern die manuelle Schadensbearbeitung auf durchschnittlich 70 Minuten pro Fall, wobei die Arbeitskosten bis zu 90 % der Kosten von 10–40 $ pro Fall ausmachen. Die Extraktion ersetzt nicht die Prüfung durch den Sachbearbeiter – komplexe Fälle erfordern weiterhin menschliches Urteilsvermögen bei Deckung, Haftung und Rückstellungsbildung. Was sie ersetzt, ist der Schritt der Übertragung: die 20–30 Minuten pro Fall, die für das Lesen von PDFs und das Eintippen von Werten in Felder aufgewendet werden, die eine Maschine in Sekunden hätte befüllen können.

COIs und Compliance-Dokumente: Das Problem der empfangenen Zertifikate

Versicherungsgesellschaften stellen COIs aus. Sie erhalten sie aber auch – von Versicherungsnehmern, die nachweisen müssen, dass ihre Auftragnehmer, Dienstleister oder Mieter über ausreichenden Versicherungsschutz verfügen. Ein gewerblicher Sachversicherer, der 5.000 Policen verwaltet, könnte pro Jahr mehrere tausend COIs von Versicherungsnehmern erhalten, die belegen, dass ihre Bauunternehmer, Reinigungsdienste und Wartungsdienstleister versichert sind. Jede COI muss geprüft werden: Entspricht die Deckungsart den vertraglichen Anforderungen? Ist die Deckungssumme ausreichend? Ist die Police abgelaufen? Ist die versicherte Partei als zusätzlich versichert aufgeführt?

Das International Risk Management Institute (IRMI) hat dokumentiert, dass über 90 % der COI-Zertifikate wesentliche Abweichungen von den vertraglichen Anforderungen aufweisen, die sie erfüllen sollen. Das Problem ist nicht, dass COIs schwer zu lesen sind – die meisten sind ACORD-25-Formulare mit vorhersehbaren Feldern. Das Problem sind die Menge und die Geschwindigkeit der Überprüfung. Ein Compliance-Analyst, der 5 Minuten pro COI damit verbringt, Policennummer, Versicherer, Deckungsarten, Limits, Beginn, Ablauf und Status der zusätzlich versicherten Partei manuell in eine Tracking-Tabelle einzutragen, hat keine Zeit mehr, um zu prüfen, ob die angegebenen Limits tatsächlich die Mindestanforderungen des Vertrags erfüllen.

Die Extraktion verändert diese Mathematik. Wenn die neun Schlüsselfelder einer COI in Sekunden extrahiert statt in 5 Minuten abgetippt werden, wandelt sich die Rolle des Analysten von der Dateneingabe zur Compliance-Prüfung – Überprüfung der Deckungssprache, Prüfung der Deckungsangemessenheit und Markierung von Ablaufdaten, die vor dem nächsten Vertragsmeilenstein liegen. Die Extraktion verifiziert die Police selbst nicht (kein Extraktionstool kann das System des Versicherers anrufen, um zu bestätigen, dass eine Police in Kraft ist), aber sie erstellt die strukturierten Daten, die eine Verifizierung in großem Maßstab ermöglichen.

Das obige Demo verwendet ein COI-Preset – Spalten wie „Police-Nummer", „Versicherer", „Deckungsart", „Höchstbetrag pro Schadensfall", „Gesamthöchstbetrag", „Beginn", „Ablauf", „Zusätzlicher Versicherter J/N". Derselbe spaltenbasierte Mechanismus verarbeitet jedes COI-Format – ACORD 25 eines nationalen Versicherers, eine Briefkopfbescheinigung eines regionalen Agenten oder eine von einem Makler ausgestellte Zusammenfassung mit nicht standardmäßigem Layout. Eine detaillierte Anleitung zu COI-Extraktionsworkflows finden Sie in unserem Leitfaden zur COI-zu-Excel-Extraktion.

Krankenakten und Nachweise: Die Herausforderung unstrukturierter Dokumente

Bei Personenschäden, Arbeitsunfällen und Erwerbsunfähigkeitsansprüchen bilden Krankenakten die Beweisgrundlage. Ein Sachbearbeiter, der einen Arbeitsunfall prüft, muss Behandlungsdaten, Diagnosen (oft als ICD-10-Codes), den behandelnden Arzt, die Einrichtung, durchgeführte Prozeduren (CPT-Codes) und Kosten extrahieren – aus Unterlagen, die in dem Format eingehen, das die jeweilige Praxissoftware ausgibt.

Die Akte eines einzigen Klägers kann Unterlagen eines Hausarztes (Epic-PDF), eines Orthopäden (Cerner-PDF), einer Physiotherapiepraxis (Word-Dokument oder handschriftliche Notizen) und eines unabhängigen Gutachters (getippter Bericht) enthalten. Jede Quelle liefert ein Dokument mit unterschiedlichen Feldnamen an unterschiedlichen Stellen. „Behandlungsdatum" kann in vier Dokumenten von vier Anbietern als „DOS", „Leistungsdatum", „Besuchsdatum" oder „Kontaktdatum" erscheinen.

Hier bietet die semantische Extraktion einen strukturellen Vorteil gegenüber vorlagenbasierten Tools. Wenn Sie eine Spalte als „Behandlungsdatum" definieren, erkennt die KI, dass „DOS", „Leistungsdatum", „Besuchsdatum" und „Kontaktdatum" dasselbe Konzept bezeichnen – und extrahiert das korrekte Datum aus jedem Dokument, unabhängig von der verwendeten Bezeichnung. Gleiches gilt für „Gesamtkosten", „Diagnose" und „Arztname". Ein einziger Satz Spaltendefinitionen verarbeitet Unterlagen mehrerer Anbieter in einem Durchgang und erstellt eine konsolidierte medizinische Chronologie, die der Sachbearbeiter prüfen kann, anstatt sie selbst zusammenzustellen.

Diese konsolidierte Ansicht erstellen Schadensprüfer normalerweise manuell – eine Tabelle mit jedem Behandlungsdatum, Leistungserbringer, Diagnose, Prozedur und jeder Gebühr aus der gesamten Krankengeschichte des Antragstellers. Die manuelle Erstellung aus 15–20 Seiten Krankenakten dauert 30–60 Minuten pro Schadensfall. Die Extraktion reduziert dies auf einen Prüfschritt: die extrahierte Tabelle auf Richtigkeit prüfen, etwaige Fehlerlesungen korrigieren und zur Bewertung übergehen. Weitere Informationen zur Handhabung verschiedener Formate medizinischer Dokumente durch KI finden Sie in unserer Extraktion medizinischer Rechnungen und für einen Vergleich aus Sicht des Leistungserbringers deckt der Käuferleitfaden zur Extraktion von Gesundheitsdokumenten die EHR-Erfassung und EOB-Abstimmung aus klinischer Betriebssicht ab.

Bewertungsrahmen: Sieben Fragen vor dem Kauf

Wenn Sie Dokumentextraktions-Tools für einen Versicherungsbetrieb evaluieren – sei es ein Sachversicherer, ein MGA, ein TPA oder ein Rückversicherer –, werden die folgenden sieben Fragen mehr über die tatsächliche Eignung verraten als jede Demo eines Anbieters mit einem kuratierten Datensatz.

Eine detailliertere Aufschlüsselung der Build-vs.-Buy-Überlegungen und wann ein unternehmensweites IDP gegenüber einem leichteren Tool sinnvoll ist, finden Sie unter Build vs. Buy für die Dokumentextraktion und Enterprise- vs. SMB-Extraktionsfunktionen.

Was Extraktion in der Versicherung nicht ersetzt

Dokumentenextraktion ist keine Schadenautomatisierung. Sie ist keine Betrugserkennung. Sie ist keine Entscheidungsfindung. Diese Begriffe werden im Marketing von Anbietern häufig vermischt, was zu falschen Erwartungen führt.

Extraktion erfasst Daten aus Dokumenten. Sie trifft keine Deckungsentscheidungen, legt keine Rückstellungen fest, erkennt keine inszenierten Unfälle und prüft nicht, ob eine im COI angegebene Police tatsächlich beim Versicherer in Kraft ist. Diese Funktionen erfordern Schadenmanagementsysteme (Guidewire ClaimCenter, Duck Creek Claims), Betrugserkennungsplattformen (Shift Technology, FRISS) bzw. Verifizierungsdienste (myCOI, Jones, TrustLayer zur COI-Prüfung).

Der Wert der Extraktion in der Versicherung ist spezifisch und begrenzt: Sie eliminiert den manuellen Übertragungsschritt zwischen Dokumenteneingang und Systemerfassung. Für einen mittelgroßen Versicherer, der 500 Schäden pro Monat mit durchschnittlich 5 Dokumenten pro Schaden bearbeitet, sind das 2.500 Dokumente – jedes erfordert 3-5 Minuten manuelle Dateneingabe. Bei durchschnittlich 4 Minuten entspricht das etwa 167 Arbeitsstunden pro Monat, die für das Abtippen von Daten aufgewendet werden, die bereits auf Papier oder in PDFs vorliegen. Extraktion reduziert den Großteil dieser Zeit auf einen Prüfschritt, der pro Dokument in Sekunden statt Minuten gemessen wird.

Was die Extraktion schafft, ist Spielraum. Wenn der Sachbearbeiter nicht 20 Minuten pro Schadensfall für die Dateneingabe aufwendet, kann er diese Zeit für die Arbeit nutzen, die menschliches Urteilsvermögen erfordert: Prüfung der Deckungsanwendbarkeit, Bewertung der Haftung, Verhandlung von Vergleichen und Erkennung von Warnsignalen, die Betrugserkennungsalgorithmen übersehen könnten. Die Forrester-Studie zur Versicherungstechnologie ergab, dass 91 % der Versicherungsunternehmen bis Ende 2026 KI-gestützte Schadensautomatisierung im Produktivbetrieb einsetzen werden – die ausgereifteste und am weitesten verbreitete Fähigkeit innerhalb dieser Automatisierung ist jedoch die Dokumentenextraktion und Datenerfassung, nicht die durchgängige End-to-End-Verarbeitung.

FAQ