Why Claim Dates Need to Be Distinguished
A claim history can contain several dates that look like competing answers to the same question. They are not interchangeable. One date may record when an event caused damage, another when an accident injured someone, another when the insurer learned of the claim, and still others when claim payments were made. Confusing these fields can misstate what happened and when.
The distinction matters even before any loss measure is calculated. For example, a claim could arise from an event in one month, be reported in a later month, and have payments made over several subsequent months. Each date describes a different event in the claim’s history. A transaction record may therefore have a payment date even though the claim itself has one underlying occurrence or accident date.
The exact meaning of a field can depend on the product and the insurer’s data definitions. For a straightforward collision claim, occurrence date and accident date may refer to the same day. For a loss caused by an event that develops over time, the occurrence date may require a defined convention rather than a single obvious instant. Always interpret a field using its stated meaning; do not infer that two labels are synonyms just because they sometimes hold the same value.
What Each Date Records
An occurrence date points to the event or circumstances that gave rise to the loss. It answers a question about the underlying cause, not about when the insurer learned of the loss or paid it. Depending on the coverage and the facts, the relevant event may be a sudden incident or a circumstance that unfolds over a period. If the event spans time, the data definition should make clear how a date or date range is recorded.
An accident date points to the accident itself, often the date of an injury-causing incident. For a vehicle collision, this is ordinarily the date of the collision. For some claims, injury or damage may be discovered after the incident; the discovery date does not automatically replace the accident date. Accident date is especially useful as a factual description of when the accident happened, but it should not be substituted for another date field without checking the data definition.
A report date describes when information about the claim reached the insurer, as defined by the system. A claimant might first notify an agent, who then notifies the insurer; those contacts can occur on different days. A database may define report date as the insurer’s receipt of the first notice, or may use a different documented milestone. The label alone does not settle which convention applies.
A payment date belongs to a payment transaction, not necessarily to the claim as a whole. A claim can have no payment yet, one payment, or multiple payments. If payments are made in installments, each transaction can have its own date. A system may record the date a payment was issued, authorized, or otherwise recognized as paid; use the system’s stated convention when those moments differ.
| Date field | Question it answers | Common interpretation |
|---|---|---|
| Occurrence date | When did the loss-causing event or circumstances occur? | Date of the underlying occurrence, according to the data convention |
| Accident date | When did the accident happen? | Date of the accident or injury event |
| Report date | When was the claim reported? | Date notice was received at the specified reporting point |
| Payment date | When was this payment made or recorded? | Date attached to an individual payment transaction |
Reading a Claim Timeline
A typical claim timeline has an event first, a report afterward, and one or more payments later. This is a useful expectation, not a universal rule that validates every record. A reporting delay can be long; an event may be discovered only later; payments can be split into multiple transactions; and data may contain corrections or errors. A date sequence should prompt interpretation and, when appropriate, a data-quality check rather than an automatic assumption.
Ask what happened that gave rise to the claim. Record its occurrence date, and its accident date if the claim involves an accident and the field is defined.
Use the report-date convention documented for the claim system. Do not use the date of the event merely because it is the earliest date.
Each payment record has a payment date. Several payment records may belong to one claim and therefore need not share a date.
Confirm the field definition, whether dates are complete, and whether the claim has more than one payment or relevant event.
Worked Example: Four Dates for a Workshop Fire
A hypothetical workshop’s wiring fault ignites a fire on March 14. The owner discovers the damage that afternoon and calls the insurer’s claims center on March 18. The insurer records the first notice on March 19 after receiving the call information. It issues an initial payment on April 8 and a separate supplemental payment on May 2. Identify the relevant dates and explain which dates attach to the claim and which attach to transactions.
Step 1: Identify the loss-causing event. The fire resulting from the wiring fault occurred on March 14. Under the stated facts, March 14 is the occurrence date.
Step 2: Identify the accident date. The fire is the sudden damaging incident in this scenario, so March 14 is also the accident date. The fact that the owner discovered the damage later that day does not change when the fire occurred.
Step 3: Identify the report date. The claims center received the call information on March 18, but the stated system convention records first notice when the insurer records it. Therefore, the report date is March 19. If a different system defined report date as the date of first contact, March 18 could be recorded instead; the convention must be known.
Step 4: Identify payment dates. The initial payment has an April 8 payment date, and the supplemental payment has a May 2 payment date. There is one claim but two payment transactions.
Check. The four kinds of dates are not all the same: occurrence and accident are March 14, report is March 19 under the specified convention, and the two payment dates are April 8 and May 2. The common mistake is to call March 18 the report date without noticing that the problem explicitly defines the system’s report date as the date first notice was recorded.
Why Payment Dates Do Not Replace Event Dates
A payment records when money moved under the applicable transaction convention. It does not, by itself, identify when the underlying event happened. This can be seen directly by writing a claim’s paid amount as a sum of its payment transactions.
Here, \(p_{jk}\) is the amount of transaction \(k\) for claim \(j\), and \(t_{jk}\) is that transaction’s payment date. The claim may also have one occurrence date \(o_j\). Nothing in the sum requires \(t_{j1}, t_{j2}, \ldots, t_{jn_j}\) to equal \(o_j\), or even to equal one another. The sum describes the claim’s payments; the occurrence date describes the event that gave rise to the claim.
This explains why a payment-level file and a claim-level summary can contain different numbers of date values. If a claim has three payment transactions, it can appear on three payment records but still have one occurrence date and one report date. Repeating the claim’s occurrence date on each transaction row does not create three occurrences. Conversely, assigning a transaction the claim’s occurrence date would change what the payment-date field means.
Worked Example: One Claim With Installment Payments
A hypothetical equipment policy covers damage when a conveyor fails. The failure occurs on September 27. The insured reports it on October 4, and the insurer records the report that day. The insurer makes three payments: $1,250 on October 20, $2,300 on November 12, and $450 on December 3. Find the total paid and state the date information that belongs to the claim versus the individual payments.
Step 1: Separate the event and report dates. The occurrence date is September 27. No separate accident date is provided; do not invent one or assume that every occurrence-date field is also an accident-date field. The report date is October 4.
Step 2: Add the payment amounts. The first two payments total \(1{,}250+2{,}300=3{,}550\) dollars. Adding the third gives \(3{,}550+450=4{,}000\) dollars paid in total.
Step 3: Attach dates at the right level. The claim has one stated occurrence date and one report date. Its three payment transactions have dates October 20, November 12, and December 3, respectively.
Check. The total of the three payment amounts is $4,000, and none of the payment dates changes the September 27 occurrence date. The common mistake is to treat each payment row as a separate claim occurrence. The rows are transactions for one claim, not three distinct events.
Ambiguous Dates and Data Checks
Some claim histories do not have a clean, single-day story. A condition may develop over time, damage may be noticed after it occurs, or an initial report may be followed by a more complete notice. In such cases, avoid silently replacing one date with another. First determine what the field is intended to capture; then use the documented convention consistently.
A useful review asks whether the date values make sense in context. For example, a payment date before the recorded report date may reflect an incorrect field, a special processing convention, or an unusual history that requires investigation. It is not enough to declare the record impossible without knowing the system. Likewise, an unusually long delay between occurrence and report may be real rather than erroneous.
- Do not substitute discovery date for occurrence date automatically. Discovery describes when someone noticed the loss; occurrence describes when the loss-causing event took place under the applicable convention.
- Do not infer report date from an external contact date. Check whether the field uses first contact, insurer receipt, system entry, or another defined milestone.
- Do not force all dates into one claim-level value. Payment dates may be transaction-level, and one claim may have several.
- Do not treat a matching pair of dates as proof of identical meaning. Occurrence and accident dates can match in a particular claim while remaining distinct concepts.
Worked Example: Resolving a Misread Claim Record
A hypothetical claim record lists an accident date of January 11, a report date of January 16, and payment transactions dated February 7 and March 1. A reviewer says, “There are two claims, because there are two payment dates,” and proposes January 16 as the accident date because that is when the insurer received the notice. Assess the reviewer’s statements using only the information given.
Step 1: Interpret the accident date. The recorded accident date is January 11. The report date does not replace it: January 16 records when notice was received, not when the accident happened.
Step 2: Interpret the payment dates. February 7 and March 1 are dates for two payment transactions. Two transactions alone do not establish that there are two claims. The claim identifier and claim-level records are needed to determine whether the transactions belong to one claim or more than one.
Step 3: State what can and cannot be concluded. If both payments carry the same claim identifier, they are two payments for that claim; if they carry different claim identifiers, they may represent different claims. The facts supplied do not state the identifiers, so the reviewer’s claim count cannot be verified from the payment dates alone.
Check. January 11 is the stated accident date and January 16 is the stated report date. The payment dates do not, by themselves, determine the number of claims. The common mistake is to use a date’s timing or number of appearances as a substitute for its defined meaning and the claim identifier.
Common Exam Traps
The main trap is to read the dates chronologically but not semantically. A later date is not necessarily a more accurate version of an earlier one; it may describe a different event entirely. Another trap is to assume that every payment record corresponds to a separate claim, or that every claim has only one payment date. Always identify what each row represents before interpreting its dates.
For a quick check, say the date’s meaning aloud in a complete phrase: “the date the accident happened,” “the date the insurer received notice,” or “the date this payment was recorded.” If the phrase does not fit the field’s documented definition, the value is being misread. This discipline is aligned with the CAS Exam 5 (Basic Ratemaking and Estimated Claim Liabilities) syllabus.
Check Your Understanding
For each scenario, identify the requested date or explain what the available dates do and do not establish.
- A hypothetical delivery van collides with a barrier on June 6. The driver reports the collision to the insurer on June 8, and the insurer records the notice that day. A payment is issued on June 25. State the accident date, report date, and payment date. (Answer: Accident June 6; report June 8; payment June 25.)
- A hypothetical pipe bursts on November 2, but the building owner discovers the water damage on November 5 and reports it that day. Under a convention that records the date the pipe burst as the occurrence date, what are the occurrence and report dates? (Answer: Occurrence November 2; report November 5.)
- One hypothetical claim has payments of $800 on April 3 and $1,200 on April 19. What is the total paid, and how many payment dates are present? Does that alone establish the number of claims? (Answer: $2,000 across two payment dates; no, the number of claims cannot be established without claim-level identification.)
- A hypothetical claim system defines report date as the date first notice is entered. A customer calls an agent on August 10, and the insurer enters first notice on August 12. Which date is the report date under that convention, and why? (Answer: August 12, because the stated convention uses the insurer’s entry date.)
- A file shows an occurrence date of February 4, a report date of February 15, and a payment date of February 20. A reviewer says the three fields should be changed to February 4 because that is the earliest date. Is that conclusion justified? (Answer: No; each field records a different event, so only a confirmed data error or a different documented convention would justify changing the later dates.)