損失実績報告書の4つの数字
一致していなければならない

損失実績報告書は3つの文書が重なったものであり、クレーム表になるのは真ん中の1つだけです

すべての損失実績報告書にはヘッダー、クレームグリッド、合計欄があり、スプレッドシートの行になるのはクレームグリッドだけです。ヘッダーは記名被保険者、保険会社、保険証券番号、補償種類、保険期間を示します。クレームグリッドは1件のクレームを1ブロックまたは1行として並べます。合計欄は保険期間ごと、多くの場合さらに補償種類ごとに支払済み、準備金、発生額を再掲し、クレーム件数も示します。

ヘッダーには評価基準日も記載され、「as of」や「evaluated」と表記されることもあります。これはページ上のすべての支払済み・準備金の数値の締め切り日です。これがなければ、発生額は時計のない値になり、同じクレームを扱っていても2つの報告書を比較できません。10月14日に印刷された損失実績報告書は、10月14日時点で保険会社がどう考えていたかを示すだけで、現在どう考えているかは何も示しません。

ファイルを1つの連続した表として読むことが、最初の誤りの原因です。クレームグリッドは2ページ目や5ページ目から始まることが多く、スキャンでは各ページの上部に保険証券のヘッダーが繰り返され、合計行はクレーム行と同じ列構成をしています。クレームのない年は、空白ページではなく「no known losses」のレターとして届くことがあり、これは空の結果ではなく実際の文書です。以下では、正確性の話をする前にこれらのレイヤーが分離されていることを前提とします。

2つの報告書を比較できるかどうかは4つの数値で決まります

支払済み、準備金、発生額、そして報告書自体の印字合計だけが、表の残りが意味を持つ前に一致していなければならない数値です。その他のフィールドは、これらの数値がどうやって出たかを説明するものです。数値を検証するものではありません。

発生額は、引受人が実際に価格設定に用いる唯一の数値です。支払済み47,000ドル、準備金28,000ドルのクレームは、47,000ドルではなく75,000ドルのクレームであり、未処理の準備金こそが損失発展が依然として潜む場所です。この業務に不慣れな人が驚くのは、発生額がまったく印字されていないことがいかに多いかという点です。これは導出される数値であり、多くの報告書では保険会社が2つの入力値を提示し、それを合算することを期待しています。

発生額が最初に崩れる。その原因は通常、誤字ではなく定義である

3つの保険会社の慣行が、同じクレームで発生額を数万ドル単位で動かす可能性があり、そのうちページ上で自らを明示するのは1つだけです。いずれも抽出エラーではありません。しかし、あなたの列設定がそれらを無視すれば、すべてが抽出エラーになります。

費用が金額列の内側にあるか外側にあるか。多くの保険会社は、割当損失調整費用（弁護費用および独立損害査定人費用）を支払済みと準備金に折り込んでいます。一方で「損失のみ、ALAE含まず」と印字し、費用を別の列に置く保険会社もあります。注記を読まずに両方から支払済みと準備金を抽出すると、30,000ドルの弁護費用を含むクレームと、それを除外したクレームを比較することになります。さらに、すでに折り込み済みの保険会社に対して別の費用列を発生額に加算すると、同じ金額を二重に計上することになります。どちらのルールを適用すべきかは注記が決めますが、それは通常、列ヘッダーではなくスタンプや脚注です。

回収額が純額で示されるか総額で示されるか。第三者から回収した代位求償および残存物回収の金額は、発生額を減少させる場合もあれば、独自の列に置かれ発生額が総額のままの場合もあります。80,000ドルを支払い、下請業者から60,000ドルを回収したクレームは、純損失20,000ドルであり、総額80,000ドルでもあります。どちらの数値も正しいのです。ある保険会社の純額と別の保険会社の総額を足し合わせることは正しくありません。

