Why Claim Records Are Not the Same as Claims
A claim system may contain a row for the first notice, another for a reserve change, several payment transactions, and further rows when a claim is closed or reopened. Counting rows in that system does not necessarily count claims: one claim can generate many records, and accidental duplicates can add still more. A defensible count starts by defining what identifies one claim, then determines which identified claims meet the coverage and time-period rules.
This tutorial assumes an occurrence-triggered coverage for which eligibility depends on whether the covered loss date falls within an applicable coverage period. The coverage must also be one included in the analysis. For a claims-made contract or another coverage with a different trigger, use the contract’s applicable trigger instead of mechanically applying a loss-date rule. The earlier material on coverage periods and earned exposure provides the basis for identifying the relevant coverage dates.
The count is therefore not generally the number of rows, payment transactions, or status changes. It is the number of distinct eligible claim keys. The definition of a key is a data decision that should be made before counting. A claim number may be unique across an entire system, or it may be unique only within a policy, system, or business unit. Use the fields needed to identify one claim reliably in the source data; do not assume that a field is globally unique without checking.
Set the Scope and Eligibility Rules First
Before processing records, state the population being counted. At a minimum, specify the analysis period, the coverage or coverages in scope, the contract trigger that determines eligibility, the data cutoff, and the key fields. For an occurrence-triggered coverage, a typical eligibility rule requires that the claim be associated with the selected coverage and that its covered loss date fall within that coverage’s applicable period. If a loss date is missing, or the coverage association is ambiguous, the record needs investigation rather than an invented eligibility decision.
A reported date and a loss date answer different questions. Under the occurrence-triggered assumption here, the loss date determines whether the event falls in the coverage period; the report date determines whether the claim was present in the data by the cutoff. A claim can be reported after the end of a coverage period and still have a loss date in that period. Conversely, a claim reported during the period can concern a loss outside it.
Eligibility is not the same as whether a claim has been paid, whether a reserve is positive, or whether its current status says “open.” A valid reported claim can have no payment, and a claim may be closed after settlement. These attributes may matter for other analyses, but they do not by themselves define whether an identified claim is included in this count.
A Direct Justification for Counting Distinct Eligible Keys
The logic can be written with an indicator. Let \(K\) be the set of distinct claim keys in the extract by the stated cutoff. For each \(k\in K\), define \(I_k=1\) if that key is eligible and \(I_k=0\) otherwise. The claim count is the sum of these indicators:
Each eligible key contributes exactly one to the sum, and each ineligible key contributes zero. This equals the number of eligible keys because the set \(K\) contains each key once. If instead one sums over transaction rows, a key with \(r\) rows contributes \(r\) times whenever those rows are all marked eligible; that is a transaction count, not a claim count. Deduplicating at the claim-key level before summing is therefore a direct consequence of the quantity being measured.
Write down the period, coverage scope, contract trigger, cutoff date, and required key fields.
Check that dates, policy or coverage associations, and claim identifiers are present and internally consistent. Identify true duplicated rows using reliable source fields.
Group transaction rows by the validated key, retaining one logical claim even when it has many transactions or status changes.
Apply the stated trigger and coverage rules to each key. Count each eligible key once and record exclusions and unresolved cases.
Worked Examples
Worked Example: Coverage Eligibility and Repeated Transactions
A hypothetical property policy covers the period from January 1 through June 30, with dates represented as the half-open interval \([ \text{January 1}, \text{July 1})\). The analysis includes property claims only. The extract is complete through September 30. The claim number is unique within this policy. Determine the claim count from these records:
- Claim P-101: property loss February 12; one notice row, two payment rows, and one reserve-change row.
- Claim P-102: property loss December 29 of the preceding year; one notice row.
- Claim P-103: liability loss May 4; two transaction rows.
- Claim P-104: property loss June 30; one notice row and one closure row.
- Claim P-105: property loss July 1; one notice row.
Method. Form one key for each policy claim number, then apply the coverage and loss-date tests. P-101 has four rows but one key. Its loss date, February 12, falls inside the selected property period, so it contributes 1. P-102 has one key, but December 29 precedes January 1, so it contributes 0. P-103 has two rows, but it is liability rather than property, so it contributes 0.
P-104 has two rows but one key. June 30 is included because the coverage interval ends at the start of July 1, so P-104 contributes 1. P-105’s July 1 loss is outside the interval, so it contributes 0. The total is \(1+0+0+1+0=2\) eligible claim keys.
Check. The eligible keys are P-101 and P-104, so there are two. The common mistake avoided here is counting the six transaction rows for P-101 and P-104 as six claims, or excluding June 30 by misreading the period boundary.
Worked Example: Closed and Reopened Claims at a Data Cutoff
A hypothetical equipment coverage applies from January 1 through December 31. The occurrence-triggered analysis includes equipment claims with loss dates in that interval. The extract cutoff is March 31 of the following year. The records show:
- E-21: loss January 7; reported January 10; opened, closed, reopened, and closed again before the cutoff.
- E-22: loss November 20; reported November 25; closed January 15, then reopened February 10.
- E-23: loss December 30; reported December 31; closed January 20; reopened April 5, after the cutoff.
- E-24: loss August 8; reported August 9; one valid claim record appears twice because the same source transaction was loaded twice.
- E-25: loss October 2; first reported April 3, after the cutoff.
Method. Use the loss-period rule and the March 31 cutoff, then count each known eligible key once. E-21 has an in-period loss and was reported before the cutoff: include one key, regardless of its sequence of status changes. E-22 also has an in-period loss and was reported before the cutoff: include one key, even though it was open at the cutoff.
E-23 was reported before the cutoff and has an in-period loss, so it contributes one key. Its April 5 reopening is not in this March 31 extract and does not change the fact that the claim was already known. E-24 is eligible; the duplicated source transaction is one underlying record and does not create a second claim. E-25 is not in the data by the cutoff, so it contributes zero to this as-of-cutoff count. The total is \(1+1+1+1+0=4\).
Check. The four included keys are E-21, E-22, E-23, and E-24. The mistake avoided is treating “closed” as an exclusion rule or counting a reopened claim again. The cutoff concerns what the extract knows, not whether the latest status label is open or closed.
Worked Example: Claim Numbers Reused Across Policies
A hypothetical insurer’s system assigns claim numbers that are unique only within a policy. The selected coverage is collision, with the relevant periods and claims shown below. All listed claims were reported before the data cutoff.
- Policy R-31, claim 0042: collision loss March 3 during the policy’s January 1–December 31 coverage period; three transaction rows.
- Policy R-32, claim 0042: collision loss April 8 during its January 1–December 31 coverage period; two transaction rows.
- Policy R-31, claim 0043: collision loss December 31 of the preceding year; one row.
- Policy R-31, claim 0044: comprehensive loss July 7; two rows.
- Policy R-31, claim 0045: collision loss September 9 during the coverage period; one source transaction loaded twice.
Method. Since claim numbers are unique only within a policy, define the key using the policy identifier and claim number. The keys for the two claims numbered 0042 are therefore \((\text{R-31},0042)\) and \((\text{R-32},0042)\), not one combined key. Each has an in-period collision loss, so each contributes 1.
The key \((\text{R-31},0043)\) is excluded because its loss date precedes the coverage period. The key \((\text{R-31},0044)\) is excluded because it is comprehensive, not collision. The key \((\text{R-31},0045)\) is eligible and contributes 1; its duplicate loaded transaction does not create another key. Thus the count is \(1+1+0+0+1=3\).
Check. The three included keys are \((\text{R-31},0042)\), \((\text{R-32},0042)\), and \((\text{R-31},0045)\). A common wrong calculation is to count distinct claim numbers alone, which yields only 2 (0042 and 0045) and merges two different claims. The correction is to use the validated composite key.
Handling Duplicates Without Losing Real Claims
“Duplicate” should describe a verified data duplication, not merely two rows that look similar. Strong evidence includes the same source transaction identifier appearing twice because of a repeated file load. Identical policy, date, amount, and claim number can be a clue, but may not prove duplication: two genuine transactions can share those values. Keep an audit trail of which rows were removed and the evidence used.
It is also important to distinguish duplicate claim records from multiple claims that happen to share a field. Two policies may reuse a claim number, or a claim may have several valid transaction rows. A claim-level key should group the rows for one claim; a transaction-level key can help detect repeated imports. These are different tasks and should not use an unverified common field as a substitute for either key.
If an identifier is missing or changes over time, do not silently combine records based only on matching dates or amounts. Use documented linkage rules or send the case for review. An incorrect merge suppresses a real claim; a missed duplicate inflates the count. Both errors can affect the credibility of later analyses built from the data.
Common Mistakes and Practical Controls
- Counting rows instead of keys. A claim with several payments or status updates remains one claim under the stated key definition.
- Excluding closed claims. Closure is a status, not a general eligibility condition. Apply the stated period, coverage, and cutoff rules.
- Counting a reopening as another claim. A status change does not create a new key. Count the underlying claim once.
- Using the report date for an occurrence-triggered period test. Test the loss date against the coverage period; use report date for availability by the cutoff. Other contract triggers require their own rule.
- Removing similar-looking records without verification. Use source identifiers and documented checks to distinguish repeated loads from genuine transactions or claims.
- Assuming claim numbers are globally unique. Confirm their scope and build a composite key when needed.
A reproducible process should retain the original records, document the key and eligibility rules, and report counts of included, excluded, and unresolved keys. These checks make it possible to explain why a record was treated in a particular way and to rerun the count when corrected data arrive. The objective is not to make every ambiguous record fit a rule; it is to apply a clear rule consistently and expose cases that need judgment.
Check Your Understanding
For each problem, state the number of eligible claim keys under the given rules.
- A hypothetical glass coverage is in force from April 1 through September 30, inclusive. A claim with loss date September 30 has five transaction rows, and a second claim with loss date October 1 has one row. Both were reported before cutoff. How many claims are included? (Answer: 1)
- A hypothetical occurrence coverage runs from January 1 through December 31. Claim M-1 has an in-period loss and is reported before cutoff, but is closed with no payment. Claim M-2 has an in-period loss and is reopened twice before cutoff. Both have several transaction rows. How many eligible keys are included? (Answer: 2)
- A policy’s claim numbers are unique only within policy. Policies T-1 and T-2 each have an in-period eligible claim numbered 77, while T-1 claim 78 has a loss before the policy period. All are reported before cutoff. What is the eligible count when policy and claim number form the key? (Answer: 2)
- A covered claim with an in-period loss is reported on December 20. It is closed in January and reopened in February. The cutoff is March 31, and a duplicate import of one transaction is confirmed. How many claims are included at cutoff? (Answer: 1)
- A hypothetical occurrence coverage ends at the start of July 1. Claim A has a covered loss on June 30 and is reported July 10. Claim B has a covered loss on July 1 and is reported June 29 due to a data-entry error. Both appear in an extract with an August 1 cutoff. How many satisfy the stated loss-date rule? (Answer: 1)