Vier Zahlen auf einem Loss Run Report,
die übereinstimmen müssen

Ein Loss Run Report besteht aus drei übereinanderliegenden Dokumenten, und nur das mittlere ist eine Schadenstabelle

Jeder Loss Run Report enthält einen Kopfbereich, ein Schadenraster und eine Reihe von Summen, und nur das Schadenraster wird zu Zeilen in Ihrer Tabelle. Der Kopfbereich identifiziert die namentlich versicherte Person, den Versicherer, die Policennummern, die Deckungsart und die Versicherungsperioden. Das Schadenraster listet einen Schaden pro Block oder Zeile auf. Die Summen geben Gezahlt, Reserve und Incurred nach Versicherungsperiode und oft nach Deckung wieder, plus eine Schadensanzahl.

Der Kopfbereich enthält außerdem den Bewertungsstichtag, manchmal als „as of" oder „evaluated" bezeichnet. Er ist der Stichtag für jeden Gezahlt- und Reserve-Wert auf der Seite. Ohne ihn ist ein Incurred-Wert ein Wert ohne Uhr, und zwei Berichte lassen sich nicht vergleichen, selbst wenn sie denselben Schaden abdecken. Ein am 14. Oktober gedruckter Loss Run sagt Ihnen, was der Versicherer am 14. Oktober annahm, und nichts darüber, was er heute annimmt.

Die Datei als eine durchgehende Tabelle zu lesen, ist die Quelle der ersten Fehler. Das Schadenraster beginnt oft auf Seite zwei oder Seite fünf, Scans wiederholen den Policenkopf oben auf jeder Seite, und Summenzeilen haben dieselbe Spaltenform wie Schadenszeilen. Ein Jahr ohne Schäden kann als „no known losses"-Schreiben statt als leere Seite eintreffen, was ein echtes Dokument und kein leeres Ergebnis ist. Alles Folgende setzt voraus, dass diese Ebenen getrennt werden, bevor irgendjemand über Genauigkeit spricht.

Vier Zahlen entscheiden, ob zwei Berichte überhaupt vergleichbar sind

Gezahlt, Reserve, Incurred und die gedruckte Gesamtsumme des Berichts selbst sind die einzigen Werte, die übereinstimmen müssen, bevor der Rest der Tabelle etwas bedeutet. Die anderen Felder erklären, wie diese Zahlen zustande kamen. Sie prüfen sie nicht.

Incurred ist der Wert, den ein Underwriter tatsächlich bepreist. Ein Schaden mit 47.000 $ Gezahlt und 28.000 $ Reserve ist ein Schaden von 75.000 $, nicht von 47.000 $, und in der offenen Reserve verbirgt sich noch immer die Loss Development. Was Neulinge in diesem Bereich überrascht, ist, wie oft Incurred gar nicht ausgewiesen wird. Es ist ein abgeleiteter Wert, und bei vielen Reports liefert der Versicherer die beiden Eingangswerte und erwartet, dass Sie sie addieren.

Incurred bricht zuerst, und die Ursache ist meist eine Definition und kein Tippfehler

Drei Versicherer-Konventionen können Incurred beim selben Schaden um Zehntausende verschieben, und nur eine davon kündigt sich auf der Seite an. Keine davon ist ein Extraktionsfehler. Alle werden zu Extraktionsfehlern, wenn Ihr Spaltensatz sie ignoriert.

Kosten stehen innerhalb oder außerhalb der Geldspalten. Viele Versicherer rechnen zugewiesene Schadenregulierungskosten – die Kosten für Verteidigungsanwälte und unabhängige Schadenregulierer – in Gezahlt und Reserve ein. Andere drucken „nur Schaden, ALAE nicht enthalten" und führen Kosten in separaten Spalten. Wenn Sie Gezahlt und Reserve aus beiden extrahieren, ohne den Hinweis zu lesen, vergleichen Sie einen Schaden, der 30.000 $ Verteidigungskosten enthält, mit einem, der sie ausschließt. Wenn Sie außerdem die separaten Kostenspalten in Incurred einrechnen, obwohl der Versicherer sie bereits eingerechnet hat, zählen Sie dieselben Beträge doppelt. Der Hinweis entscheidet, welche Ihrer beiden Regeln gilt, und er ist meist ein Stempel oder eine Fußnote, kein Spaltenkopf.

