Kann KI Versicherungs-Schadenmeldungen (FNOL) lesen?
Ja – Feld-für-Feld-Analyse

Was ein FNOL-Formular tatsächlich enthält

Eine Erste Schadensmeldung ist keine einzelne Dokumentenart. Sie besteht aus drei Eingabeschichten, die zu einem Schadensereignis gebündelt werden – und jede Schicht stellt eine andere technische Herausforderung für die KI-Extraktion dar.

Schicht 1 – Die strukturierten Kopfzeilenfelder. Jedes ACORD-FNOL-Formular (ACORD 1 für Sachschäden, ACORD 2 für Kfz, ACORD 3 für allgemeine Haftpflicht) beginnt mit einem Block beschrifteter Felder: Policennummer, Name des Versicherungsnehmers, Datum und Uhrzeit des Schadens, Schadensort, NAIC-Versicherungscode, Polizeiberichtsnummer und die Kontrollkästchen für die „Schadensart“. Diese Felder haben gedruckte Beschriftungen. Die Datenwerte sind kurz – typischerweise ein paar Wörter, eine Zahl oder ein Datum. Selbst handschriftlich ist der Kontext stark eingeschränkt: Das Feld für die Policennummer enthält immer eine Policennummer. Diese Einschränkung macht die KI-Extraktion zuverlässig.

Schicht 2 – Die Freitext-Schilderung. Der Abschnitt „Schadensbeschreibung“ auf einem ACORD-Formular ist ein leeres Feld von etwa einer halben Seite Größe. Der Anspruchsteller schreibt in eigenen Worten, was passiert ist – 50 oder 500 Wörter, sachlich oder abschweifend mit Details zum Wetter, zum Verhalten des anderen Fahrers und zur Dauer des Abschleppvorgangs. Dieser Text enthält Informationen, die ein Sachbearbeiter zur Prüfung von Deckung und Haftung benötigt, ist aber keine strukturierten Daten. Kein heutiges KI-Extraktionstool kann diese Art von Schilderung zuverlässig in kategorisierte Felder umwandeln, ohne eine Fehlerrate, die die nachgelagerte Verarbeitung unzuverlässig machen würde.

Schicht 3 – Beigefügte Anhänge. Eine FNOL wird selten allein eingereicht. Ein Polizeibericht kommt als separates PDF vom Portal der Strafverfolgungsbehörde. Ein Reparaturkostenvoranschlag stammt aus dem Kalkulationssystem einer Werkstatt. Fotos des Schadens werden von einem Smartphone gesendet. Jeder Dokumententyp liegt in einem anderen Format vor, kommt über einen anderen Kanal und erfordert einen eigenen Extraktionsansatz.

Die Frage „Kann KI Versicherungs-Schadensmeldeformulare (FNOL) lesen?“ hat daher drei verschiedene Antworten, je nachdem, nach welcher Schicht Sie fragen. Die praktische Antwort für den Schadensbetrieb lautet: Ja für Schicht 1, teilweise für Schicht 2 (als Text extrahieren, nicht kategorisieren) und ja für Schicht 3 – mit dem Vorbehalt, dass jeder Anhangstyp seine eigene Extraktionsspaltendefinition benötigt.

Die strukturierten Felder: Wo KI wirklich glänzt

Der Kopfblock eines ACORD-1-, -2- oder -3-Formulars enthält etwa 12–15 Felder, die vorhersehbaren Mustern folgen. Jedes Feld hat eine gedruckte Beschriftung in der Nähe, einen begrenzten Wertebereich und ein definiertes Format – Bedingungen, unter denen moderne Bild-KI ihre beste Leistung erbringt. Die folgende Tabelle zeigt die gängigsten Felder, ihr Format und die realistische Extraktionsgenauigkeit, die Sie mit einem semantischen, vorlagenfreien KI-Ansatz erwarten können.

Das Muster ist eindeutig: Jedes Feld im beschrifteten Kopfbereich – wo die KI die Beschriftung lesen kann, um den zugehörigen Wert zu verstehen – erzielt eine hohe Genauigkeit, unabhängig davon, ob die Eingabe getippt oder handschriftlich erfolgt. Die Herausforderung Handschrift ist real, betrifft aber einzelne Zeichen (eine handschriftliche „5“ wird als „S“ gelesen, eine „0“ als „O“), nicht die grundsätzliche Extraktionsfähigkeit des Feldes. Eine handschriftliche Policennummer mit einem einzigen falsch gelesenen Ziffer wird durch eine einfache Prüfsummenvalidierung abgefangen, wenn die Nummer mit keiner aktiven Police in den Akten übereinstimmt. Der Fehler wird erkannt, bevor er ins Schadenssystem gelangt.

