Why Claim-Level Data Matter
Berquist-Sherman adjustments use information about individual claims to investigate whether changes in observed paid or incurred experience reflect changing claims practices rather than only underlying loss emergence. A triangle cell shows an aggregate amount at an accident period and development age. It does not, by itself, identify which claims were open, when they closed, or how much each claim had been paid or held as a case reserve. Those details must come from claim-level records.
For this work, data must be both detailed enough to support the intended analysis and consistent with the aggregate loss data being reviewed. A file can contain many fields and still be unsuitable if, for example, its payments are on a different gross or net basis from the triangle, its valuation cutoff is unclear, or closed claims have been assigned inconsistent status codes. The data specification is therefore part of the actuarial method, not just an administrative step.
The concepts here are aligned with the CAS Exam 5 (Basic Ratemaking and Estimated Claim Liabilities) syllabus. All examples use hypothetical insurance claims and amounts.
Specify the Data Before Aggregating
A useful data request states the unit of each file and how each field is defined. Some systems provide one row per claim per valuation; others provide a transaction ledger with one row per payment or reserve change. These are different data structures. Payment transactions must be accumulated through the valuation date to obtain cumulative paid amounts, while a claim snapshot should already show the cumulative amount as of its stated valuation.
| Field group | Examples of required fields | Why it matters |
|---|---|---|
| Claim identity and scope | Stable claim identifier; policy, coverage, or line identifier; currency; gross or net basis | Supports deduplication and ensures that the records represent the same business as the triangles. |
| Accident information | Date of loss; assigned accident period; period-assignment rule | Places each claim in the correct accident period. |
| Valuation information | Snapshot valuation date, or transaction date and a clear cutoff convention | Determines which information belongs in each observed valuation. |
| Payments | Cumulative paid loss at snapshot, or dated payment transactions, including corrections and reversals | Allows paid amounts to be calculated consistently through the valuation cutoff. |
| Case reserves | Outstanding case reserve at snapshot, with a documented definition | Provides the case-reserve component needed to calculate incurred amounts. |
| Claim status | Reported status as of valuation, such as open or closed; status effective date | Describes the claim at the valuation rather than at an unrelated later date. |
| Closure information | Closure date; reopening date or indicator, if applicable | Permits closure status at each valuation to be checked against the claim history. |
The operational definitions matter. “Paid” might include loss payments only, or it might include specified claim-related amounts; it might be gross of recoveries or net of them. “Case reserve” might include only a particular reserve component. The claim-level data and aggregate triangles must use the same definitions, currency, coverage scope, and gross or net basis. If they do not, a numerical difference may reflect a scope mismatch rather than an error in summation.
At a given valuation, let \(C^P_{i,j}\) denote cumulative paid loss for accident period \(i\) at development age \(j\), and let \(C^R_{i,j}\) denote the corresponding outstanding case reserve. When the triangle definitions are compatible, incurred loss is calculated as:
Here, the superscript \(I\) denotes incurred, \(P\) paid, and \(R\) case reserve. This identity concerns the specified loss basis; it does not imply that every data source uses the same definition of loss or reserve.
From Claim Records to Triangle Cells
For a claim-snapshot file, first select the records at the required valuation, assign each claim to its accident period, and sum paid and case reserve separately within each accident-period and development-age cell. For a transaction file, first select eligible transactions through the cutoff and accumulate them by claim. Apply the same accident-period and valuation rules to both approaches. Do not sum multiple snapshots together: doing so would count the same cumulative payments more than once.
Specify the accident-period assignment, valuation date, development age, coverage scope, and paid and reserve basis.
For snapshots, use the amount reported at the selected valuation. For transactions, accumulate eligible payment entries through the cutoff, including valid reversals or corrections.
Assign each included claim to the appropriate accident-period and development-age cell; total paid and case reserve separately.
Compare claim-level totals with the corresponding aggregate paid and reserve data, and resolve differences before interpreting the experience.
The aggregation identity follows directly from addition. If \(S_{i,j}\) is the set of claims assigned to cell \((i,j)\), and claim \(k\) has paid amount \(P_k\) and case reserve \(R_k\) at that valuation, then the cell totals are \(\sum_{k\in S_{i,j}}P_k\) and \(\sum_{k\in S_{i,j}}R_k\). Adding the two cell totals gives:
Thus, if claim-level and aggregate data have the same claim population, valuation, and definitions, the total of claim-level incurred amounts must equal aggregate paid plus aggregate case reserve. A failure to reconcile signals that at least one of those conditions may not hold, or that the data contain an error.
Worked Example: Building Two Incurred Triangle Cells from Snapshots
A hypothetical insurer supplies claim snapshots for accident year 2024 at December 31, 2024 (12 months of development) and December 31, 2025 (24 months). All amounts are dollars, cumulative paid amounts are shown, and case reserves are outstanding at the snapshot date. Determine the paid, case-reserve, and incurred totals at each valuation.
Method. Treat each valuation as its own snapshot. Sum paid and case reserves separately by valuation, then add the two totals to obtain incurred.
At December 31, 2024, Claim A has paid \(10{,}000\) and a case reserve of \(15{,}000\). Claim B has paid \(8{,}000\) and no case reserve. Therefore:
The 12-month incurred total is \(18{,}000+15{,}000=33{,}000\).
At December 31, 2025, Claim A has paid \(18{,}000\) and a case reserve of \(7{,}000\); Claim B has paid \(8{,}000\) and no case reserve; and Claim C, first present in this later snapshot, has paid \(4{,}000\) and a case reserve of \(6{,}000\). Thus:
The paid amount increased from \(18{,}000\) to \(30{,}000\), while the case reserve changed from \(15{,}000\) to \(13{,}000\). The incurred total is \(43{,}000\), not the change in paid plus the later case reserve. As a check, the 24-month claim-level incurred amounts are \(25{,}000\), \(8{,}000\), and \(10{,}000\), which sum to \(43{,}000\). The common mistake avoided is adding the two snapshots together, which would count earlier cumulative payments a second time.
Transaction Detail, Cutoffs, and Claim Status
A transaction ledger requires extra care because a transaction date and a snapshot valuation date are not interchangeable. To construct paid loss at a valuation, include eligible payment transactions dated on or before the stated cutoff, net of valid corrections and reversals. Do not include a transaction merely because it appears in a file extracted after the cutoff. In addition, retain a stable transaction identifier where possible: duplicated transaction rows can inflate cumulative paid amounts even when the claim identifier is correct.
Status and closure information should also be valuation-specific. A claim that is closed at a later valuation may have been open at an earlier one. A closure date is useful for checking that history, but it should not be substituted for the status recorded at a different snapshot. If reopenings are possible, a single unqualified “closed” flag may be insufficient to describe the claim at every valuation; obtain the relevant status history or snapshot values.
Worked Example: Accumulating Transactions and Checking the Reserve
A hypothetical claim has three payment-ledger entries through June 30: \(1{,}200\) on April 8, \(800\) on May 19, and a correction of \(-200\) on June 2. Its case reserve at June 30 is \(700\). A separate claim has paid \(500\), a zero case reserve, and a closure date of June 20. Find the June 30 cell totals.
Method. Accumulate the dated transactions for the first claim, then add the second claim’s snapshot amounts. The negative entry is a correction and must reduce paid loss.
For the first claim, cumulative paid is \(1{,}200+800-200=1{,}800\). Its incurred amount is \(1{,}800+700=2{,}500\). For the second claim, incurred is \(500+0=500\). Therefore the cell totals are:
The result reconciles by claim as well: \(2{,}500+500=3{,}000\). The second claim is shown as closed at this valuation because its closure date precedes June 30. The common mistake avoided is dropping the negative correction, which would overstate paid and incurred by \(200\).
Worked Example: Applying a Valuation Cutoff
A hypothetical accident-year cell is valued at December 31, 2025. Claim K has a \(5{,}000\) payment dated December 30, another payment of \(900\) dated January 2, 2026, and a December 31 case reserve of \(2{,}000\). Claim L has a \(3{,}000\) payment dated December 30, a zero case reserve, and a closure date of December 30, 2025. Claim M relates to an accident on December 29, 2025, but was first reported on January 3, 2026. Determine the cell totals as of December 31, 2025.
Method. Include only information belonging to the specified valuation and claim population. The January 2 payment is after the cutoff, and Claim M had not been reported by the cutoff.
Claim K contributes \(5{,}000\) paid and \(2{,}000\) case reserve. Claim L contributes \(3{,}000\) paid and zero case reserve; it is closed at this valuation because its closure date is December 30. Claim M contributes no reported-claim record to the data as of December 31 under the stated reporting convention. Therefore:
The check is that the two included claims have incurred amounts \(7{,}000\) and \(3{,}000\), summing to \(10{,}000\). The common mistake avoided is using information after the valuation date to alter the earlier snapshot.
Reconciliation and Practical Controls
Reconciliation should be performed for each relevant accident-period and valuation cell, not only for a grand total. A grand total can hide offsetting differences—for example, an omitted claim in one period and a duplicate claim in another. Compare paid, case reserve, and incurred separately where the aggregate source permits. Record the basis of comparison, the size and direction of any difference, and how it was resolved.
A practical control sequence is to confirm that claim identifiers are unique at the intended file grain, check that accident dates map to the assigned accident periods, verify that transaction dates respect the cutoff, and compare claim counts and amounts with the aggregate source. Then inspect open and closed status against case reserves and closure dates. A zero reserve on a closed claim may be expected, but the data specification should not assume that all claims with a zero reserve are closed. Different systems may use zero reserves for open claims as well.
- Duplicate or missing records: compare distinct claim counts, transaction identifiers, and record counts with the source totals.
- Wrong valuation: confirm that each snapshot is labelled with its actual valuation date and that later transactions have not entered an earlier cumulative total.
- Inconsistent basis: confirm matching currency, coverage, gross or net treatment, and definitions of paid loss and case reserve.
- Incorrect accident-period assignment: trace a sample of records from date of loss through the assigned period, using the agreed period rule.
- Unresolved differences: document known exclusions and explain any remaining difference rather than forcing a reconciliation by an unexplained plug.
The purpose of these checks is not to make claim records mechanically equal an aggregate triangle at any cost. It is to establish whether both sources measure the same population, at the same valuation, on the same basis. Only after that is clear can claim-level patterns be interpreted responsibly for adjustment work.
Check Your Understanding
For each hypothetical situation, calculate the requested amount or identify the appropriate treatment. Assume all amounts are dollars and use the stated valuation cutoff.
- At a valuation, two claims have cumulative paid amounts of \(4{,}250\) and \(1{,}750\), and case reserves of \(2{,}000\) and \(0\). What are the paid, case-reserve, and incurred totals? (Answer: paid \(6{,}000\); case reserve \(2{,}000\); incurred \(8{,}000\).)
- A claim has payment transactions of \(900\), \(600\), and a valid reversal of \(100\) through the valuation date. Its case reserve is \(400\). What are cumulative paid and incurred? (Answer: paid \(1{,}400\); incurred \(1{,}800\).)
- At a March 31 valuation, one claim has a \(700\) payment dated March 30 and a \(300\) payment dated April 2; another has a \(500\) payment dated March 31. The total case reserve at March 31 is \(600\). What are the cell paid and incurred totals? (Answer: paid \(1{,}200\); incurred \(1{,}800\).)
- At a later snapshot, two claims in one accident-period cell have paid and case-reserve amounts of \(6{,}000\) and \(1{,}500\) for Claim A, and \(2{,}000\) and \(3{,}500\) for Claim B. Calculate the cell totals and verify incurred by summing claim-level incurred amounts. (Answer: paid \(8{,}000\); case reserve \(5{,}000\); incurred \(13{,}000\), also \(7{,}500+5{,}500=13{,}000\).)
- An aggregate cell reports paid of \(24{,}000\) and case reserve of \(6{,}000\). The matching claim-level extract totals paid of \(22{,}500\) and case reserve of \(6{,}500\). What is the aggregate incurred total, the claim-level incurred total, and the incurred difference? (Answer: aggregate incurred \(30{,}000\); claim-level incurred \(29{,}000\); aggregate exceeds claim-level by \(1{,}000\).)