準備金が存在しない場合があり、それは完全に合法であり得ます。フロリダ州は、保険会社に対し、書面による請求から15暦日以内に被保険者へ5年間の損失実績報告書を送付することを義務付けており、同じ法令は、保険会社が損失準備金情報を提供することを要求されないと明記しています（Fla. Stat. § 627.444）。ケンタッキー州は同じ5年間に対して20日の期間を定めています（KRS 304.20-100）。請求の側面は規制されています。内容は標準化されていません。様式でさえ片側だけが標準化されています。ACORD 611はクレーム履歴および損失実績報告書の請求書であり、報告書そのものではなく、返送される報告書は共通のレイアウトに従っていません（ACORD forms index）。ブローカーも同じばらつきを説明しています。事故発生日を印字する保険会社もあれば、報告日のみの保険会社もあり、準備金とクレーム費用を完全に省略する保険会社もあれば、クレームがクローズするまでほとんど何も表示しない保険会社もあります（r/InsuranceProfessional）。

支払済みのみの報告書では、計算された発生額列は支払済みを返します。支払済み9,000ドル、準備金86,000ドルのクレームは9,000ドルのクレームになり、シートはきれいに埋まり、プロセス内のどこもエラーを報告しません。

その失敗はじっくり考える価値があります。なぜなら、それは下流のあらゆるチェックをすり抜けて生き残るものだからです。行数は正しく、合計は一致し、ファイルは開きます。しかし、この口座は実際よりも良く見えているだけなのです。唯一の防御策は、計算の前に適用するルールです。欠落した準備金は空白のままにし、決してゼロにはせず、ステータス列にそのフィールドが報告されなかったことを記録します。空白は不明として伝播します。ゼロは事実として伝播します。

金額がすべて正しくても、次に行数とグループ化が失敗する

クレームテーブルはあらゆる算術チェックを通過しても、頻度を過大に示すことがあります。なぜなら、頻度は金額ではなく行数でカウントされるからです。 損害のほとんどは4つの問題に起因します。

合計行がクレームとしてカウントされる。 小計行にはクレームらしい金額があり、多くの場合クレーム番号は空白です。これがデータに入り込むと、保険期間に幻のクレームが加わり、金額が二重にカウントされます。カウントはアンダーライターが最初に読むものなので、発生額が正しくても、このエラーは口座の運用に関する見方を変えてしまいます。

1つの事故に2つのクレーム番号。 ヤードトラクターが訪問者に衝突した事故は、自動車保険と一般賠償責任保険の両方で準備金が計上され、それぞれの補償種類の下で別々のクレーム番号が付くことがあります。クレーム番号で重複排除しても何も見つかりません。2つの番号は本当に異なるからです。実用的なルールは、事故発生日、説明、金額で照合し、事故を1回だけカウントし、両方の補償種類の準備金を保持することです。これを盲目的に適用すると、同じ事故がクレーム数と発生額を倍にしてしまいます。

支払いのないクローズ済みクレームもカウントされる。 これは重大度に$0を、頻度に1件のクレームを寄与します。これはまさに、安全プログラムが静かに失敗しているときにリスクマネージャーが必要とするシグナルです。行を「金額がゼロより大きい」でフィルタリングすると、レポートで最も有用なパターンが削除されてしまいます。

1つの提出書類内で評価基準日が異なる。 5社の保険会社のパケットには5つの評価基準日が含まれることがあり、そのうちの1つは何年も前のものであることがよくあります。同じレポートが発行時から口座とともに転送されてきたためです。それらのレポート全体で発生額を合計すると、どの単一の日付も支持しない合計が生じます。すべての行に評価基準日を保持し、各数値がどの日付に属するかを示さずにレポートをプールすることを拒否してください。

引受担当者が最初に目を通す項目と、関心をつなぎとめる報告書レベルの項目

保険の文脈を欠いたクレーム行は使えません。同じクレーム番号でも、どの保険会社が発行し、どの期間に属するかが分からなければ意味をなさないからです。 だからこそ、列セットは表紙だけでなくすべての行で両方のレベルを保持する必要があります。パケットを組み立てるブローカーにとっての成果物は引受提出データです。つまり、格付けシステムや引受担当者のワークブックが再転記なしで取り込めるクレームレベルのテーブルです。