Die Schilderung: Wo KI an ihre Grenzen stößt

Das Feld „Schadenschilderung“ ist der Teil eines FNOL-Formulars, bei dem die KI-Extraktion nicht so funktioniert, wie es sich die meisten Schadensabteilungen erhoffen. Dieser Abschnitt enthält typischerweise 200–500 Wörter Fließtext – die eigene Schilderung des Geschädigten, in seinen eigenen Worten, in einem Moment, in dem er gestresst, verletzt oder in Eile sein kann. Eine Kfz-Unfallmeldung könnte lauten: „Ich hielt an der roten Ampel auf der Main Street in nördlicher Richtung. Die Ampel wurde grün und ich fuhr los. Ein weißer Pickup überfuhr die rote Ampel aus westlicher Richtung und traf meine Fahrertür.“ Eine Sachschadenmeldung könnte heißen: „Ich kam um 17:30 Uhr von der Arbeit nach Hause und bemerkte Wasserflecken an der Decke im Wohnzimmer. Ich ging auf den Dachboden und sah, dass ein Rohr in der Nähe des Kamins geplatzt war. Ich drehte den Haupthahn ab und rief einen Klempner.“

Moderne Bild-KI kann den Text dieser Schilderung mit hoher Genauigkeit extrahieren – die handschriftlichen oder getippten Wörter von der Seite lesen und als Textblock in einer Tabellenzelle darstellen. Das funktioniert. Was jedoch nicht zuverlässig funktioniert, ist der Schritt, den die meisten Schadensabteilungen eigentlich wollen: die Kategorisierung dieser Schilderung in strukturierte Felder wie „Schadensursachenkategorie“, „Verantwortliche Partei“, „Haftungsindikator“ oder „Verletzungsschweregrad“.

Die Sprache in den Schilderungen der Geschädigten ist zu variabel. Derselbe Autounfall – eine Kollision beim Linksabbiegen an einer Kreuzung – kann beschrieben werden als „Der andere Fahrer überfuhr die rote Ampel und traf meine Beifahrerseite“, „Ich hatte Grün, sie bog direkt vor mir links ab“ oder „Ich fuhr geradeaus durch die Kreuzung, als das andere Auto aus dem Nichts kam.“ Alle drei beschreiben im Wesentlichen dasselbe Haftungsszenario, ohne dass eine gemeinsame extrahierbare Struktur vorhanden ist. Ein Sprachmodell mag die verantwortliche Partei in 70–75 % der Fälle korrekt kategorisieren, aber diese Genauigkeit bedeutet, dass bei jeder vierten Schadensmeldung eine falsche Haftungseinstufung erfolgt. Ein Sachbearbeiter kann keinem aus der Schilderung abgeleiteten Feld vertrauen, was bedeutet, dass er jede Schilderung trotzdem lesen muss – und die versprochene Zeitersparnis durch Automatisierung verpufft.

Der ehrliche Workflow: Extrahieren Sie die Schilderung als Rohtext in ein einzelnes Feld. Der Sachbearbeiter liest sie – genau wie er sie vom Papierformular lesen würde –, muss aber die Policennummer, Schadennummer, Schadensdatum und Versichertennamen aus den strukturierten Feldern nicht neu eingeben. Die wirkliche Zeitersparnis kommt von den 80–85 % der Felder, die automatisiert werden können, nicht vom Versuch, die restlichen 15–20 % in eine strukturierte Ausgabe zu zwingen, der nicht vertraut werden kann.

Unterlagen ergänzen die Meldung

Eine FNOL-Meldung besteht in der Praxis selten nur aus dem ACORD-Formular. Eine Schadenakte wächst schnell um mehrere Begleitdokumente: einen Polizeibericht als PDF, Reparaturkostenvoranschläge von Werkstätten oder Handwerkern, Fotos des Schadens, medizinische Aufnahmeformulare bei Personenschäden und manchmal einen Abschleppbeleg oder Mietwagenvertrag. Jeder Dokumententyp hat sein eigenes Format, eigene Layoutkonventionen und eigene Schlüsselfelder.

