《独立开发者的商业指南·合同、应收与风险》6.3 投保时点与理赔流程

以下情境为教学假设，人物与数字不代表经核实的真实案例。

理赔是保险里最不像财务的部分：它发生在事故之后，充满时间压力和材料准备。但从财务看，理赔只是一个减法：赔付减去免赔、保费和处理工时，剩下的才是净得。投保时点决定这张保单是否覆盖事故；如实告知决定理赔时保单是否还有效；流程决定赔付到账的速度和金额。

用 Nord 的 E&O 举例：一次 $120,000 的索赔，保额 $500,000，免赔 $10,000，年保费 $4,800，处理工时 24 小时、每小时 $85（教学假设）。总额赔付是 min(损失, 保额) = $120,000，减掉免赔 $10,000，保险实付 $110,000；再扣保费和处理成本 $6,840，净得 $103,160，相当于损失的 86.0%。如果理赔被拒，净得变成 −$6,840：保费和处理工时照付，赔付为零。

这一节不写理赔操作手册，也不给法律意见；它只把投保时点、告知义务和理赔流程翻译成三个财务问题：保单有没有生效、赔付能不能成立、净得还剩多少。

投保时点：保单起期、追溯日与项目开始日

保险不是签了字就保所有事。保单有三个时间点：起期（inception）、追溯日（retroactive date）、事故日（occurrence）。E&O 和网络安全险常按索赔发生制承保：只要索赔在保单期内提出，事故可以发生在追溯日之后；追溯日之前的事故，通常不保。

对 Nord，最危险的时间窗是项目开始到保单起期之间。咨询合同签字、项目启动、交付物发出，这些动作都在产生责任；如果 E&O 在项目开始三个月后才生效，追溯日又设成保单起期，这三个月的交付就没有保险。一次 $120,000 的索赔如果落在这个窗口，赔付是 $0，自留是 $120,000，而不是 $10,000。

对 LedgerLite，同样的窗口是第一个客户数据上线到网络安全险起期之间。数据泄露可以在上线第一天发生；如果保单在两个月后生效，且没有追溯日覆盖上线日，这两个月的数据就是全自留。$120,000 的响应成本对 LedgerLite 是 0.92 年 SDE，对 Nord 是 3.50 年 SDE；同一个时间窗，两家公司的承受能力完全不同。

这张表的差额是 $110,000，正好是一次标准赔付的金额。投保时点不是行政流程，它直接决定这张保单有没有机会赔。对服务型公司，投保时点应该对齐第一个有风险的交付；对订阅型公司，应该对齐第一个客户数据进入系统。

还有一个时间点常被忽略：保单到期后的尾期（run-off）。索赔发生制保单通常只保保单期内提出的索赔；保单到期后，如果事故发生在保单期内、索赔在到期后才提出，需要尾期保障或续保来覆盖。没有尾期，保单到期那一刻，历史项目的尾部风险就暴露了。

这张表把「保单有效期」和「事故有效期」分开：保单有效，不等于事故一定在保；事故在保，也不等于索赔一定在保单期内提出。投保时点的真正含义，是让这三个时间窗对齐，而不是只让保单在某个日期生效。

如实告知：申请表上的每个数字都会回来

投保申请表会问收入、客户数、服务类型、数据类型、安全措施、历史索赔和已知争议。这些答案不是背景调查，而是保单的定价基础和承保条件。填错不会平均分摊，而是可能在理赔时变成拒赔理由。

对 LedgerLite，如果申请表把年收入写成 $150,000，实际是 $240,240，保费按较低的收入档计算；理赔时保险公司发现收入口径不符，可能按比例赔付，也可能拒赔。一种常见的按比例赔付算法是「已付保费 ÷ 应缴保费 × 赔付」：假设应缴保费是 $4,800，实缴 $3,000，比例是 62.5%，原本 $110,000 的赔付变成 $68,750，自留从 $10,000 变成 $51,250。

「已知争议」是最容易被低估的一项。投保前已经发生的客户纠纷、已经收到的律师函、已经发现的漏洞，通常属于已知索赔或已知情况，不在保单范围内；如果申请表问「是否已知」，答「否」，理赔时会被拿出来。对独立开发者，最常见的不是故意隐瞒，而是觉得这件事不算争议；判断标准不是你的感觉，而是申请表的问题和保单的定义。

如实告知还包括业务变化。保单期内新增了数据处理、新增了子处理者、收入翻倍，这些变化可能超出原保单的承保范围。多数保单要求在中介或保险公司规定的时间内通知；不通知的后果，和投保时填错类似：理赔时按新风险重新核保，或者直接拒赔。DPA 下的子处理者管理见11.1 DPA、SCC 与跨境传输 。

这张表说明，告知义务不是投保那一刻的一次性动作，而是保单期内的持续义务。业务变化越快，越容易漏报；漏报的代价，通常在一次理赔时才出现。

理赔四步：报案、举证、定损、赔付

理赔通常分四步，每一步都有时间成本和材料成本：