労災保険の損失実績報告書にはさらに2つの列が必要です。1つ目はクレーム種別で、医療のみか休業補償かです。医療のみのクレーム群は、同じ総額でも休業補償を含む群とは全く異なる読み方になるためです。2つ目は医療費と休業補償の内訳で、それぞれ別々に支払済みまたは準備金として計上されることがあるためです。それ以外はすべて同じパターンに従います。

1クレーム1行はドキュメントテンプレートではなく列定義である

損失実績報告書の抽出は、出力列を固定し、読み取りを各ドキュメントに適応させることで機能します。これがカスタム列抽出とテンプレートベースの解析の違いです。クレーム番号、事故発生日、支払済み、準備金、ステータス、評価基準日など、必要な列名を入力すると、AIはラベルの意味を理解して各値を特定します。ページ上の位置を知っているからではありません。各保険会社にテンプレートもサンプルセットも設定も不要です。

テンプレート方式がこのドキュメントタイプで失敗するのは構造的な理由があります。テンプレートは位置をマッピングするため、保険会社のレイアウトごとに1つ必要で、再発行されたレポートや新しいスキャン解像度で壊れます。20社の保険会社があれば20のテンプレートとメンテナンスキューが生じます。セマンティックな列定義は一度書けば、次に現れる保険会社にも適用できます。これは、パケットが届くまで以前の保険会社が分からない提出案件では重要です。

バッチ処理が列定義を提出可能なシートに変えます。すべての保険会社のPDFを1つのバッチでアップロードすると、結果が1つのテーブルにマージされ、4社にまたがる5年間の履歴が、各クレームに保険会社と保険期間が付いた1つの行セットになります。これらのレポートレベルの列が引き継がれる限り、順序は問いません。

2つの列が、レポートがあなたに任せている計算を行います。発生額（支払済み＋準備金）と定義された計算列は、保険会社が発生額を印字していない行も含め、すべてのクレーム行でその数値を導出します。2つ目の計算列は、その行の支払済み＋準備金が印字された発生額と一致しない場合、またはあるセクションのクレーム行の合計が印字された期間合計と一致しない場合に、その差を返します。どちらも価値があります。1つ目はギャップを埋め、2つ目は保険会社自身の計算またはあなたの行取り込みがどこで狂ったかを教えてくれます。

最後に重要な設定は検証です。bboxハイライト付きのレビューモードでは、抽出された任意のセルをクリックすると、元のページのどこからその値が来たかを確認でき、ページ上の領域をクリックするとセルにジャンプします。損失実績報告書では、40ページを読み返さずに、低く見える準備金をこうやって確認します。レビューする予定のバッチで自動注釈をオンにすれば、開いたときにハイライトが待っています。

この表が料率算出に使えるかは5つのチェックで決まる

クレーム行が保険会社自身の合計と突合するまで、その表は下書きにすぎません。そしてこのチェックだけが、欠落したページを検出できる唯一の手段です。 シートが引受人に渡る前に、次の順序で実行してください。

サンプリングは、バッチがきれいに見えるときにチームが省略してしまう部分です。少数の行を抽出してページと照らし合わせて読むことで、合計では捉えられない失敗、つまり内部的には整合しているものの誤ったクレームに紐づいた値が見つかります。そのための実践的な手順はバッチ検証とスポットチェックサンプリングに記載されています。

クレーム一覧表が教えてくれないこと

整った表が答えているのは、保険会社が報告した内容です。リスクにどれだけの価値があるかではありません。 この境界を明示しておく価値はあります。この種の書類で起きる失敗は、信頼しなさすぎることではなく、信頼しすぎることだからです。