Die praktische Frage ist nicht, ob KI Daten aus diesen Dokumenten isoliert extrahieren kann – das kann sie, mit demselben Ansatz der benutzerdefinierten Spaltenextraktion für jeden Typ. Die Herausforderung sind Umfang und Vielfalt: Ein einziger Schadenfall kann 5–12 Begleitdokumente umfassen, die jeweils eigene Spaltendefinitionen benötigen und alle mit demselben Schadensdatensatz im Schadenmanagementsystem verknüpft werden müssen.

Polizeiberichte sind der häufigste Anhang. Sie enthalten wichtige strukturierte Daten: Name und Dienstmarkennummer des ermittelnden Beamten, Berichtsnummer, Datum und Uhrzeit der Aufnahme, Angabe zum Unfallverursacher, Bußgeldinformationen sowie Hinweise zu Wetter und Straßenzustand. Anders als das ACORD-Formular stammen Polizeiberichte von Hunderten verschiedener Strafverfolgungsbehörden, jede mit einem eigenen Layout – was eine positionsbasierte Vorlagenextraktion unmöglich macht. Ein semantischer KI-Ansatz, der Feldbezeichnungen liest, um Werte zu lokalisieren, kommt mit dieser Variabilität problemlos zurecht.

Reparaturkostenvoranschläge von Werkstätten und Handwerkern enthalten positionsgenaue Details, die für die Rückstellungsbildung nützlich sind: Arbeitsstunden, Teilekosten, Lack und Material sowie der geschätzte Gesamtbetrag. Diese sind am wertvollsten, wenn sie als Tabelle mit einer Zeile pro Position extrahiert werden – sodass der geschätzte Gesamtschaden aus der Summe aller Positionen berechnet werden kann, nicht aus einer einzelnen handschriftlichen Summe, die möglicherweise unvollständig ist.

Die Multidokument-Natur der FNOL-Erfassung erfordert eine Schadensautomatisierungsstrategie, die dokumententypspezifisch ist, nicht nur formularspezifisch. Ein Satz Extraktionsspalten für das ACORD-Formular, ein weiterer für den beigefügten Polizeibericht, ein weiterer für den Kostenvoranschlag – und ein Workflow, der alle mit derselben Schadenakte verknüpft hält.

Warum semantische Extraktion für FNOL besser geeignet ist als Template-OCR

Die Versicherungsbranche hat sich auf ACORD-Formulare standardisiert, damit Daten über Versicherer, Agenturen und MGAs hinweg konsistent sind. Doch die Standardisierung des Formulars standardisiert nicht, wie das Formular eintrifft. Ein ACORD 1 kann als sauberes PDF aus einem Agenturportal kommen. Ein anderes kann als Foto eines Versicherungsnehmers auf dem Handy eintreffen – um 15 Grad gedreht, schräg aufgenommen, mit einem Schatten, der über das Feld der Policennummer fällt. Ein drittes kann eine gefaxte Kopie sein, die drei Komprimierungsdurchläufe hinter sich hat und nur noch als Graustufenbild einer Durchschrift lesbar ist.

Template-basierte Extraktion (Zonen-OCR) erfordert, dass das Werkzeug weiß, wo sich jedes Feld auf der Seite befindet. Die Vorlage sagt: "Die Policennummer befindet sich bei Pixelkoordinaten (200, 450) bis (400, 470)." Das funktioniert, wenn jedes ACORD 1 als perfekt ausgerichtetes 300-DPI-Scanner-PDF von derselben Agentur eintrifft. Es scheitert, wenn das Formular gedreht, beschnitten, schräg fotografiert oder auf einem leicht anderen Papierformat gedruckt eintrifft – all das kommt bei der realen FNOL-Erfassung regelmäßig vor.

Hier unterscheidet sich semantische Extraktion – der Ansatz hinter Custom Column Extraction – grundlegend von traditioneller OCR. Statt nach Daten an festen Seitenkoordinaten zu suchen, liest die KI das Dokument wie ein menschlicher Sachbearbeiter: Sie findet die Bezeichnung "Policennummer" auf dem Formular, liest den daneben stehenden Wert und gibt diesen zurück – unabhängig davon, wo auf der Seite die Bezeichnung steht. Dieselbe Spaltendefinition – "Policennummer" – funktioniert auf einem ACORD 1, einem ACORD 2, einem Handyfoto eines ACORD 3 und einer gefaxten Kopie eines beliebigen davon, weil die KI die eigenen strukturellen Bezeichnungen des Formulars liest, um die Daten zu lokalisieren, und sich nicht auf eine vorab festgelegte Koordinatenmatrix stützt.