Regresse werden verrechnet oder brutto ausgewiesen. Subrogation und Salvage – von Dritten zurückgeholte Beträge – können Incurred mindern oder in einer eigenen Spalte stehen, während Incurred brutto bleibt. Ein Schaden, bei dem 80.000 $ gezahlt und 60.000 $ von einem Subunternehmer zurückgeholt wurden, ist ein Nettoverlust von 20.000 $ und ein Bruttoverlust von 80.000 $. Beide Zahlen sind korrekt. Die Nettosumme eines Versicherers zur Bruttosumme eines anderen zu addieren, ist es nicht.

Die Reserve muss nicht existieren, und das kann völlig legal sein. Florida verlangt von einem Versicherer, einem Versicherten innerhalb von 15 Kalendertagen nach schriftlicher Anfrage einen Loss Run über fünf Jahre zu senden, und dasselbe Gesetz besagt, dass ein Versicherer keine Informationen zu Schadenreserven bereitstellen muss (Fla. Stat. § 627.444). Kentucky setzt ein Fenster von 20 Tagen für dieselben fünf Jahre (KRS 304.20-100). Die Antragsseite ist reguliert. Der Inhalt ist nicht standardisiert. Selbst das Formular ist nur auf einer Seite standardisiert: ACORD 611 ist ein Antrag auf Schadenhistorie und Loss Run, nicht der Report selbst, und der zurückkommende Report folgt keinem gemeinsamen Layout (ACORD-Formularindex). Makler beschreiben dieselbe Varianz: Manche Versicherer drucken ein Schadendatum, andere nur ein Reportdatum, manche lassen Reserven und Schadenkosten ganz weg, und manche zeigen zu einem Schaden fast nichts, bis er geschlossen wird (r/InsuranceProfessional).

Bei einem Report mit nur Gezahlt liefert eine berechnete Incurred-Spalte Gezahlt zurück. Ein Schaden mit 9.000 $ Gezahlt und 86.000 $ Reserve wird zu einem Schaden von 9.000 $, das Sheet füllt sich sauber, und nichts im Prozess meldet einen Fehler.

Dieses Versagen verdient Aufmerksamkeit, denn es übersteht jede nachgelagerte Prüfung. Die Zeilenzahl stimmt, die Summen passen, die Datei öffnet sich. Das Konto sieht einfach besser aus, als es ist. Die einzige Verteidigung ist eine Regel, die vor der Arithmetik greift: Eine fehlende Reserve bleibt leer, niemals null, und eine Statusspalte hält fest, dass das Feld nicht gemeldet wurde. Leer wird als unbekannt weitergegeben. Null wird als Tatsache weitergegeben.

Zeilenzahl und Gruppierung scheitern als Nächstes, selbst wenn jeder Dollar stimmt

Eine Schadentabelle kann jede arithmetische Prüfung bestehen und dennoch die Häufigkeit überzeichnen, weil die Häufigkeit in Zeilen gezählt wird, nicht in Dollars. Vier Probleme verursachen den größten Teil des Schadens.

Summenzeilen, die als Schäden gezählt werden. Eine Zwischensummenzeile hat einen schadenähnlichen Betrag und oft eine leere Schadennummer. Landet sie in den Daten, erhält die Versicherungsperiode einen Phantom-Schaden und die Dollars werden doppelt gezählt. Da die Anzahl das Erste ist, was ein Underwriter liest, verändert dieser Fehler die Aussage über die Betriebsabläufe des Kontos, selbst wenn Incurred korrekt ist.

Ein Unfall, zwei Schadennummern. Ein Hofschlepper, der einen Besucher anfährt, kann sowohl unter Auto- als auch unter General Liability reserviert werden, mit einer separaten Schadennummer je Deckungsart. Eine Deduplizierung nach Schadennummer findet nichts, weil die beiden Nummern tatsächlich verschieden sind. Die praktikable Regel lautet, nach Schadendatum, Beschreibung und Betrag abzugleichen, den Unfall einmal zu zählen und beide Deckungsreserven zu behalten. Blind angewendet verdoppelt derselbe Unfall die Schadenzahl und das Incurred.

