Extraktion von Versicherungsdokumenten:
Was ein Tool abdecken muss

Vier Dokumentfamilien, eine Extraktionslücke

Versicherungsunternehmen verarbeiten Dokumente aus vier verschiedenen Familien, jeweils mit unterschiedlichen Formaten, unterschiedlichen Quellen und unterschiedlichen nachgelagerten Systemen. Der Fehler, den die meisten Betriebsteams bei der Bewertung von Extraktionstools machen, ist das Testen gegen eine Familie – normalerweise Schadensformulare – und die Annahme, dass das Tool die anderen drei bewältigt.

Ein mittelgroßer Sach-/Haftpflichtversicherer mit 50.000 laufenden Policen verarbeitet täglich Dokumente aus allen vier Familien. Das Underwriting-Team prüft Anträge und Inspektionsberichte. Das Schadenteam verarbeitet Schadenmeldungen und beigefügte Beweise. Das Compliance-Team verfolgt COIs von Auftragnehmern und Lieferanten der Versicherungsnehmer. Das Finanzteam gleicht Prämienprüfungen und Bordereaux ab. Keine Abteilung besitzt „Dokumentextraktion“ – aber jede Abteilung hat denselben Engpass: Jemand tippt Daten aus einem PDF in ein System, das sie strukturiert hätte empfangen können.

Deshalb führt die Bewertung eines Extraktionstools allein anhand der Schadensgenauigkeit zu einem irreführenden Ergebnis. Ein Tool, das bei ACORD-Schadenmeldungen 98 % erreicht, aber einen handschriftlichen Feldbericht eines Gutachters oder eine mehrseitige Krankenakte des behandelnden Arztes eines Anspruchstellers nicht lesen kann, lässt drei der vier Dokumentfamilien unberücksichtigt. Für einen breiteren Überblick darüber, was Extraktionstools unterscheidet, erläutert unser Bewertungsrahmen die Kriterien, die branchenübergreifend zählen – aber in der Versicherungsbranche ist das wichtigste Kriterium die Abdeckung des Dokumenttyps.

Warum ACORD-Formulare die einfache Hälfte der Versicherungsdatenextraktion sind

Die Association for Cooperative Operations Research and Development (ACORD) definiert die Datenstandards, die Versicherungstransaktionen weltweit zugrunde liegen. Ihre Formularbibliothek – ACORD 25 (Versicherungszertifikat), ACORD 125 (Antrag auf gewerbliche Versicherung), ACORD 130 (Antrag auf Arbeiterunfallversicherung), ACORD 140 (Sachversicherungsabschnitt) – ist das, was der Versicherungsbranche am nächsten an ein universelles Dokumentformat kommt.

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

Die Lücke entsteht in dem Moment, in dem ein Dokument eintrifft, das keine ACORD-Formularnummer hat.

In einem typischen Sach- und Haftpflichtschadenfall ist die ACORD-Schadenmeldung (Formular 1) ein Dokument in einer Akte, die fünf bis fünfzehn weitere enthalten kann: ein Polizeibericht der örtlichen Polizeidienststelle (kein Standardformat), ein Reparaturkostenvoranschlag eines unabhängigen Sachverständigen (formatiert durch die von ihnen verwendete Schadenschätzsoftware – Xactimate, Symbility oder eine Word-Vorlage), medizinische Unterlagen des Leistungserbringers des Antragstellers (formatiert durch die Krankenhaus-EHR – Epic, Cerner, Athenahealth – jede erzeugt ein anderes PDF-Layout), Fotos des Schadens und Korrespondenz vom Anwalt des Antragstellers. Keines dieser Dokumente ist ein ACORD-Formular. Alle enthalten Daten, die der Schadenssachbearbeiter in ClaimCenter oder das Schadenmanagementsystem eingeben muss, bevor der Schaden bearbeitet werden kann.

Dies ist die Frage, die Werkzeuge, die für die Verarbeitung von Versicherungsdokumenten entwickelt wurden, von Werkzeugen unterscheidet, die das Problem tatsächlich lösen. Ein vorlagenbasierter Extraktor benötigt eine vorkonfigurierte Vorlage für jedes Dokumentformat, das er verarbeitet. In der Versicherung, wo derselbe Dokumenttyp (ein medizinischer Bericht, ein Reparaturkostenvoranschlag, ein Polizeibericht) von jeder Quelle in einem anderen Format eintrifft, erzeugt die vorlagenbasierte Extraktion einen Wartungsaufwand, der die manuelle Dateneingabe, die sie ersetzen sollte, übersteigen 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 stattdessen