Die Auswirkung auf die Betriebsabläufe ist erheblich. Ein Schadenteam, das template-basierte OCR verwendet, muss separate Vorlagen für jeden Formulartyp (ACORD 1, 2, 3), jeden Eingangskanal (Portal-PDF, Handyfoto, Scan, Fax) und jede Variation (neue Formularausgabedaten, agenturspezifische Anpassungen) erstellen und pflegen. Dieser Wartungsaufwand ist ein Hauptgrund, warum Pilotprojekte zur Schadensautomatisierung nach der ersten Machbarkeitsstudie ins Stocken geraten: Die Vorlagen funktionieren bei den fünf Testformularen, versagen dann aber bei den fünfzig Produktionsformularen, die in unterschiedlichen visuellen Zuständen eintreffen. Semantische Extraktion eliminiert die Vorlagenebene vollständig. Sie definieren die Felder einmal. Die KI passt sich jedes Mal an das Dokument an.

Praktische Erkenntnisse für Schadensabteilungen

Wenn Sie prüfen, ob KI-Extraktion für Ihren FNOL-Erfassungsprozess sinnvoll ist, finden Sie hier einen Entscheidungsrahmen, der direkt auf die drei oben diskutierten Ebenen abgestimmt ist:

Für die meisten Schadensabteilungen mit 50–200 FNOLs pro Tag ist der pragmatische Ausgangspunkt: Extrahieren Sie alles, was möglich ist, und belassen Sie den Rest als Text. Die strukturierten Felder, die KI gut verarbeitet – Policennummern, Daten, Namen, Beträge, Fahrzeugdetails – machen den Großteil des Dateneingabeaufwands aus. Allein deren Automatisierung halbiert die Bearbeitungszeit pro Schaden. Der Textabschnitt bleibt als Textabsatz für den Sachbearbeiter zum Lesen. Die Belege werden mit eigenen Spaltensätzen extrahiert. Der Sachbearbeiter validiert, verknüpft die Datensätze und widmet sich der Arbeit, die tatsächlich sein Fachwissen erfordert.

Eine detaillierte Schritt-für-Schritt-Anleitung zur Implementierung – von der Definition Ihrer ACORD-Extraktionsspalten bis zum Export strukturierter Ergebnisse in Guidewire, Duck Creek oder jedes Schadenmanagementsystem – finden Sie unter So extrahieren Sie Versicherungsschadenformulare (FNOL) in Tabellen.

Häufig gestellte Fragen

Wie schneidet die KI-Extraktion bei FNOL-Formularen im Vergleich zur manuellen Dateneingabe ab?

Die manuelle Dateneingabe von FNOL-Formularen weist eine geschätzte Fehlerrate von 3–5 % auf Feldebene auf – etwa ein Fehler bei jedem zweiten oder dritten Schadenfall. Die KI-Extraktion bei strukturierten Feldern erreicht eine Genauigkeit von 90–95 %+, wobei verbleibende Fehler auf schwierige Handschriften oder ungewöhnliche Feldformate zurückzuführen sind. Der entscheidende betriebliche Unterschied: Manuelle Fehler sind zufällig und unvorhersehbar (jedes Feld kann aus beliebigem Grund falsch sein), während KI-Fehler bei bestimmten Feldtypen (handschriftliche Fahrgestellnummern, teilweise angekreuzte Kästchen) gehäuft auftreten und durch ein strukturiertes Validierungsprotokoll leichter vorhersehbar und stichprobenartig prüfbar sind. Einen detaillierten Vergleich der Validierungsansätze finden Sie unter Einrichtung eines Stichprobenprotokolls.

Kann KI handschriftliche FNOL-Formulare extrahieren, die am Unfallort ausgefüllt wurden?