Ein geschlossener Schaden ohne Zahlung zählt trotzdem. Er trägt $0 zur Severity und einen Schaden zur Häufigkeit bei – genau das Signal, das ein Risk Manager braucht, wenn ein Sicherheitsprogramm still versagt. Zeilen auf „Betrag größer als null" zu filtern, löscht das nützlichste Muster im Report.

Bewertungsstichtage, die innerhalb einer Submission abweichen. Ein Paket von fünf Versicherern kann fünf Bewertungsstichtage enthalten, und einer davon ist oft Jahre alt, weil derselbe Report seit seiner Ausstellung mit dem Konto weitergeleitet wurde. Incurred über diese Reports zu summieren, ergibt eine Gesamtsumme, die kein einzelner Stichtag stützt. Behalten Sie den Bewertungsstichtag in jeder Zeile und weigern Sie sich, Reports zusammenzufassen, ohne zu sagen, zu welchem Stichtag welche Zahl gehört.

Die Felder, die ein Underwriter zuerst liest, und die Berichtsfelder, die ihn dabei halten

Eine Schadenzeile ohne ihren Policenkontext ist unbrauchbar, denn dieselbe Schadennummer bedeutet nichts, solange Sie nicht wissen, welcher Versicherer sie ausgegeben hat und unter welche Periode sie fällt. Deshalb muss der Spaltensatz beide Ebenen in jeder Zeile tragen, nicht nur in einem Deckblatt. Für einen Broker, der ein Paket zusammenstellt, ist das Ergebnis Underwriting-Submission-Daten: eine Tabelle auf Schadenebene, die ein Rating-System oder die Arbeitsmappe eines Underwriters ohne einen weiteren Übertragungsschritt aufnehmen kann.

Workers-Compensation-Loss-Runs benötigen zwei weitere Spalten. Die erste ist die Schadenart, nur medizinisch oder mit Verdienstausfall, denn ein Bestand mit ausschließlich medizinischen Schäden liest sich ganz anders als einer, der bei gleicher Gesamtsumme Entschädigungsleistungen enthält. Die zweite ist die Aufteilung in medizinische und Entschädigungskosten, da beide getrennt gezahlt oder reserviert werden können. Alles andere folgt demselben Muster.

Eine Zeile pro Schaden ist eine Spaltendefinition, keine Dokumentvorlage

Die Loss-Run-Extraktion funktioniert, indem die Ausgabespalten festgelegt werden und die Leselogik sich an jedes Dokument anpasst. Das ist der Unterschied zwischen Custom Column Extraction und vorlagenbasiertem Parsing. Sie geben die gewünschten Spaltennamen ein, etwa Schadennummer, Schadendatum, Gezahlt, Reserve, Status und Bewertungsstichtag, und die KI findet jeden Wert, indem sie versteht, was die Bezeichnung bedeutet, und nicht, indem sie weiß, wo sie auf der Seite steht. Jeder Versicherer benötigt keine Vorlage, keinen Mustersatz und keine Konfiguration.

Der Vorlagenansatz scheitert bei diesem Dokumenttyp aus einem strukturellen Grund. Eine Vorlage bildet Positionen ab, benötigt also eine pro Versicherer-Layout, und ein neu ausgegebener Bericht oder eine neue Scan-Auflösung macht sie unbrauchbar. Zwanzig Versicherer bedeuten zwanzig Vorlagen und eine Wartungsschlange. Eine semantische Spaltendefinition wird einmal geschrieben und gilt für den nächsten Versicherer, der auftaucht, was bei einer Submission wichtig ist, bei der die vorherigen Versicherer erst mit dem Paket bekannt werden.

Die Batch-First-Verarbeitung macht aus der Spaltendefinition ein submission-fertiges Sheet. Laden Sie alle Versicherer-PDFs in einem Batch hoch, und die Ergebnisse werden zu einer einzigen Tabelle zusammengeführt, sodass aus einer fünfjährigen Historie über vier Versicherer ein Satz Zeilen wird, wobei jedem Versicherer und jede Versicherungsperiode zugeordnet ist. Die Reihenfolge spielt keine Rolle, solange diese berichtsebene Spalten nach unten durchgereicht werden.