Versicherer, die Guidewire, Duck Creek, Majesco oder OneShield betreiben, verfügen bereits über Systeme, die den Lebenszyklus einer Police oder eines Schadens verwalten, sobald die Daten im System sind. Guidewire ClaimCenter übernimmt Zuweisung, Untersuchung, Bewertung, Verhandlung und Regulierung. Duck Creek Policy verwaltet Tarifierung, Ausstellung, Endorsements und Verlängerungen. Diese Plattformen sind keine Dokumentextraktions-Tools – sie sind Workflow- und Datenmanagementsysteme, die davon ausgehen, dass strukturierte Daten an ihrer Schnittstelle ankommen.

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. Der Polizeibericht enthält den Vorfallsbericht, den eingesetzten Beamten und die Aktennummer. Die Arztrechnung enthält den Leistungserbringer, die Kosten, die Diagnosecodes und das Leistungsdatum. 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 Schaden, der eingeht.

Die Dokumentextraktion sitzt in dieser 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 Dokumenten zum Abtippen. Die Daten gehen weiterhin in Guidewire oder Duck Creek. Der Sachbearbeiter prüft sie weiterhin. Der Unterschied ist, ob sie 15 Minuten mit Tippen oder 90 Sekunden mit Prüfen verbringen.

Diese Positionierung ist wichtig, wenn Sie Tools bewerten. Ein Extraktionstool, das eine Guidewire-Integration erfordert, um zu funktionieren, löst ein anderes Problem (und verlangt dafür Enterprise-Preise). Ein Tool, das strukturierte Daten ausgibt – Excel, CSV, JSON – funktioniert mit jedem Kernsystem, weil jedes Kernsystem strukturierte Daten importieren kann. Die Frage ist nicht „integriert das mit Guidewire“, sondern „liefert das saubere Daten, die mein Team prüfen und in jedem Format importieren kann, das meine Systeme akzeptieren“. Weitere Informationen zu dieser Architekturentscheidung finden Sie unter API vs. No-Code-Dokumentextraktion.

Schadensdokumente: Formatvielfalt innerhalb einer einzigen Schadensakte

Ein einziger Kfz-Versicherungsfall kann acht bis zwölf Dokumente aus sechs verschiedenen Quellen erzeugen. Der Versicherungsnehmer reicht Fotos und eine schriftliche Beschreibung ein. Die zuständige Polizeidienststelle liefert einen Bericht. Die Werkstatt sendet einen Kostenvoranschlag. Der medizinische Leistungserbringer des Anspruchstellers übermittelt Behandlungsunterlagen und Rechnungen. Der eigene Sachverständige des Versicherers verfasst einen Besichtigungsbericht. Ein Anwalt, sofern beteiligt, sendet ein Aufforderungsschreiben.

Jedes dieser Dokumente beantwortet eine Variante derselben drei Fragen: Was ist passiert, wann und wie viel? Aber jedes kodiert diese Antworten in einem anderen Format. Der Polizeibericht platziert das Schadensdatum in einem Kopfzeilenfeld mit der Bezeichnung „Date of Occurrence“. Die Arztrechnung platziert das Leistungsdatum in einer Tabellenspalte mit der Bezeichnung „DOS“. Der Kostenvoranschlag der Werkstatt platziert das Schadenbewertungsdatum in einer 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 zuzuordnen, liest die KI das Dokument und lokalisiert Felder anhand ihrer Bedeutung. Sie definieren die benötigten Spalten – „Schadensdatum“, „Name des Anspruchstellers“, „Geforderter Gesamtbetrag“, „Diagnosecode“, „Reparaturkosten 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, und nicht, indem sie sich merkt, wo es normalerweise erscheint. Dieselben Spaltendefinitionen verarbeiten einen Polizeibericht, eine Arztrechnung und einen Kostenvoranschlag in einem einzigen Batch.

Für Schadensabteilungsteams, die Hunderte von Schadensfällen pro Monat bearbeiten, ist die praktische Auswirkung 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 eliminiert nicht die Prüfung durch den Sachbearbeiter – komplexe Schadensfälle erfordern weiterhin menschliches Urteilsvermögen bei Deckung, Haftung und Rückstellungsbildung. Was sie eliminiert, ist der Übertragungsschritt: die 20–30 Minuten pro Fall, die damit verbracht werden, PDFs zu lesen und Werte in Felder einzutippen, die eine Maschine in Sekunden hätte befüllen können.

