【メモ】生保の給付金請求の社内フロー
要旨
Web申請の給付金請求では、保険会社側で「形式チェック」「査定」「支払確定」「夜間バッチ」「支払実行」が分業されて進みます。アプリの入力チェックだけで完結せず、自動チェック＋人手確認＋夜間一括処理の組み合わせで支払いに到達する点が重要です。1
本稿では、Web申請前提の社内フローを正常系/不備系/夜間バッチに分けて整理します。
1. 全体像（Web申請を前提にした“箱”の分け方）
- 申請受付（案件起票・受付時刻確定）
- 形式チェック（入力値・添付・本人/口座などの最低限の成立条件）
- 査定（支払可否判断：契約・約款の条件確認）
- 支払確定（承認・支払指図）
- 夜間バッチ（支払データ締め、振込データ生成、会計・連携）
- 支払実行（着金、通知、記録）
「形式チェック」と「査定」を分けるのがポイントで、形式不備は査定に入る前に止める運用が一般的です。
2. 正常フロー（必要情報が揃っているケース）
2.1. Web申請の受信と案件起票
- Webフォーム送信（申請データ＋添付ファイル）
- 受付記録の作成（受付番号、受付日時、契約識別子、請求種類）
- 添付ファイルの保管（申請IDにひも付けて管理）
この時点では「受け取った」だけで、支払判断はまだです。
2.2. 形式チェック（自動＋必要に応じて人手）
- 入力必須項目の欠落（入院期間、手術日、医療機関名、連絡先など）
- 添付必須の不足（診断書、領収書、必要な場合の本人確認など）
- 入力フォーマット妥当性（日付、電話番号、口座情報の桁など）
- 契約情報との基本突合（契約番号の存在、契約状態の概況）
ここを通ると「査定可能」状態になります。
2.3. 査定（支払可否判断）
査定は、提出情報と約款にもとづいて支払事由に該当するかを判断する工程です。免責、支払条件、特約の有無、既払との整合などを確認します。必要に応じて事実確認が入り得ます。1
典型的な確認観点（例）：
- 支払事由該当性（入院日数、手術の定義、通院条件、所定状態など）
- 免責や支払対象外の条件
- 同一事象の二重請求や既払との整合
- 契約状態（失効/解除、特約付帯、支払限度など）
- 追加確認が必要な兆候（添付の内容が不明瞭、記載に矛盾など）
2.4. 支払確定（支払データ化と承認）
- 支払額の確定（給付金内訳、対象期間、限度、既払控除など）
- 承認（自動承認／上長承認／例外承認など、金額や条件で分岐）
- 支払キュー（支払待ち）へ投入
2.5. 夜間バッチ（締め・振込・会計・通知の一括処理）
夜間バッチは「人の判断」をする工程ではなく、日中に確定した支払データをまとめて安全に処理する工程です。大量件数を扱うため、締めや外部連携を夜間に寄せる設計がよく採られます。2
典型的な夜間バッチの中身：
- 当日分の支払対象データを締める（ロック、差分確定）
- 振込データ生成（銀行連携用フォーマット作成）
- 送金依頼の実行または送信予約
- 会計計上（支払計上、引当や残高の更新）
- 通知データ生成（支払通知、Web通知、メールなど）
2.6. 支払実行（着金）と通知
- 銀行処理で着金（即時ではなく銀行営業日に依存する場合あり）
- 支払通知の発行（Web通知・郵送等）
- 監査ログ、オペレーションログの保存
「必要書類がすべて揃った日」から支払いまでの目安として、5営業日以内を掲げる例があります（ただし追加確認が入ると延びます）。34
3. 書類不備フロー（形式不備・不足があるケース）
3.1. 不備検出（自動チェックで止める）
代表例：
- 必須添付が未提出（診断書・領収書など）
- 入力必須項目の欠落（入院日、退院日など）
- 口座情報が成立していない（桁、名義、選択項目の不整合など）
- 添付画像が判読できない（ブレ、欠け、ファイル破損など）
不備が見つかった案件は「不備」または「追加提出待ち」に振り分けられます。
3.2. 不備の分類（差し戻し／追加提出依頼）
- 差し戻し（申請自体の成立に問題がある）
- 例：主要項目が欠落、添付が根本的に足りない、契約特定不能
- 追加提出依頼（不足が限定的で、追完すれば査定できる）
- 例：診断書の追加ページ、領収書の追加、明細の補足
3.3. 請求者への通知（Web中心）
- Webポータルに不足項目一覧を掲示
- メールやアプリ通知でリマインド
- 重要度が高い場合は電話フォローも併用
追加確認や不足がある場合は連絡する旨を明記している例があります。4
3.4. 保留状態での管理（期限・督促・失効を防ぐ）
- 状態管理：不備待ち、追加資料待ち、連絡待ち
- 期限管理：一定期間で自動督促（バッチでリストアップ）
- 監査証跡：いつ何を依頼し、いつ受領したかを記録
3.5. 追加提出後の再開（形式チェックに戻す）
追加提出が来たら、基本的に以下で再開します。
- 追加添付の受領 → 形式チェック再実施 → 通過後に査定へ
- ここで初めて「必要書類が揃った日」が確定する設計が多い
4. 夜間バッチで起きる例外（不備とは別枠）
不備ではなく、支払実行段階で落ちる例外もあります。
- 振込エラー（口座の名義や口座自体の問題、銀行側の受付不可など）
- 連携エラー（銀行連携・会計連携の障害）
- 締め後の差し戻し（承認の取り消し、例外フラグの付け直し）
この場合は「支払確定」または「支払実行前」へ戻して再処理する運用になります。
5. まとめ表（正常フロー／不備フローの分岐点）
| 工程 | 正常フローで起きること | 不備フローで止まるポイント | 次に進む条件 |
|---|---|---|---|
| 受付・起票 | 受付番号付与、添付保管 | 契約特定不能など | 契約と申請のひも付け完了 |
| 形式チェック | 入力/添付/最低限の突合 | 必須不足、形式エラー、判読不能 | 査定可能状態になる |
| 査定 | 約款条件で支払可否判断 | 追加確認が必要な場合は保留 | 支払可（または否）の結論 |
| 支払確定 | 金額確定、承認、支払キュー | 例外承認待ち | 支払対象として締めに乗る |
| 夜間バッチ | 締め、振込データ生成、会計・通知 | 連携エラー、振込生成失敗 | 振込依頼が成立 |
| 支払 | 着金・通知 | 振込エラー | 口座訂正・再振込で完了 |
まとめ
- 形式チェックと査定は分離され、査定前に不備を止める設計が一般的
- 追完による復帰で「必要書類が揃った日」が確定する
- 夜間バッチは締め・連携・会計の要で、例外時は前工程へ戻す