Zwei Spalten erledigen die Arithmetik, die der Bericht Ihnen überlässt. Eine berechnete Spalte, definiert als Incurred (Paid + Reserve), leitet die Zahl für jede Schadenzeile ab, einschließlich Zeilen, in denen der Versicherer kein Incurred ausgewiesen hat. Eine zweite berechnete Spalte kann die Differenz zurückgeben, wenn die Summe aus Gezahlt und Reserve der Zeile nicht mit dem gedruckten Incurred übereinstimmt oder wenn die Schadenzeilen eines Abschnitts nicht die gedruckte Periodensumme ergeben. Beide sind sinnvoll: Die erste füllt eine Lücke, die zweite zeigt Ihnen, wo die Arithmetik des Versicherers oder Ihre Zeilenerfassung fehlerhaft war.

Die letzte wichtige Einstellung ist die Verifizierung. Der Review Mode mit bbox-Hervorhebung ermöglicht es Ihnen, auf eine beliebige extrahierte Zelle zu klicken und zu sehen, woher der Wert auf der Originalseite stammt, und ein Klick auf einen Bereich auf der Seite springt zurück zur Zelle. Bei einem Loss Run ist das die Art und Weise, wie Sie eine niedrig erscheinende Reserve prüfen, ohne vierzig Seiten erneut zu lesen. Aktivieren Sie Auto-annotate für einen Batch, den Sie überprüfen möchten, und die Hervorhebungen warten bereits, wenn Sie ihn öffnen.

Fünf Prüfungen entscheiden, ob die Tabelle eine Kalkulation wert ist

Die Tabelle ist ein Entwurf, bis die Schadenzeilen mit den eigenen Summen des Versicherers übereinstimmen, und diese Prüfung ist die einzige, die eine fehlende Seite aufdecken kann. Führen Sie diese in der angegebenen Reihenfolge aus, bevor die Tabelle einen Underwriter erreicht.

Die Stichprobenprüfung ist der Teil, den Teams überspringen, wenn der Batch sauber aussieht. Ein paar Zeilen herauszuziehen und sie gegen die Seite zu lesen, erkennt den Fehler, den Summen nicht erkennen können: einen Wert, der in sich stimmig, aber dem falschen Schaden zugeordnet ist. Eine funktionierende Routine dafür finden Sie unter Batch-Verifizierung und Stichprobenprüfung.

Was eine Schadenstabelle Ihnen nicht sagt

Eine saubere Tabelle beantwortet, was der Versicherer gemeldet hat. Sie beantwortet nicht, was das Risiko wert ist. Die Grenze ist es wert, benannt zu werden, denn das typische Fehlermuster bei diesem Dokumenttyp ist übermäßiges Vertrauen, nicht zu wenig Vertrauen.

Sie trifft nicht die Underwriting-Entscheidung. Appetit, Bedingungen, Selbstbehaltsstruktur und Preis bleiben beim Underwriter. Sie liefert keine aktuarische Sicht: Sie können Incurred durch verdiente Prämie in der Tabelle teilen, aber Trendauswahl, Entwicklungsfaktoren und Credibility sind nichts, was die Extraktionsebene leistet oder auch nur implizieren sollte. Sie liefert keinen Connector zu einem Versicherer- oder Agenturverwaltungssystem. Die Ausgabe ist eine Tabelle, CSV oder JSON, die Sie oder Ihr Rating-Tool laden, und die Zuordnung in Applied Epic, Vertafore oder eine interne Workbench ist Ihre Integration.

Sie kann auch nicht erfinden, was der Versicherer weggelassen hat. Wenn die Reserve-Spalte nicht auf der Seite steht, ist die korrekte Ausgabe ein Leerfeld und ein Hinweis, keine modellierte Schätzung. Sie löst keinen Definitionskonflikt zwischen zwei Versicherern auf; sie kann Ihnen nur zeigen, dass der Konflikt existiert, was der Sinn davon ist, Aufwendungen und Regresse in eigenen Spalten zu führen. Und sie ersetzt nicht den Schadenverlauf im Antrag, wo ACORD 125 und die Spartenabschnitte festhalten, was der Antragsteller zu früheren Schäden angibt. Der Loss Run Report des Versicherers ist der Nachweis, und beide werden zusammen gelesen. Dieselbe Vorsicht gilt für einen Workers' Compensation Experience Mod: Er wird aus den Einheitsstatistikdaten berechnet, die der Versicherer beim Rating Bureau einreicht, sodass eine Abweichung vom vorliegenden Loss Run Report zu erwarten ist und kein Fehlernachweis.

