This report checks the quality of the data submitted by officers in their weekly claims trackers, as at 27 July 2026. The goal is to catch data entry mistakes — wrong dates, missing information, inconsistent naming — before they affect the accuracy of the performance dashboards the team relies on.
Each section below explains in plain terms what is being checked and why it matters, followed by the actual records that need attention.
| Check | Count |
|---|---|
|
16 |
|
113 |
|
16 |
|
660 |
|
147 |
|
133 |
|
205 |
|
8 |
|
239 |
|
12 |
|
5 |
|
23 |
|
2 |
What this checks: Some columns calculate “how many days did this step take” by subtracting one date from another. If an officer enters dates in the wrong order in Excel, this subtraction produces a negative number — which is impossible. You cannot take “-3 days” to assess a claim.
Why it matters first: Every other calculation in the dashboard — averages, delay rates, SLA comparisons — depends on these numbers being correct. A negative value silently distorts every report built on top of it, which is why this is checked before anything else.
Note: The dashboard automatically converts negative numbers to zero so they do not break the charts. This means the table below shows you which officer, claim, and column had the problem, but not the original wrong number itself — that gets overwritten before this check ever sees it.
What this checks: Certain events must happen in a specific order — for example, a Repair Authority cannot be issued before the assessor’s report was received. This check looks for cases where the dates say otherwise.
Why it matters: If dates are out of order, it usually means a date was typed into the wrong field, or the wrong date was copied from a different claim entirely. The Date 1 and Date 2 columns show the two dates that are in conflict, and the Label columns identify which field each date came from.
What this checks: How long a claim has been open, from the loss date to the repair authorisation date. A reasonable claim should fall between 0 and 120 days. Anything outside that range is unusual enough to warrant a second look — it might be a genuinely difficult claim, or it might be a typo in one of the dates.
What this checks: Whether the officer has recorded what stage a claim is currently at (e.g. “RA Issued”, “Repairs Ongoing”, “Closed/Settled”). If this field is left blank, the claim cannot be tracked properly in the workflow charts.
Why it matters: A claim with no status simply disappears from the stage breakdown views — it is not wrong data exactly, it is missing data, and it needs the officer to go back and fill it in.
What this checks: Claims missing the absolute basics needed to process anything at all — no claim number, no officer name, or no loss date. Where the claim number is missing, the vehicle registration number is provided as a fallback so the record can still be located in the officer’s Excel file.
What this checks: Whether the Claim No field contains an actual claim number in the expected format (C-YYYY-UNIT-CLASS-NUMBER), or whether the officer has typed in a note instead — most often because the claim number has not yet been issued at the point of entry.
Why it matters: These claims cannot be tracked or matched against any other report using a claim number, since the field does not contain one. The officer needs to follow up and update this field with the proper claim number once it becomes available. This is not an error on the officer’s part — it is a flag to prompt follow-up.
What this checks: Whether the same claim number appears more than once across all officer trackers. This usually means either the same claim was entered twice by mistake, or a claim number was accidentally reused for two genuinely different claims.
What this checks: Whether a loss date or report date is set sometime after today — which is impossible, since a claim cannot be reported before it happened.
What this checks: Claims where a stage shows “0 days” — meaning it was apparently completed on the very same day it started. This is possible in genuine fast-track cases, but worth a second look, especially if the same officer has many of these, since it can also mean two dates were accidentally entered as identical.
Note: This check only applies to claim types where a non-zero TAT is genuinely expected — Third Party, Windscreen, and Not Claiming claims are excluded since they do not go through the standard assessor or repair process and would always show zero.
What this checks: Every claim number contains a 4-digit code that tells us whether the policy is Motor Private or Motor Commercial. This check finds any code that has appeared in the data but has not yet been added to our classification list — meaning it currently shows up as “Unknown” instead of being correctly classified.
Action required: Any codes appearing here should be
added to the MOTOR_CLASS_MAP in the main R script with the
correct classification.
What this checks: Dates typed with an extra digit, a
missing digit, or a double slash — for example 15/010/2026
instead of 15/01/2026. These cannot be read as valid dates
at all, so without this check they would silently disappear from every
TAT calculation without anyone noticing.
Action required: Each entry below needs to be corrected in the officer’s Excel tracker. The Raw Value column shows exactly what was typed so the officer can identify and fix the specific cell.
What this checks: Status values entered by officers that do not match any of the recognised standard statuses in our classification list. These are currently labelled “OTHER” in the dashboard, which means they are not being counted in any of the stage breakdowns correctly.
Action required: Review the raw values below and
decide the correct standardised label for each. Once decided, add the
mapping to STATUS_MAP in the main R script so future
entries are automatically corrected.
What this checks: Damage type values entered by officers that do not match any of the recognised standard damage types. These are currently labelled “OTHER” in the dashboard charts, which means they are not being classified correctly in the claim type mix.
Action required: Review the raw values below and
decide the correct standardised label for each. Once decided, add the
mapping to DAMAGE_TYPE_MAP in the main R script.
Report generated automatically from officer tracker data. For queries contact the Actuarial Services & Research department.