How to test a rate revision before it goes live

A rate revision is a promise. The filing says what the premium will be from a given date. The policy system has to charge exactly that, for every risk the revision touches, from exactly that date. Most teams check that promise with a spreadsheet macro and a few dozen hand-picked quotes. This is a method that checks all of it.

Why hand-picked quotes miss the defects that matter

A typical revision changes a fraction of a table: say 150 rows out of 1,000, plus a handful of carrier deviations on top. A tester picks the scenarios they expect to be interesting. The defects that cost money are rarely in that set. They are:

• A row changed outside the revision. Someone edited a factor that the circular never touched.
• A row dropped. The new edition is missing a territory or class that the old one had.
• The wrong edition in force. Last year's edition is still selectable on the effective date, or the new one starts a day late.
• A deviation that stopped applying. The carrier's own adjustment was layered on the old base and never carried to the new one.

None of these throw an error. The system returns a plausible premium every time.

Step 1: Read the revision as data, not as a document

Start from the filed source as you received it: the bureau circular or your own filing, plus any deviation, plus the effective date. Turn the before and after tables into a change set: every row added, removed or changed, and the edition it produces.

Two rules keep this honest:

1. The reference is always the filing. Expected values come from the filed material, never from the system under test. If the answer key is copied from the system, the test can only agree with it.
2. Every row is accounted for. Map your columns once, through a declared mapping, so nothing is silently skipped.

Step 2: Generate a case for every changed row

For each changed row, generate a rating case that actually reads that cell, and compute its expected premium from the new edition. Add cases for policies either side of the effective date, because the date boundary is where editions get crossed.

The point is coverage you can state: these cases read these cells. Not "we ran 40 scenarios", but "every changed row was read by at least one case".

Step 3: Check which edition wins

For every state, line and date window, name the edition that should be in force and confirm it is the one the system picks. Active is not the same as in force. Competing editions, unfiled editions and orphaned editions are findings in their own right, before you compare a single premium.

Step 4: Grade the premium, to the cent

Rate each case in the policy system, the way your QA team already does, and compare. The bar is simple: the independent premium must equal the system's premium. Every case ends in one of three states:

Result	What it means
Match	The two premiums agree, to the cent.
Mismatch	They differ, and the report names the first rating step where the two calculations part ways, and the cells it read.
Open	Unexplained. It is listed, and never counted as passed.

A mismatch that names its step is the difference between "something is wrong" and "row 412's deviation factor did not carry into the new edition".

Step 5: Reconcile the tables row by row

Premium checks only see the cells your cases read. To catch the row changed outside the revision, export the system's rate tables and grade them cell by cell against the change set: as declared, missing, wrong value, or unexpected.

What this proves, and what it does not

Be precise about the claim. A revision check proves the system matches the filing on the rows the revision changes. Rows the revision does not touch are reported as baseline, not re-checked against the filing. A replay of an older circular against the edition in force before it surfaces disagreeing rows as candidates that a person classifies.

That precision is what makes the result something a VP of Pricing can sign and a regulator can read.

Questions rating teams ask

How many scenarios does a rate revision test need? Enough that every changed row is read by at least one case, plus the cases either side of the effective date. The number follows from the revision, not from a team's capacity to hand-write quotes.

Do we need API access to the policy system? No. Cases can be rated through the screens, through an adapter in a non-production environment, or exchanged as a sheet your team rates its usual way.

Can the expected values come from our current system? Only for the set-up baseline, and only for unchanged rows. For the revision itself, expected values must come from the filing, or the test cannot find a defect.