Ja – die Genauigkeit hängt von der Leserlichkeit der Handschrift ab. Ein ACORD 2, der am Straßenrand auf einem Klemmbrett oder der Motorhaube eines Autos ausgefüllt wird, weist in der Regel eine lesbare Handschrift auf, die die KI bei strukturierten Feldern mit 85–90 % Genauigkeit liest. Die Hauptfehlerquelle sind einzelne Zeichenverwechslungen (eine „5“, die wie ein „S“ aussieht) und nicht vollständige Feldausfälle. Jeder Extraktionsworkflow für vor Ort ausgefüllte FNOLs sollte einen kurzen Validierungsschritt enthalten – 1–2 Minuten pro Schadenfall zur Überprüfung der 2–3 kritischsten Felder wie Policennummer, Schadendatum und geschätzte Schadenhöhe.

Kann KI die Schadenschilderung analysieren, um Verschulden oder Haftung zu bestimmen?

Nicht zuverlässig genug für den Produktionseinsatz. KI kann den vollständigen Text der Schilderung als Rohtext mit hoher Genauigkeit in eine Tabellenzelle extrahieren. Die Kategorisierung dieses Textes in strukturierte Felder wie „Schuldiger“, „Ursachenkategorie“ oder „Verletzungsschwere“ führt jedoch zu einer geschätzten Fehlerrate von 25–30 %, was die Ausgabe für Deckungsentscheidungen unbrauchbar macht. Der empfohlene Ansatz besteht darin, die Schilderung als Textfeld zu belassen, das der Sachbearbeiter direkt liest, während die strukturierten Kopffelder automatisiert werden, die den Großteil der Schreibarbeit ausmachen.

Funktioniert die KI-Extraktion auch bei Polizeiberichten und Reparaturkostenvoranschlägen, die dem Schaden beigefügt sind?

Ja – allerdings benötigt jeder Dokumententyp eigene Extraktionsspaltendefinitionen, getrennt vom ACORD-Formular. Polizeiberichte haben andere Felder (Name des Beamten, Berichtsnummer, Angaben zum Bußgeld, Schuldzuweisung). Reparaturkostenvoranschläge enthalten Positionsdetails (Arbeitsstunden, Teile, Gesamtsummen). Für jeden Dokumententyp kann ein eigenes Extraktionsprofil einmalig definiert und für alle Schäden wiederverwendet werden. Die zentrale Workflow-Anforderung ist die Verknüpfung der extrahierten Daten jedes Anhangs mit demselben Schadensdatensatz für eine konsolidierte Verarbeitung. Eine umfassende, dokumentenspezifische Aufschlüsselung finden Sie im vollständigen Leitfaden zur Versicherungsschadenextraktion.

Funktioniert die KI-Extraktion bei allen drei ACORD-FNOL-Formulartypen ohne separate Einrichtung?

Ja – hier zeigt sich der Vorteil der semantischen Extraktion gegenüber vorlagenbasierten Tools am deutlichsten. Da die KI Feldbezeichnungen liest und nicht auf feste Positionen angewiesen ist, funktionieren dieselben Extraktionsspaltendefinitionen für ACORD 1 (Sachschaden), ACORD 2 (Kfz-Schaden) und ACORD 3 (Betriebshaftpflicht). Eine Spalte „Police-Nummer“ extrahiert aus allen dreien, weil die KI die Bezeichnung „Police-Nummer“ auf dem jeweils verarbeiteten Formular findet und den angrenzenden Wert ausliest. Vorlagenbasierte Tools erfordern eine separate Einrichtung für jeden Formulartyp und jede Layoutvariante – mindestens drei Formulare, mehr, wenn Agenturen unterschiedliche Ausgabedaten oder benutzerdefinierte Layouts verwenden.

Wie beginne ich mit dem Testen der KI-Extraktion für die FNOL-Formulare meines Teams?

Laden Sie ein gescanntes ACORD-Formular oder ein Foto eines ausgefüllten Schadenformulars hoch – keine Registrierung erforderlich. Definieren Sie die Spalten, die Ihr Schadensystem benötigt (Police-Nummer, Schadendatum, Versicherungsnehmer, Geschädigter, Schadenart, geschätzte Höhe) und sehen Sie die Extraktionsergebnisse in Sekunden. Eine vollständige Schritt-für-Schritt-Anleitung zur Stapelverarbeitung, Handschrifterkennung und zum Export in Schadenmanagementsysteme finden Sie im FNOL-Extraktionsleitfaden.