1. 报案：事故发生后，在保单规定的时间内通知保险公司或中介。报案不等于索赔，但延迟报案可能影响赔付；先把时间、地点、涉及客户、初步损失记下来。
2. 举证：证明损失真实、金额合理、在保单范围内。材料包括合同、发票、交付记录、日志、客户索赔函、修复账单、第三方账单。举证不足，定损就会被压低。
3. 定损：保险公司核对保额、免赔、分项限额、除外责任，决定哪些损失赔、赔多少。定损可能聘请律师、取证机构或第三方定损人；他们的结论不一定是最终结论，但会决定谈判起点。
4. 赔付：保险公司支付赔款，可能扣除免赔、未保险部分和已由第三方支付的部分。赔付后，保险公司可能取得代位求偿权，向责任方追偿。

这张表的时间是教学假设，不是承诺。真实理赔的时长取决于事故复杂度、材料完整度和保险公司的流程；对现金流紧张的一人公司，等待期本身就是成本。LedgerLite 的年 SDE 是 $130,240，月均约 $10,853；如果理赔拖 6 个月，这段时间的现金缺口要靠自有资金垫付，保险赔付到账之前，损失已经发生。

举证阶段最容易被忽略的是证据链。客户索赔函、交付记录、变更单、验收邮件、监控日志、修复账单，这些材料在事故发生时才想起来收集，通常已经不全。证据链的日常管理见5.3 证据链与止损 ；保险理赔不是另起一套证据，而是把日常证据按保单要求重新组织。

这张表说明，举证不是理赔开始时才做的事，而是日常记录的自然延伸。证据链完整，定损才有依据；证据链缺失，保险赔付再高也可能赔不出来。

一次理赔的净得

把一次理赔拆成现金项，才能看出保险到底补了多少。以 Nord 的 E&O 为例：

保险实付除以损失是 91.7%，净得率 86.0% 是公司最后留下多少。两者相差 5.7 个百分点，来自保费和处理工时。如果处理工时是 80 小时而不是 24 小时，处理成本变成 $6,800，净得降到 $98,400，净得率 82.0%。工时不是小数：一次理赔的内部投入，可能相当于一个月的可支配时间。

如果理赔被拒，净得变成负数：

拒赔的净损失不只是没拿到赔付，还包括已经花掉的保费和工时。对 Nord，−$6,840 是 SDE 的 19.9%；对 LedgerLite，同样的金额是 SDE 的 5.3%。金额相同，相对压力不同。

净得还要看时间价值。如果赔付在 6 个月后到账，而损失在第 1 个月已经支付，公司需要垫付 6 个月的现金；按 LedgerLite 的年 SDE $130,240 折算，月均 $10,853，6 个月是约 $65,120 的现金占用。保险赔付没有改变损失的金额，但改变了现金流的时点；对 runway 紧张的公司，时点和金额一样重要。现金底线见8.3 runway 与最低现金水位 。

这张表的现金占用是近似值：它用月均 SDE 代表每月可垫付的现金，实际垫付取决于损失支付节奏和公司现金余额。它想说明的是，理赔时长不是「等一等」的问题，而是现金流问题。

代码：理赔净得

下面的 claim.ts 把理赔的现金项固化成 settleClaimWithCost：输入是否在保、损失、保额、免赔、年保费、处理工时和小时费率，输出总额赔付、保险实付、自留、保费、处理成本、净得和赔付率。金额用整数美分，工时可以是小数，处理成本四舍五入到美分。

// file: src/contract/claim.ts
// tier: L1
// verify: node --test test/contract/claim.test.ts

import { type Cents } from "../core/money.ts";
import { type Bps, divide } from "../core/rate.ts";
import { type Result, fail, ok } from "../core/result.ts";

export type ClaimInput = {
  covered: boolean;
  lossCents: Cents;
  limitCents: Cents;
  deductibleCents: Cents;
  annualPremiumCents: Cents;
  handlingHours: number;
  hourlyRateCents: Cents;
};

export type ClaimOutcome = {
  covered: boolean;
  grossIndemnityCents: Cents;
  insurerPaysCents: Cents;
  deductibleCents: Cents;
  premiumCents: Cents;
  handlingCostCents: Cents;
  netRecoveryCents: Cents;
  recoveryBps: Bps;
};

function validAmount(value: Cents): boolean {
  return Number.isInteger(value) && value >= 0;
}

/**
 * A claim has three costs that survive even when the insurer pays: the
 * deductible, the premium already spent, and the hours needed to document the
 * loss. Net recovery is what the business keeps after all three. A denied
 * claim keeps none of the indemnity but still pays the premium and the hours.
 */
