All articles Reserving

Why Actuarial Reserving Models Break in Spreadsheets

Kim Sung-jun 7 min read
Spreadsheet grid representing actuarial modeling complexity

The failure mode is almost always the same. Not a formula error caught before production. Not a data import that clearly broke. The failure that costs actuarial teams the most time is quieter: the model running in production is not the model the documentation describes. The divergence accumulated slowly, one quarter at a time, and nobody noticed until an examiner asked a question that required tracing backward through two years of close cycles.

This piece is about how that divergence happens, why spreadsheets are structurally prone to it, and what the cost looks like in practice. It is not an argument that spreadsheets are bad tools. They are excellent tools for what they were designed to do. The problem is that reserving at a carrier with multiple lines, multiple regulatory obligations, and a recurring quarterly cycle puts demands on the medium that the medium was not designed to meet.

The Version Drift Problem Is Structural

Most reserving teams work from a base model built and reviewed at some point in the past, often during an actuarial review or a regulatory examination cycle. That model gets modified each quarter: a new accident year row is added, a development factor updated, a formula adjusted to handle an edge case in the marine line that did not exist when the model was first designed.

Over twelve to eighteen months, the model in use still resembles the reviewed version but is not that version. The structural drift happens in layers. The first modification is usually minor and clearly justified. By the time the model has had six or eight seasonal iterations, the formula logic across several sheets may have been touched by three different actuaries, with the most recent changes made under the time pressure of a quarterly close. The reviewed model and the running model have diverged, and the documentation still describes the older version.

This matters most when regulatory review depends on consistency between documented methodology and actual calculation. When an examiner asks how development factors for the casualty auto line were selected in Q2, the answer should come from a system record. When it comes from re-reading formula cells and cross-referencing email threads, that is a signal that something structural has gone wrong.

When the Reviewed Model Stops Being the One Running

After any formal sign-off cycle, the clock starts on the next divergence. A calculation issue is found in the marine tail factors, identified during the Q3 close. The error is corrected, the fix is made directly in the production workbook, and the Q3 output is delivered on schedule. No new formal review is triggered because the fix is considered minor. The Q4 model runs on the corrected workbook.

Twelve months later, a regulatory examination reviews the documentation from the last formal sign-off. That documentation describes the pre-correction tail factor methodology. The figures produced in Q3 and Q4 and Q1 of the following year all used different logic than the documentation states. This is not a hypothetical. It is the normal operating condition of a team where the sign-off cycle and the modification cycle run at different frequencies with no mechanism to link them.

The spreadsheet itself offers no protection against this. There is no version lock, no change log, no mechanism that requires a formula change to be accompanied by a documentation update or to trigger a review checkpoint. The tool is agnostic about what was changed, when, and by whom.

Manual Linkages as a Recurring Failure Surface

Non-trivial reserving workbooks typically draw from multiple sources: a data export from the claims system, a rate change history file, sometimes a separate assumptions workbook maintained by a different team member. These connections are built with cell references that work while file paths and naming conventions stay stable.

They break when a new actuary reorganizes the folder structure for clarity. They break when a file is renamed to add a date suffix. They break when the shared network drive is restructured during an IT migration. The break is usually noticed within the hour and fixed manually: open the workbook with reference errors, find the broken cells, re-link to the new location. The fix takes thirty minutes and life continues.

What is not recorded is which cells were re-linked to which files, when, and whether the re-link pointed to the correct source. When an auditor later asks to trace the reserve calculation, the manual re-link history is simply not available. This is not negligence. It is the natural result of using a tool that does not capture provenance automatically.

Reconstructing an Audit Trail After the Fact

When a regulator, internal auditor, or appointed actuary asks for the full calculation trace from raw triangle data to final reserve figure, a spreadsheet-based team assembles the answer from whatever records exist. The actuary who ran the model remembers which version of the data file fed into the Q2 calculation. The email thread from the close week contains the exported triangles. The reserve memo describes the method but does not document every assumption that went into the tail selections.

This reconstruction process takes time that would not exist if the system had logged every step automatically. For teams that participated in our early-access program, assembling a complete calculation trace for a single line of business for one quarter typically required the better part of a working day, assuming no key personnel had changed. For a regulatory examination covering two or three years across six to eight lines, the documentation preparation phase consumed three to five weeks of actuarial time. None of that time was spent on model judgment. It was spent on archaeology.

This Is Not a Skill Problem

We want to be direct about this: the actuaries building and running these models are not making avoidable mistakes. The version drift problem, the manual linkage problem, and the audit trail reconstruction problem arise from properties of the spreadsheet medium applied to a recurring, regulated workflow at scale. A spreadsheet is an excellent calculation and exploration tool. It is not designed to enforce version control, maintain provenance across linked files, or automatically log every formula change with a timestamp and author identity.

We are not saying spreadsheets should never be used in actuarial work. Exploratory analysis, scenario testing, ad hoc calculations, and communicating model results to non-technical stakeholders are all areas where spreadsheets continue to be genuinely useful. The problem is using them as the production system for a quarterly close process that carries regulatory and financial reporting obligations.

What the Problem Costs in Practice

The cost has two parts. The direct cost is measurable: actuarial team time spent on version management, linkage maintenance, and documentation reconstruction rather than on actual model work. For a team of four or five actuaries at a property and casualty carrier running six to eight lines, we estimate conservatively that 20 to 25 percent of close-cycle time goes to these process overhead activities. For a team billing at market rates, that represents a meaningful fraction of the annual actuarial function budget consumed by infrastructure friction rather than analysis.

The second cost is harder to quantify and more significant from a risk perspective. When documented methodology and running model have silently diverged, the inconsistency may not surface until a stress event: adverse reserve development, a change of appointed actuary, a targeted examination. The conversation with a regulator becomes substantially harder when the audit trail is incomplete, and the regulator's first question cannot be answered from a system record.

The direct cost is recoverable. The regulatory risk from documentation gaps is a different category of problem, one that justifies the infrastructure investment required to avoid it. That is the calculation that drove us to build HyperCal the way we did: with version history and audit trail capture as foundational properties of the system, not features bolted on afterward.

Related articles