COIs und Compliance-Dokumente: Das Problem der eingegangenen Zertifikate

Versicherungsunternehmen stellen COIs aus. Sie erhalten sie auch — von Versicherungsnehmern, die nachweisen müssen, dass ihre Auftragnehmer, Dienstleister oder Mieter über ausreichenden Versicherungsschutz verfügen. Ein Gewerbeimmobilienversicherer, 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 der Vertragsanforderung? 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 gegenüber den Vertragsanforderungen 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 ist das Volumen und die Geschwindigkeit der Überprüfung. Ein Compliance-Analyst, der 5 Minuten pro COI für die manuelle Eingabe von Policennummer, Versicherer, Deckungsarten, Deckungssummen, Beginn, Ablaufdatum und Status der zusätzlich versicherten Partei in eine Nachverfolgungs-Tabelle aufwendet, hat keine Zeit mehr, um zu prüfen, ob die angegebenen Deckungssummen tatsächlich die Mindestanforderungen des Vertrags erfüllen.

Die Extraktion verändert diese Rechnung. Wenn die neun Schlüsselfelder einer COI in Sekunden statt in 5 Minuten Tipparbeit extrahiert werden, verlagert sich die Rolle des Analysten von der Dateneingabe zur Compliance-Prüfung — Prüfung der Endorsement-Sprache, Verifizierung der Deckungsangemessenheit und Kennzeichnung von Ablaufdaten, die vor dem nächsten Vertragsmeilenstein liegen. Die Extraktion verifiziert die Police selbst nicht (kein Extraktionstool kann auf das System des Versicherers zugreifen, um zu bestätigen, dass eine Police in Kraft ist), aber sie erzeugt die strukturierten Daten, die eine Verifizierung in großem Maßstab ermöglichen.

Die Demo oben verwendet eine COI-Voreinstellung — Spalten wie „Policennummer", „Versicherer", „Deckungsart", „Deckungssumme pro Schadensfall", „Gesamtdeckungssumme", „Beginn", „Ablaufdatum", „Zusätzlich versichert J/N". Derselbe spaltenbasierte Mechanismus verarbeitet jedes COI-Format — ACORD 25 von einem nationalen Versicherer, ein Zertifikat auf Briefkopf von einem regionalen Agenten oder eine vom Makler ausgestellte Zusammenfassung mit nicht standardisiertem Layout. Eine ausführliche Anleitung zu COI-Extraktionsworkflows finden Sie in unserem Leitfaden zur COI-zu-Excel-Extraktion.

Krankenakten und unterstützende Nachweise: Die Herausforderung unstrukturierter Dokumente

Bei Personenschäden, Arbeiterunfällen und Invaliditätsansprüchen sind Krankenakten das Beweisgerüst. Ein Sachbearbeiter, der einen Arbeiterunfallanspruch prüft, muss Behandlungsdaten, Diagnosen (häufig als ICD-10-Codes), behandelnden Arzt, Einrichtungsnamen, durchgeführte Verfahren (CPT-Codes) und Gebühren extrahieren – aus Akten, die in dem Format ankommen, das das EHR des behandelnden Anbieters zufällig erzeugt.

Die medizinische Akte eines einzelnen Antragstellers kann Aufzeichnungen eines Hausarztes (Epic-generiertes PDF), eines Orthopäden (Cerner-generiertes PDF), einer Physiotherapiepraxis (ein Word-Dokument oder handschriftliche Fortschrittsnotizen) und eines unabhängigen medizinischen Gutachters (ein getippter narrativer Bericht) umfassen. Jede Quelle erzeugt ein Dokument mit unterschiedlichen Feldnamen an unterschiedlichen Positionen. „Date of Service" kann in vier Dokumenten von vier Anbietern als „DOS", „Service Date", „Visit Date" oder „Encounter Date" erscheinen.

Hier bietet die semantische Extraktion einen strukturellen Vorteil gegenüber vorlagenbasierten Tools. Wenn Sie eine Spalte als „Date of Service" definieren, versteht die KI, dass „DOS", „Service Date", „Visit Date" und „Encounter Date" sich alle auf dasselbe Konzept beziehen – und extrahiert das korrekte Datum aus jedem Dokument, unabhängig von der verwendeten Bezeichnung. Dasselbe gilt für „Total Charges", „Diagnosis" und „Provider Name". Ein Satz Spaltendefinitionen verarbeitet Akten mehrerer Anbieter in einem einzigen Batch und erzeugt eine konsolidierte medizinische Chronologie, die der Sachbearbeiter prüfen kann, statt sie von Grund auf zusammenzustellen.

