Data validation software for actuaries checks claim and payment data between the claims system and the reserving tool: it profiles each extract, ties it to the general ledger, compares it claim by claim with last quarter, and holds any reserving segment that fails until a person releases it. It does not replace the reserving software, the claims data warehouse or the general ledger, and it should not write to any of them. The reason to buy it is timing. Reserving teams usually learn that an extract was wrong when a development factor looks odd, after the triangles are built and reviewed; checks that run the day the extract lands move that discovery to the start of the quarter. Botminds' Reserving Data Validation is built as that checkpoint: six agents read every source, explain each break with its claims, and pass only released segments to the tool the team already uses.
The examples below follow a fictional mutual insurer's third-quarter 2026 extract, 486,215 claims and 3,118,440 transactions in nine reserving segments, through the solution.
Where data validation sits: between the claims extract and the reserving tool
Agent
Extract lands from the claims data warehouseThe extract profiler reads counts, totals, field profiles, open-claim roll-forward, negative values and dates, per segment.
Never: edits the extract
Agent
Compared and tiedEach claim is matched to last quarter’s locked extract; paid and case reserves are tied to the general ledger; the change log is read for causes.
Never: posts or proposes journal entries
Agent
Hold pointA segment that fails a check stops here, with the reason in one line and the claims behind it. Triangles are built as extracted and as adjusted, for comparison.
Never: selects factors
A person decides
Reserving actuary releasesReleases each segment, restates for reserving, or keeps it held until claims data fixes the source.
Agent
Released segments go to the reserving toolOnly released segments reach the reserving workbook or software, unchanged in format; the data memo is drafted from accepted adjustments.
Never: sends a held segment
What is data validation software for actuaries?
It is software that tests whether the data an actuarial analysis will use is fit for that use, before the analysis starts, and leaves evidence of the test. The phrase is crowded in search results by two other things: the Data Validation feature in spreadsheets, which restricts what a user can type into a cell, and data-pipeline testing tools that check tables as they load. Neither compares a claims extract with last quarter's or with the general ledger, which is what reserving needs.
For property and casualty reserving the requirement is old and plain. The Casualty Actuarial Society's 1988 Statement of Principles on loss reserves, reprinted in Friedland's CAS study text, put it in one sentence:
Whatever data are used in analysis of reserves, they must reconcile to the insurer's financial records.
CAS Statement of Principles Regarding Property and Casualty Loss and Loss Adjustment Expense Reserves (1988), as reprinted by Friedland, CAS
Europe's Solvency II Directive turns the same idea into a governance requirement. Article 82 obliges insurers to "have internal processes and procedures in place to ensure the appropriateness, completeness and accuracy of the data used in the calculation of their technical provisions", and Article 48 makes the actuarial function "assess the sufficiency and quality of the data used in the calculation of technical provisions" (Directive 2009/138/EC). Data validation software is the process; its log and its data memo are the evidence that the process ran.
Where should data validation sit in the reserving process?
Between the extract and the first triangle, so that nothing is built from data nobody has checked. Three other places are common, and each is too late or too early. Checks inside the reserving workbook run after triangles exist, which means a failed check costs rework. Checks in the claims warehouse's load process catch broken files but not recodes, because the warehouse is consistent with the claims system by design. And the year-end reconciliation to Schedule P comes once a year, after three quarters of analysis.
A checkpoint at the start of the quarter also changes who hears about problems first. In the sample, the extract landed at 06:40; by 06:52 every segment had been checked, six were through, three were held, and the claims data owner had the claims behind a recode that moved 1,240 claims between two lines. The reserving software had not yet been opened.
Nine segments, eight checks each: through to the triangles or held
What does a hold point hold, and who releases it?
It holds a reserving segment, not the whole extract, and only a named person releases it. Segment-level holds matter because most quarters have one or two problems, and a team should not lose a day on Personal Auto because General Liability has a recode. In the sample configuration, a failed check holds a segment, a flagged one passes through with a note, and only the reserving lead releases segments or accepts adjustments. Restatements above $10 million and any change to segment definitions are listed for the appointed actuary.
Releasing is a decision with three outcomes: release as extracted, release with an adjustment for reserving, or keep holding until the source is fixed. The sample quarter used all three. The recode was restated to the prior coding for reserving, which released Commercial Auto and General Liability; Homeowners stayed held for 312 negative case reserves that claims data had to re-post as recoveries.
After a restatement: eight through, one held
Can data validation work with our reserving software?
Yes, because it sits in front of the reserving software and hands it what it already expects. The reserving tool keeps its methods, its factor selections and its exhibits; what changes is that the data it receives has been checked, and the segments it receives have been released by name. The output is the same shape the team uses now (claim-level data or triangles by segment, paid and incurred), delivered as extracted and, where the actuary accepted an adjustment, as adjusted, with the adjustments listed.
That design is deliberate. Reserving software is where judgment lives, and the profession's standards are written around it: ASOP No. 43 asks the actuary to consider whether "significant changes in conditions, particularly with regard to claims, losses, or exposures" are "likely to be insufficiently reflected in the experience data" (ASOP No. 43, section 3.6.7). A checkpoint that finds a recode or a migration effect informs that judgment; it does not make it. Monitoring how the released triangles then develop is a separate job, covered in actual vs expected in actuarial reserving.
What systems does data validation connect to?
Six sources, all read-only from the checkpoint's side. The claims data warehouse supplies the quarter's extract; last quarter's extract is locked and kept; the general ledger supplies paid losses and case reserves by close; Schedule P, Part 1 supplies year-end incurred; the system change log and the coding tables supply causes.
What the checkpoint reads, what it uses each source for, and what it writes back
| Source | What is read | Used for | Written back |
|---|---|---|---|
| Claims data warehouse | The quarter’s claim and payment extract | Profiling, roll-forward, triangles | Nothing |
| Last quarter’s locked extract | The extract the last triangles were built from | Claim-by-claim comparison; prior-diagonal check | Nothing; read-only, kept for 10 years in the sample configuration |
| General ledger | Paid losses and case reserves by account, for the close | Tie by segment; every difference named | Nothing; no journal entries posted or proposed |
| Schedule P, Part 1 | Year-end incurred by accident year | Year-end tie of the triangles | Nothing |
| System change and migration log | Tickets, dates, impact notes | The cause of each break, quoted | Nothing |
| Coding tables | Every version of the line-of-business mapping | Why claims moved; restating to a prior coding for reserving | Nothing |
Does data validation change the claims system?
It should not, and in Reserving Data Validation it cannot. The agents never edit source data, post journal entries or select factors. When the claims system is wrong, the fix is made there by the claims data owner, with a ticket; when the claims system is right on its own terms but wrong for the triangle, as with a deliberate recode that was never back-converted, the adjustment is made for reserving only and listed in the data memo. Keeping those two apart is what lets an auditor trace any triangle cell back to an unmodified source plus a named, approved adjustment.
How long does it take to set up data validation for reserving?
Weeks, not quarters, if the sources exist; the long pole is agreeing tolerances and releasers, not connecting systems. The plan below is our estimate for a team with a claims warehouse, a quarterly general ledger close and a change log, and it ends with the first live quarter run in parallel with the existing process.
An illustrative set-up: four weeks to a quarter run in parallel
- Connect sources, map segmentsWeek 1
- Back-run two closed quartersWeek 2
- Agree tolerances and releasersWeek 3
- Parallel run on the live quarterWeek 4
The back-run is the most valuable week. Two quarters the team has already closed come with an answer key: the breaks it found, when, and what they cost. Running the checks on them shows which breaks would have been held on day one, which tolerances produce false holds, and whether the change log is complete enough to explain what the comparison finds. The seeded-error test turns that week into a scored evaluation.
What to look for in data validation software, and where it does not fit
Look for the claim-level comparison and the evidence trail first; most other features are easy to add. Then be honest about fit. This kind of software earns its keep where extracts change under the reserving team: several lines, a claims platform that is migrated or patched, coding tables that move, more than one person between the claims system and the triangle.
Seven tests for data validation software in front of a reserving tool
- It compares every claim with last quarter’s locked extract
Totals and field rules miss recodes, renumbering and defaulted dates.
- It ties to the general ledger by segment, not only in total
Offsetting differences between lines net to nothing in total.
- It holds a segment, not the whole extract
One bad line should not delay the other eight.
- It writes nothing back to any source
Fixes at source, adjustments for reserving, never silent corrections.
- Its tolerances and releasers are settings you own
And a change shows what it would hold on today’s extract.
- It hands your reserving tool the format it already takes
Released segments, as extracted and as adjusted; no new modelling platform.
- It leaves a signed data memo and a replayable log
Data used, review performed, adjustments with claims, items noted, open items, limitations.
Where it does not fit: a single-line book with a few thousand claims, where the actuary can read the extract, gains little. Neither does a team without a stable claim identifier across quarters, which must fix that first, because no claim-level comparison can match what cannot be matched. And it is not a reserving engine, a data warehouse or a claims system; teams looking for any of those are looking for a different purchase. Signing is part of the design rather than an add-on, as the last screen shows.
The data memo is signed, with the meaning of the signature kept
What happens once the data is released (selecting factors, comparing actual with expected development, explaining movements to the reserving committee) stays in the team's reserving software and process. How the six agents divide the checks is set out in AI data validation tools for claims data, and the whole solution on the Reserving Data Validation page.
Questions people ask
Is data validation software the same as data reconciliation software?
Reconciliation is one of its checks. Data validation for reserving ties the extract to the general ledger and Schedule P, but also compares it with last quarter's extract claim by claim and tests field-level reasonableness; reconciliation software that matches two balances does only the first.
Who should own data validation software: actuarial, claims or IT?
The reserving team should own the checks, tolerances and releases, because it decides what reaches the triangles. Claims data owns the fixes at source and IT owns the connections. A tool owned by IT alone tends to test loads, not consistency with last quarter's triangles.
Can we build reserving data validation in SQL or Python instead?
Many teams script parts of it, and a control-total check or a general ledger tie is a few hundred lines. The harder parts to maintain are the claim-level comparison across migrations, reading the change log for causes, segment holds with named releasers, and a signed memo that lists every adjustment with its claims.
Does data validation software need a claims data warehouse?
It needs a repeatable extract with stable claim identifiers and the fields reserving uses; a warehouse makes that easier but is not essential. It also needs last quarter's extract kept unchanged, which is a discipline as much as a system.
Does data validation help with the year-end actuarial opinion?
It supplies evidence the opinion relies on: the data reviewed, the adjustments made and the tie to Schedule P, Part 1. The opinion itself is the appointed actuary's, and the reconciliation regulators expect is set out in the Schedule P reconciliation guide in this series.