export function settleClaimWithCost(
  input: ClaimInput,
): Result<ClaimOutcome> {
  if (!validAmount(input.lossCents)) {
    return fail("loss must be a non-negative integer amount in cents");
  }
  if (!validAmount(input.limitCents)) {
    return fail("limit must be a non-negative integer amount in cents");
  }
  if (!validAmount(input.deductibleCents)) {
    return fail("deductible must be a non-negative integer amount in cents");
  }
  if (!validAmount(input.annualPremiumCents)) {
    return fail("premium must be a non-negative integer amount in cents");
  }
  if (!Number.isFinite(input.handlingHours) || input.handlingHours < 0) {
    return fail("handling hours must be a non-negative number");
  }
  if (!validAmount(input.hourlyRateCents)) {
    return fail("hourly rate must be a non-negative integer amount in cents");
  }

  const handlingCostCents = Math.round(
    input.handlingHours * input.hourlyRateCents,
  );

  if (!input.covered) {
    const netRecoveryCents =
      -(input.annualPremiumCents + handlingCostCents);
    return ok({
      covered: false,
      grossIndemnityCents: 0,
      insurerPaysCents: 0,
      deductibleCents: 0,
      premiumCents: input.annualPremiumCents,
      handlingCostCents,
      netRecoveryCents,
      recoveryBps: 0,
    });
  }

  const grossIndemnityCents = Math.min(input.lossCents, input.limitCents);
  const insurerPaysCents = Math.max(
    0,
    grossIndemnityCents - input.deductibleCents,
  );
  const netRecoveryCents =
    insurerPaysCents - input.annualPremiumCents - handlingCostCents;

  return ok({
    covered: true,
    grossIndemnityCents,
    insurerPaysCents,
    deductibleCents: input.deductibleCents,
    premiumCents: input.annualPremiumCents,
    handlingCostCents,
    netRecoveryCents,
    recoveryBps: divide(insurerPaysCents, input.lossCents),
  });
}

代码里有四个口径值得注意。第一，grossIndemnityCents 是 min(损失, 保额)，不是最终赔付；最终赔付还要减免赔。第二，netRecoveryCents 是「保险实付 − 保费 − 处理成本」，不是「总额赔付 − 免赔 − 保费 − 处理成本」的另一种写法，两者在数值上相等。第三，covered: false 时，保险实付为 0，但保费和处理成本仍然计入净得，所以净得是负数。第四，recoveryBps 用保险实付除以损失，不是净得除以损失；净得率要另外算。

代码没有处理「部分赔付」和「按比例赔付」。这两种情形要先算出实际可赔金额，再传进 settleClaimWithCost；如果在代码里再加一层比例，公式会变得难以核对。把比例放在输入侧，代码只负责现金项，边界更清楚。

小结

• 投保时点、追溯日和事故日决定保单是否覆盖；项目开始到保单起期之间的窗口是全自留。
• 如实告知是保单的定价基础；收入低报、已知争议未披露、业务变化未通知，都可能在理赔时变成拒赔或按比例赔付。
• 理赔分报案、举证、定损、赔付四步，每一步都有时间成本和材料成本。
• 一次 $120,000 的索赔，赔付 $110,000，扣保费 $4,800 和处理工时 $2,040，净得 $103,160，净得率 86.0%。
• 理赔被拒时，净得是 −$6,840；保费和处理工时不会因为拒赔而退回。
• 处理工时从 24 小时增加到 80 小时，净得从 $103,160 降到 $98,400；内部投入是理赔成本的一部分。
• 赔付到账的时间影响现金流；保险没有改变损失金额，但改变了现金占用。

阅读导航：上一节：6.2 保额、免赔与除外责任 · 下一节：7.1 商标、著作权、专利与商业秘密 。

常见错误与边界

1. 项目开始后才投保。 项目开始到保单起期之间的交付没有保险；追溯日不覆盖，赔付可能是 $0。
2. 把保单起期当成追溯日。 起期是保单生效日，追溯日是事故可以回溯的最早日期；两者不是同一个概念。
3. 忽略尾期保障。 索赔发生制保单到期后，历史项目的索赔可能没有保障；尾期或续保要提前安排。
4. 申请表数字与实际不符。 收入、客户数、数据类型、历史争议填错，理赔时可能按比例赔付或拒赔。
5. 把已知争议当成不算争议。 判断标准是申请表的问题和保单定义，不是自己的感觉。
6. 业务变化不通知。 新增数据处理、子处理者、收入翻倍，可能超出原保单范围；不通知会影响理赔。
7. 延迟报案。 报案不等于索赔，但延迟可能影响赔付；先记录时间、地点、涉及客户和初步损失。
8. 举证材料不全。 交付记录、变更单、验收邮件、日志缺失，定损会被压低；证据链要在日常积累。
9. 只算赔付，不算保费和工时。 赔付率 91.7% 不等于净得率；扣掉保费和处理工时，净得率是 86.0%。
10. 忽略赔付到账时间。 理赔拖 6 个月，现金缺口要靠自有资金垫付；保险改变现金流时点，不改变损失金额。

保险的最后一个财务问题，不是保额够不够，而是事故发生时，这张保单有没有生效、赔不赔、多久到账。把投保时点、告知义务和理赔净得放在一条时间轴上，保险才从一张纸变成一个可计算的现金结果。下一章转向知识产权：它不产生赔付，但决定收入能不能合法地卖第二次。