Diese konsolidierte Ansicht ist das, was Sachbearbeiter typischerweise manuell erstellen – eine Tabellenkalkulation mit jedem Behandlungsdatum, Anbieter, Diagnose, Verfahren und jeder Gebühr aus der gesamten Krankengeschichte des Antragstellers. Die manuelle Erstellung aus 15–20 Seiten Krankenakten dauert 30–60 Minuten pro Anspruch. Die Extraktion reduziert dies auf einen Prüfschritt: Die extrahierte Tabelle auf Genauigkeit prüfen, Fehllesungen korrigieren und zur Bewertung übergehen. Weitere Informationen darüber, wie die KI mit der Vielfalt der Formate in medizinischen Dokumenten umgeht, finden Sie in unserer medizinischen Rechnungsextraktion-Walkthrough, und für einen Vergleich aus Anbietersicht behandelt der Einkaufsführer zur Extraktion von Gesundheitsdokumenten die EHR-Erfassung und EOB-Abstimmung aus Sicht des klinischen Betriebs.

Bewertungsrahmen: Sieben Fragen vor dem Kauf

Wenn Sie Dokumentextraktions-Tools für einen Versicherungsbetrieb evaluieren – ob P&C-Versicherer, MGA, TPA oder Rückversicherer – zeigen die folgenden sieben Fragen mehr über die Praxistauglichkeit als jede Vorführung eines Anbieters mit einem kuratierten Datensatz.

Für eine detailliertere Aufschlüsselung der Überlegungen zu Eigenentwicklung vs. Kauf und wann Enterprise-IDP gegenüber einem leichteren Tool sinnvoll ist, siehe Eigenentwicklung vs. Kauf für Dokumentextraktion und Enterprise- vs. SMB-Extraktionsfunktionen.

Was Extraktion in der Versicherung nicht ersetzt

Dokumentextraktion ist keine Schadenautomatisierung. Sie ist keine Betrugserkennung. Sie ist keine Entscheidungsfindung. Dies sind häufige Vermischungen im Marketing von Anbietern, die zu falschen Erwartungen führen.

Extraktion erfasst Daten aus Dokumenten. Sie trifft keine Deckungsentscheidungen, legt keine Rückstellungen fest, erkennt keine inszenierten Unfälle und verifiziert nicht, ob die angegebene Police einer COI 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 für COI-Validierung).

Der Wert der Extraktion in der Versicherung ist spezifisch und begrenzt: Sie entfernt den manuellen Übertragungsschritt zwischen Dokumenteingang und Systemerfassung. Für einen mittelgroßen Versicherer, der 500 Schadenfälle pro Monat mit durchschnittlich 5 Dokumenten pro Schadenfall bearbeitet, sind das 2.500 Dokumente – jedes erfordert 3–5 Minuten manuelle Dateneingabe. Bei durchschnittlich 4 Minuten sind das etwa 167 Stunden Mitarbeiterzeit pro Monat, die damit verbracht werden, Daten abzutippen, die bereits auf Papier oder in PDFs existieren. Extraktion komprimiert den Großteil dieser Zeit in einen Prüfschritt, der in Sekunden pro Dokument statt Minuten gemessen wird.

Was Extraktion schafft, ist Kapazität. Wenn der Schadensachbearbeiter nicht 20 Minuten pro Schadenfall mit Dateneingabe verbringt, kann er diese Zeit für die Arbeit nutzen, die menschliches Urteilsvermögen erfordert: Bewertung der Deckungsanwendbarkeit, Beurteilung der Haftung, Verhandlung von Vergleichen und Identifizierung der Warnsignale, die Betrugserkennungsalgorithmen möglicherweise übersehen. Die Forrester-Umfrage zu Versicherungstechnologie ergab, dass 91 % der Versicherungsorganisationen bis Ende 2026 KI-gestützte Schadenautomatisierung in Produktion haben werden – aber die ausgereifteste und am weitesten verbreitete Fähigkeit innerhalb dieser Automatisierung ist Dokumentextraktion und Datenerfassung, nicht die durchgängige Straight-Through-Verarbeitung.

FAQ