Technical reserve and the close: why an insurer's month never lands on time

An insurer’s close has a step that exists in no other industry: calculating how much the company owes for claims that have not happened yet — or that happened and nobody reported. That is the technical reserve, and it is why an insurer’s close almost never lands on time.

In most companies, the close waits for the last posting. In an insurer, it waits for a number nobody has — it has to be estimated, and the estimate depends on data that arrives late by the nature of the business.

In one sentence — an insurer’s close is not late because systems are slow: it is late because part of the result is estimated, and estimating requires a calculation round, review and sign-off that most ERPs do not model as a process.

Why the number is not ready

The claim reported later. An accident in January may be reported in March. Until it is reported, it exists as an obligation and does not exist as a record — and the reserve has to cover it anyway.

The value that changes after it is estimated. A claim’s first estimate rarely survives assessment. The value rises, falls, and every movement reopens the reserve of a period that already closed.

The dependency on external data. Regulation, reinsurance and co-insurance bring numbers from outside, on their own calendars. The accounting close waits for them, and they do not wait for the close.

Reporting to the regulator. Beyond the balance sheet there are periodic filings to the supervisory body with their own deadline — which rarely coincides with the accounting close, and whose numbers have to agree with it.

why an insurer's close waits: the result depends on reported claims, claims incurred but not reported, value re-estimates and external reinsurance data — four inputs with different calendars that must converge on a single date — Four inputs with their own calendars, one closing date. The delay is not IT’s — but IT is what can make it visible early.

Where a standard rollout gets stuck

The reserve treated as a posting, not a process. A generic ERP models the final value: you enter it, it posts. What is missing is the round — estimate version 1, review, version 2, sign-off. Without that, every re-estimate becomes a manual posting with no trace of who changed what and why.

The reconciliation nobody automated. What the claims system says, what accounting recorded and what was declared to the regulator have to agree. When they do not, the difference is hunted in a spreadsheet, at the end of the deadline, by the person with the least time.

The close with no visibility of dependencies. On the eve, nobody can say what is still missing. Everyone waits for everyone, and the real bottleneck is only identified after it already cost two days.

The retroactivity that reopens a closed period. Re-estimating an old claim affects a prior period. Without a written rule on where the adjustment lands, every case becomes a new decision — made in a hurry, during the next close.

Worth deciding early — three decisions that must be written down before any automation: where the adjustment lands when a re-estimate affects a closed period; who signs off the reserve — a name, not a department; and which number prevails when the claims system diverges from accounting. The third is the one nobody writes, and it decides whether the close holds a debate or a lookup.

What fixes it, in order

1. Model the reserve as a round, not a value. Each version with its date, its calculation basis and its owner. It is more work during the rollout and it is what turns a re-estimate into processing instead of an argument.

2. Make dependencies visible before the deadline. A simple board answering, at any point in the month: what arrived, what is missing, and who is waiting for what. That moves the close from reactive to observed — and it is the cheapest change of all.

3. Reconcile the three numbers continuously, not at the end. Claims, accounting and what goes to the regulator need comparing during the month. A divergence found on the 10th is a question; the same divergence on the 30th is a crisis.

4. Write the retroactivity rule. Where the adjustment lands, in which period, with which document. Approved by accounting and tested with a real case before it counts.

5. Treat the regulatory filing like a tax filing. Automated generation, validation before submission, comparison against the previous period and evidence kept. It is the same reasoning we apply in simulating tax filings before transmitting.

Where AI genuinely helps here

The actuarial calculation belongs to the actuary and stays there — nobody wants a language model deciding a provision. But three expensive parts of the close are reading and comparing.

Explaining the divergence between the three numbers. Comparing bases and proposing where the difference sits shortens the investigation from days to hours. It is the same kind of reconciliation we describe in the banking cycle: every step with its own confirmation.

Reading the claim notice and extracting what the system needs. Free-text documents, with attachments, arriving through different channels — reading at volume, with mandatory human review.

Validating the regulatory filing before submission. Layout, totals and coherence against the previous period.

Where it does not belong: calculating the reserve, signing off the close and signing the regulatory filing. Those three stay with people, with names and with accountability — and in the reserve’s case, with a professional registration.

The honest limit

None of this makes claims get reported sooner, reinsurance answer faster, or assessments conclude earlier. Those are facts of the sector, not defects of the system. An insurer will keep closing with an estimated portion — that is the nature of the business.

What changes is where the time goes. With the reserve modelled as a round, dependencies visible and reconciliation continuous, the close becomes a sequence with checkpoints. Without that, it becomes an all-hands effort — every month, with the same people, hunting the same difference.

And there is an effect that only appears later: once the number has a version, a date and an owner, the conversation with the auditor changes in nature. It stops being reconstruction from memory and becomes a lookup.

If the starting point is understanding what exists today before deciding what to change, start with the IT diagnostic. For the sector overview, see IT for insurers. And if the immediate pain is data arriving broken from a legacy system, the path is classifying the failure before fixing it.