引き受け判断を下すわけではありません。引受方針、条件、免責金額の構造、価格は引受人に委ねられます。アクチュアリー的な見方も生み出しません。発生額を経過保険料で割る計算は表計算ソフトでできますが、トレンドの選定、開発係数、信頼性は、抽出レイヤーが行うものでも、示唆すべきものでもありません。保険会社や代理店管理システムへのコネクタを提供するわけでもありません。出力は表計算ファイル、CSV、またはJSONで、それをあなたやあなたの料率ツールが読み込み、Applied Epic、Vertafore、社内ワークベンチへのマッピングはあなたの統合作業です。

また、保険会社が記載しなかったものを勝手に作り出すこともできません。準備金の列がページになければ、正しい出力は空欄とフラグであり、モデルによる推計値ではありません。2つの保険会社の間で定義が食い違っている場合、それを解決することはできません。できるのは、食い違いが存在することを示すことだけです。費用と回収額をそれぞれ別の列に保つ意味はそこにあります。そして、申請書の損失履歴欄を置き換えるものでもありません。ACORD 125と各補償種類の欄には、申請者が過去のクレームについて述べた内容が記録されます。保険会社の損失実績報告書が証拠であり、両者は併せて読むものです。同じ注意は労災保険の経験料率にも当てはまります。これは保険会社が料率局に提出する単位統計データから計算されるため、目の前の損失実績報告書と一致しないのは、誤りの証拠というより想定内のことです。

提出書類に保険証明書も含まれる場合、それは独自の項目を持つ別の抽出作業であり、保険証明書データを表計算に取り込むワークフローは分けておく価値があります。損失実績報告書はクレーム履歴です。FNOLフォームや修理見積書といったクレーム受付書類は3つ目のカテゴリーで、保険金請求抽出ガイドで扱っています。

FAQ

AIはスキャンまたはFAXされた損失実績報告書を読み取れますか？

はい。抽出はテキストレイヤーに頼らずページを視覚的に読み取るため、スキャン、FAX、ネイティブPDFのいずれも同じ列定義で処理されます。ただし可読性が上限を決めます。準備金の列にスタンプが重なった傾いた第三世代のFAXはレビューが必要で、正直に言えば、抽出するよりも再請求すべきページもあります。

レポートに準備金の列がない場合、発生額はどう計算しますか？

計算できませんし、試みるべきでもありません。支払済みを記録し、準備金は空欄のままにし、その行を「準備金未報告」とマークしてください。もう一つの選択肢である欠損値をゼロとして扱うと、発生額が支払済みと等しくなり、レポート上のすべての未決済クレームを過小評価することになります。見積もりにその数値が重要な場合は、準備金を保険会社または損害査定人から取得する必要があります。

保険会社ごとにテンプレートを作成しなくても対応できますか？

対応できます。列は名前で一度定義され、抽出は意味に基づいて値を特定するからです。表がまったくない段落形式の損失実績報告書はより難しいケースで、フィールドが個別にラベル付けされていない可能性があります。そうしたドキュメントも抽出はできますが、行を信頼する前にレビューを一度行うべきです。

ロス比率を計算してくれますか？

ロス比率に必要な列、つまり保険年度ごとの発生額を提供できます。保険料と除算はスプレッドシートでご自身で追加してください。どの年度を含めるか、部分期間を年換算する方法、その結果がアカウントの規模に対して信頼できるかは判断しません。それらはアクチュアリーの判断です。

損失実績報告書はACORD申請書の損失履歴と同じですか？

いいえ。ACORD申請書のセクションは、提出の一環として記入される申請者自身による過去の損失の要約です。損失実績報告書は保険会社の記録で、評価基準日時点で発行され、保険証券番号に紐づいています。引受人は両方を求めるのは、それぞれが異なる問いに答えるからであり、両者の不一致自体が知る価値のある情報です。

このテーブルの価値は、読む手間をなくすことではありません。保険会社ごとに支払済み、準備金、発生額を同じ場所に並べることで、定義が一致しない箇所が、アカウントを静かに良く見せていた数値ではなく、列の目に見える欠落として浮かび上がることです。そこが、損失実績報告書がめくるドキュメントから、確認できるものになるポイントです。