Wenn Ihre Einreichung auch Versicherungszertifikate enthält, sind diese eine separate Extraktionsaufgabe mit eigenen Feldern, und der Workflow zum Überführen von Versicherungszertifikatsdaten in eine Tabelle sollte getrennt bleiben. Loss Run Reports sind die Schadenhistorie. Schadenaufnahme-Dokumente wie FNOL-Formulare und Reparaturschätzungen sind eine dritte Kategorie, behandelt im Leitfaden zur Extraktion von Versicherungsschäden.

FAQ

Kann KI einen gescannten oder gefaxten Loss Run Report lesen?

Ja. Die Extraktion liest die Seite visuell, statt sich auf eine Textebene zu verlassen, sodass ein Scan, ein Fax und ein natives PDF alle dieselben Spaltendefinitionen durchlaufen. Die Lesbarkeit setzt dennoch die Obergrenze. Ein schiefes Fax der dritten Generation mit einem Stempel über der Reserve-Spalte muss geprüft werden, und die ehrliche Antwort ist, dass einige Seiten besser erneut angefordert statt extrahiert werden sollten.

Wie berechne ich Incurred, wenn der Report keine Reserve-Spalte hat?

Gar nicht, und Sie sollten es nicht versuchen. Erfassen Sie Gezahlt, lassen Sie Reserve leer und markieren Sie die Zeile als Reserve nicht gemeldet. Die Alternative, den fehlenden Wert als null zu behandeln, ergibt ein Incurred gleich Gezahlt und untertreibt jeden offenen Schaden im Report. Wenn die Zahl für das Angebot wichtig ist, muss die Reserve vom Versicherer oder vom Schadenregulierer kommen.

Funktioniert das über verschiedene Versicherer hinweg, ohne für jeden eine Vorlage zu erstellen?

Ja, denn die Spalten werden einmal nach Namen definiert und die Extraktion findet Werte über ihre Bedeutung. Ein Loss Run Report im Fließtextstil ganz ohne Tabelle ist der schwierigere Fall, da die Felder möglicherweise nicht einzeln beschriftet sind. Diese Dokumente werden trotzdem extrahiert, verdienen aber eine Prüfrunde, bevor die Zeilen vertrauenswürdig sind.

Kann das Tool für mich eine Loss Ratio berechnen?

Es kann Ihnen die Spalten liefern, die eine Loss Ratio braucht, Incurred nach Versicherungsjahr, und Sie können die Prämie und die Division selbst in der Tabellenkalkulation ergänzen. Es entscheidet nicht, welche Jahre einzubeziehen sind, wie ein Teilzeitraum annualisiert wird oder ob das Ergebnis für die Größe des Kontos glaubwürdig ist. Das sind versicherungsmathematische Beurteilungen.

Ist ein Loss Run Report dasselbe wie die Schadenhistorie in einem ACORD-Antrag?

Nein. Der Abschnitt im ACORD-Antrag ist die eigene Zusammenfassung des Antragstellers zu früheren Schäden, ausgefüllt als Teil der Einreichung. Der Loss Run Report ist die Aufzeichnung des Versicherers, ausgestellt zum Bewertungsstichtag und verknüpft mit Policennummern. Underwriter verlangen beides, weil sie unterschiedliche Fragen beantworten, und eine Abweichung zwischen ihnen ist selbst wissenswert.

Der Wert der Tabelle liegt nicht darin, dass sie das Lesen erspart. Er liegt darin, dass sie Gezahlt, Reserve und Incurred für jeden Versicherer an dieselbe Stelle bringt, sodass eine nicht passende Definition als sichtbare Lücke in einer Spalte erscheint statt als Zahl, die das Konto stillschweigend besser aussehen ließ. Das ist der Punkt, an dem ein Loss Run Report aufhört, ein Dokument zu sein, das Sie durchblättern, und zu etwas wird, das Sie prüfen können.