Date of loss, date reported, date received: three fields that are not the same field

A claim record needs 3 separate date fields because 3 separate things happened. The loss occurred. Somebody gave notice of it. Your system took receipt of that notice. On a straightforward motor claim reported the same afternoon, all 3 land on one day and the distinction looks academic. On the claims that cause trouble — a leak discovered in March that started in November, a notice given to a broker who forwards it a fortnight later, a voicemail at 23:40 on a Friday — they are days or months apart, and each one is load-bearing for a different decision.

The failure this prevents is quiet. A system that stores 2 dates, or that overwrites one with another, still produces claim files that look correct. What it produces alongside them is a coverage test run against the wrong day, a late-notice question nobody can answer, and service clocks that started at a time you cannot evidence.

Three moments, three different owners

The cleanest way to keep the fields apart is to ask who is entitled to set each one. Two of the three are assertions made by people, and one is a fact your own system generates.

The third row is the one to protect hardest, because it is the only one you fully control and the only one you will be asked to evidence. It should be written once, by the system, at the moment of receipt, and never be editable by a user — including the user who is fixing a genuine mistake in one of the other 2 fields.

Date of loss is the opposite: it is a claim about the world, made by somebody who may be guessing. Treat it as versioned rather than fixed. Every change needs the previous value, who changed it, when, and on what evidence, because moving a loss date by 2 days can move the claim across a renewal boundary into a different policy with different limits — and the file needs to show that this happened on purpose.

Which clock starts on which date

Service deadlines and coverage questions run on different fields, and mixing them is the single commonest defect in an intake data model.

• Coverage runs on the loss date. The in-force test asks whether the policy responded on the day the damage happened, not on the day you heard about it. A lookup run against today's date will return nothing for a valid claim on a lapsed or renewed policy, which is one of the causes behind a policy lookup that returns nothing for a covered loss.
• Late-notice questions run on the reported date. Policy conditions requiring prompt notice are measured from when notice was given, not from when your system indexed it, so a broker who held a notice for 11 days has created an exposure that lives with the agency rather than the insured.
• Service clocks run on the received date. Acknowledgement and contact obligations are counted from receipt, which is why receipt has to be a system-generated instant rather than a keyed value.
• Reserving and development statistics need both loss and reported dates. Accident-year and report-year views of the same book answer different questions, and a record holding only one date can only produce one of them.

The losses that do not have one date

A substantial share of property claims have no single moment of loss. Water has been escaping behind a wall for 7 months. A subsidence crack widened over 2 winters. A theft happened at some point during a 3-week absence. Forcing a single value into the loss-date field on these files does not simplify anything; it moves the ambiguity somewhere nobody can see it.

1. Store a loss period as 2 fields, an earliest possible and a latest possible date, and let them be equal on the ordinary claim where the loss happened at a known moment.
2. Store the discovery date separately. It is a real, knowable fact — the day the insured found the damage — and it is frequently the only date the reporter can give you with confidence.
3. Store how the period was determined: reporter's estimate, adjuster's assessment, engineer's or surveyor's report, weather data for a named event. The basis matters more than the value once anyone disputes the file.
4. Derive the single date used for the in-force test rather than typing it. Whatever your rule is — earliest possible date, date of discovery, the date a named peril occurred — write it down, version it, and record on the claim which rule produced the value.
5. Never write the discovery date into the loss-date field as a shortcut. On a theft found after a 3-week holiday it silently relocates the loss into a later policy term, and the file gives no sign that a substitution took place.
6. Flag the file as date-uncertain, and let triage see the flag. A loss period spanning a renewal is a coverage question at first notice, not a discovery for the adjuster in week 3.

Photographs supplied with the notice carry their own capture timestamps, and it is tempting to treat those as evidence of the loss date. They are evidence of when a photograph was taken, which is a different fact and frequently a much later one — and on gallery uploads the metadata is often stripped or belongs to an unrelated image, one of several reasons damage photos arrive unusable from the loss report.

Twenty-one hundred on the thirty-first

Dates are not days. A notice given at 21:00 on 31 March in one timezone is 1 April in another, and if your intake stores a date rather than an instant, the month it belongs to depends on which server formatted it. That moves files between monthly reporting periods, and on a loss date it can move a claim across a renewal that took effect at midnight.

• Store instants, with the originating timezone alongside. The instant answers what happened first; the local timezone answers which business day it was for the person reporting, and both questions get asked.
• Decide whose calendar day a deadline runs in — the insured's, the handling office's, or the state of the policy — and apply it consistently. Any of the 3 is defensible; changing between them by accident is not.
• Treat out-of-hours notice as notice. A voicemail left at 23:40 on a Friday with an answering service acting for the carrier was given on Friday. If your system stamps received as 09:05 on Monday, you have created a 57-hour gap that exists only in your own data model, and it is the version an examiner will read.
• Keep the earliest reported date when files merge. Duplicate notices for one event produce 2 received dates and sometimes 2 reported dates, and the merged file must keep the earliest of each — which is one of the things that makes one loss opening two claim numbers more than a tidiness problem.

One date decides which policy responds. One decides whether notice was late. One decides whether you were on time. A record that stores two of them is answering the third from memory.

This is also the part of the record an audit walks straight to: given a file, show when notice arrived, when the clock started, and what the system did next — the shape of request set out in what an examiner will ask your system to produce. The distinction is not unique to insurance either; event time against system-receipt time is the same split that decides whether a delivery exception is real or an artefact of when a scan uploaded, which AI in logistics operations works through in a different setting. When we build intake with AI agents and automation, these 3 fields are fixed before any routing logic is written, because every rule downstream reads at least one of them. The rest of claims intake, FNOL and triage — what a notice must carry, how files are scored and routed — assumes they are stored separately, and the wider picture sits in our insurance and claims work.

• claims intake
• FNOL
• data model
• claim dates