Reporting answers "now"; actuaries ask "as at then"
A reporting warehouse typically holds one row per claim with its current paid,
current reserve and current status. That answers every question a claims manager
has, and none of the questions an actuary has.
Reserving works by observing how a cohort of claims develops over time. You
take all claims from one accident period, and you look at what they were
believed to cost after twelve months, after twenty-four, after thirty-six, and
so on. The pattern in that development is what lets you estimate where a young
cohort will end up, and therefore what to hold for claims that have happened and
not yet been reported.
That requires the value as it stood at each past valuation date. A table
that overwrites the reserve as the adjuster revises it has destroyed exactly the
series the actuary needs. There is one row, it says 29,500, and nothing records
that it said 3,500 at the first year end and 30,000 at the second.
Which date does the claim belong to
Before anything else, establish which date the cohort is defined by, because
there are at least four and they routinely differ by years.
| Date | What it means | Used for |
|---|
| Accident date | When the loss occurred | The usual cohort for reserving |
| Report date | When the insurer was told | Reporting-delay analysis, IBNR shape |
| Transaction date | When a payment or movement was booked | Cash and financial reconciliation |
| Valuation date | The as-at point of the whole view | The column of a triangle |
| Underwriting year | When the policy was written | Reinsurance treaty allocation |
A claim from an accident in November, reported in February, paid across three
years, on a policy written the previous June, sits in a different bucket under
each of these. Building a cohort on the wrong one produces numbers that look
plausible and describe nothing.
The one that catches engineers is underwriting year, because reinsurance
treaties attach by the year the policy was written while claims arrive by
accident date, so a single payment can be split across structures negotiated
years apart.
What a triangle actually is
A development triangle is a grid: accident period down the side, development
period across the top, and in each cell the cumulative incurred (or paid) for
that cohort as at that point in its life.
Incurred, cumulative, in thousands
accident year dev 12 dev 24 dev 36 dev 48
2022 4,120 5,880 6,340 6,410
2023 4,460 6,210 6,690 —
2024 4,890 6,980 — —
2025 5,240 — — —
It is triangular because the recent cohorts have not lived long enough to fill
the later columns. The whole exercise is estimating those blanks from the
pattern in the completed rows.
Now read what one cell requires: the 2023 row, dev 24, is the incurred figure
for all 2023 accident-year claims as at the end of 2024 — not as at today.
Every claim's paid and reserve at a date two years in the past. Nothing in a
current-state table can produce that.
Two ways to make it available
Periodic snapshots. At each valuation date, write a complete copy of every
open and recently closed claim's figures, stamped with that date. Simple,
obviously correct, and the storage is unremarkable because claim counts are not
web-scale. This is what most carriers do, and quarter-end snapshots are the
common cadence.
A movement store. Record every reserve and payment movement as an immutable
row with both an effective date and a booked date, and derive any as-at view by
summing movements up to that point. More flexible — any valuation date, not just
the ones you snapshotted — and it demands discipline, because a single movement
inserted retrospectively without a booked date silently changes history that was
already reported.
The two combine well: movements as the source of truth, snapshots materialised
from them so the actuarial run is not recomputing the world.
What does not work is reconstructing from an audit log of table changes. Audit
logs record that a field changed, not what the business event was, they usually
lack the accident-period context, and they are frequently pruned. Several
programmes have discovered this at the point of needing the data.
Two complications worth raising unprompted
Reopened claims. A claim closed at zero and reopened two years later adds
cost to an accident period whose triangle rows were published long ago. The
figures for that cohort move after the fact, which is normal and has to be
visible rather than silently absorbed.
Large losses distort the pattern. One enormous claim in a small cohort makes
the development factor for that row meaningless, so actuaries typically analyse
large losses separately from attritional ones. That means the data has to be
sliceable by size band, and the threshold is a business parameter that changes —
so it must be applied at query time rather than baked into the extract.
The question to ask first
Before building anything, ask the actuarial team for the shape they want: which
date defines the cohort, which measure (paid, incurred, counts), gross or net of
reinsurance, which valuation dates, and which segmentation. Those five answers
determine the model, and they differ by line of business within the same
carrier.
Engineers who skip that and build "a claims extract" deliver something that gets
loaded into a spreadsheet and manually reshaped every quarter, which is the
outcome the project existed to prevent.
Reporting keeps the latest value. Reserving needs the value as it stood at
every past year end, and an overwrite is the one operation that makes it
unrecoverable.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).