Warranty Claim Data Model: Terms, Coverage, Claims

Key takeaways

• Warranty needs three objects, not a date column: the terms, the coverage check at the moment of failure, and the claim with its own lifecycle.
• Coverage runs on three clocks: calendar from a start event, usage from a meter, and a fresh clock on a replaced component. The earliest one to end decides.
• Warranty runs from one named event, and plants usually store a different one. Purchase and commissioning were 85 days apart on the machine below, and picking the wrong one threw away a live claim worth 3,990 EUR.
• A claim assembled weeks after the repair fails on evidence, not on entitlement. Those fields are written at the moment the part is fitted or they are never written.
• Recovery is rarely all or nothing. The ten claims below recovered 70.0% by count and 61.6% by value, a gap of 8.4 percentage points from the same rows.

Three objects, not one field on the asset

Most plants hold warranty as a single date on the machine record, usually copied from an invoice. That one field cannot answer the only question that matters on the day something breaks.

The question is: does this failure, on this component, at this meter reading, on this date, oblige this supplier to pay?

Answering it needs three separate records, because each one has a different owner, a different lifespan and a different moment of truth.

The terms record is static. It is created at purchase and carries no events.

The coverage check is not a record until you run it. It is a function of the terms and the asset's state at one instant, and its answer expires the moment the meter moves.

The claim is an event object with money attached: statuses, deadlines, a counterparty who argues back, and a settlement that is rarely what you asked for.

What breaks when it is one spreadsheet column

A spreadsheet with a purchase date per machine fails in four specific ways, and each one has a name.

The third row is the expensive one. A gearbox fitted in year two carries its own cover, and a machine-level date field has nowhere to put it.

The fourth row is the quiet one. Without a claim object, nobody can tell an unasked claim from a refused one.

What this page covers that our other pages do not

Our guide to warranty leakage and maintenance cost recovery makes the business case, and it is not repeated here. This page answers a narrower question: which fields must exist, and at which moment, for a claim to be payable.

The records a claim draws on are specified elsewhere: the equipment failure record, the meter reading, the labour time booking and the purchase order and goods receipt. Read those for the field definitions, this page for how a claim consumes them.

The warranty term record, field by field

One row per set of terms. Not one per machine, because a single machine can carry three sets at once.

object_type is the field that lets a plant stop arguing about where warranty lives. Set it to component and the gearbox gets its own row, without touching the machine.

Point object_id at a real row in the asset hierarchy, never at typed text. A term attached to the string "Line 3 capper" is a term nobody can query.

The cover scope fields

Entitlement is not one boolean. Four cost categories are settled independently, and the terms have to say which ones are in.

notify_within_days earns its place on its own. It is the commonest reason a genuinely covered failure is refused, and it is almost never stored where a technician can see it.

Typical values run from 7 to 30 days from the failure, not from the repair.

covers_labour decides whether a claim is worth raising at all. On a four hour repair with a 200 EUR part, labour is most of the money.

The covered item link

A term points at an object. The covered item link says which physical thing, with which identity, the promise actually follows.

Either serial_no or lot_no must be present, enforced at write time. A covered item with neither is a claim you lose at the first question.

This is where most plants stop, and where most claims die. Recording the serial at fitting takes fifteen seconds, and reconstructing it six months later is impossible.

Parts that come back to stock and get fitted again need the same treatment, which our rotable spare data model covers in full.

Coverage is a function of three clocks

A warranty rarely runs on one clock. It runs on two or three at once, and the earliest to end governs.

The calendar clock needs two fields: start_date and duration_months.

The usage clock needs four: meter_id, start_meter_value, usage_limit and usage_uom. Without the start value, warranty breaks on any second-hand or relocated asset whose meter did not read zero on day one.

Read it from the same meter the rest of the plant uses, with the same rules on resets and rollovers, specified in our meter reading data model. A check with its own private counter will disagree with the maintenance plan.

The rule when two clocks apply at once

Store the rule, do not assume it. One field, limit_rule, with two values: first means cover ends when either clock ends, and last means it runs until both have.

Almost every industrial term is first, and almost every plant behaves as if it were last. That single mismatch is worth more than any other on this page.

Take gearbox GBX‑12, commissioned on 1 February 2025 at a meter reading of 0 hours. The terms are 24 months or 6,000 operating hours, whichever ends first.

The gearbox failed on 9 September 2026, with 145 days of calendar cover still to run. It was not covered.

The usage clock had ended 28 days earlier, at 6,000 hours on 12 August 2026. It ran 480 hours in those 28 days, an average of 17.1 hours a day.

The repair clock, and why it is separate

A part fitted during a repair usually carries its own term, running from the day it was fitted.

A mechanical seal fitted on 14 March 2026 under a repair carries 12 months from fitting. The pump's own 24 month cover ended on 30 November 2026.

The seal failed on 22 January 2027. The pump's cover had expired 53 days earlier, and the seal's own clock still had 51 days to run.

That claim exists only if fitted_on and fitted_under_wo were written when the seal went in. Nothing recorded after the fact will reconstruct them.

The start event is the field plants get wrong

Four dates surround a new machine, routinely months apart. Terms name exactly one, and it is rarely the one the plant stored.

Store two fields, not one: start_event naming which of the four applies, and start_date holding the resolved value. The date alone loses the audit trail the first time someone disputes it.

Purchase and delivery come from the order and the goods receipt, specified in our MRO purchasing data model. Commissioning and first production come from your own acceptance record, and are the two most often missing.

Worked case: capper CAP‑07, four dates, one lost claim

A rotary capper was bought in 2025 with 24 months of cover from commissioning. Here are its four dates.

Purchase to commissioning is 85 days. Delivery to commissioning is 42 days, which is an ordinary install and acceptance period for a machine of this size.

The plant's asset register held the purchase order date, 2 March 2025, because that is what the finance export carried. Its warranty expiry therefore read 2 March 2027.

The true expiry, 24 months from the signed commissioning date, was 26 May 2027. The two dates are 85 days apart, exactly the gap between the two start events.

What that cost on one failure

The capper's servo drive failed on 21 April 2027. Against the stored date it sat 50 days past expiry, so no claim was raised.

Against the correct start event, the same failure sat 35 days inside cover.

3,450 plus 540 is 3,990 EUR, gone because one date field was populated from the wrong source system. The figures here are illustrative, chosen to be easy to check.

The coverage check

The check is a function, not a status. Run it when the failure is recorded and store its answer on the failure, with the inputs it used.

The output is one of four values, and the fourth one has to exist.

undetermined is the value that makes the whole model honest. Without it a missing meter reading silently becomes "expired", and the loss never appears in any report.

Count the undetermined results every month. They are your only direct measure of how much money the record keeping is throwing away.

What a claim must carry to survive scrutiny

A supplier's assessor is not testing whether you were entitled. They are testing whether you can prove what happened, to which unit, and when.

Two dates, not one. failure_date and notified_date are what a deadline argument turns on, and a single "claim date" loses the argument by default.

failure_id makes the claim defensible rather than assertive. It points at a record written on the day by the person who did the repair, with the failure mode and component named.

Which record each piece of evidence comes from

None of this is typed into the claim. Every field links to a record that already exists, if it was written at the time.

Say it plainly: a claim assembled weeks later from memory is the normal reason claims fail. Not the terms, not the supplier, not the entitlement.

The serial of the failed unit is the worst offender. It is legible in the technician's hand and unreadable in the skip two weeks later.

Labour is the second. An assessor pays booked hours against a work order, never a number estimated afterwards, which is why the labour time booking matters.

The claim line and its cost categories

One line per cost category, because settlement happens per category and a single total cannot carry a partial result.

Six categories cover industrial practice: parts, labour, freight, external service, travel and consequential loss. The last one is nearly always excluded and still belongs on the claim.

Put it on the claim with claimed set to false. Your reports then show what the failure cost next to what the terms would ever pay.

source_ref stops a claim drifting. Each line copies a real booking, so a total that no longer matches the work order is visible rather than plausible.

Claim lifecycle and partial recovery

A claim is a negotiation with dates on it. Seven statuses are enough, and each has a field that must be filled before it can be left.

Separate settled_full from settled_part. Merging them is how a plant comes to believe it recovers most of what it claims.

rejection_reason must be a coded list, not free text. Out of date, out of hours, excluded cause, insufficient evidence, notified late, wrong part fitted, unauthorised repair.

That list is a management report on its own. Refusals for insufficient evidence and late notification are your own defects, and refusals on cause or date are not.

Settlement carries three fields, not one

settlement_form catches a real reporting failure. A supplier credit note never appears as cash, so a recovery report reading bank receipts records a successful claim as zero, and a free replacement part fails the same way.

goodwill_pct keeps the accounting honest the other way. A supplier paying 55% without accepting liability has not agreed your claim, and counting it as a win teaches the wrong lesson.

The balance arithmetic

Every claim has a balance, and it belongs on the maintenance cost centre. The formula is one line: unrecovered balance = claimed_amount minus settled_amount.

Take claim WCL‑2026‑0412, a drive failure inside cover on a parts-only term.

Claimed 19,800 EUR, settled 14,200 EUR, so the unrecovered balance is 5,600 EUR. Recovery on this claim is 14,200 divided by 19,800, which is 71.7%.

The settlement form was a credit note against a future order, so no money arrived. Status is settled_part, not settled_full, even though the parts line was paid in full.

Rounding rule for this page: money to the whole euro, percentages to one decimal place, half rounded up. Goodwill is applied to the claimed amount and then rounded, so 55% of 2,750 EUR is 1,512.50 and settles at 1,513 EUR.

Worked example: one plant, one year, ten claims

Plant A, calendar year 2026, reconciled at the year end. Every figure below is an assumption chosen to be easy to check, not a measured result from a real site.

1. The funnel

Four covered failures produced no claim. One fell below the plant's 500 EUR threshold at 480 EUR, and three had no usable evidence, worth 11,320 EUR between them.

That is 11,800 EUR of covered value never asked for, which is 480 plus 11,320. It appears in no recovery rate unless you put it there deliberately.

2. The ten claims

All amounts are in EUR. Claimed totals 80,000 EUR and settled totals 49,293 EUR, so the unrecovered balance across the ten is 30,707 EUR.

Three claims recovered nothing. WCL‑2026‑0231 was refused for insufficient evidence, WCL‑2026‑0508 was outside the usage clock, and WCL‑2026‑0826 was notified late.

The last one is worth the detail. The failure was on 26 August 2026 and the claim was notified on 9 October 2026, 44 days later, against a 30 day deadline.

Fourteen days late on a 7,500 EUR claim, because the deadline sat in a contract folder rather than on the asset. Nothing about the repair was wrong.

3. Two partial settlements in detail

WCL‑2026‑0118 claimed 3,900 EUR: parts 2,600 and labour 1,300. The term covered parts only, so it settled at 2,600 EUR, a recovery of 66.7% with a 1,300 EUR balance.

WCL‑2026‑0347 claimed 2,750 EUR and the supplier offered 55% as goodwill without accepting cover. 55% of 2,750 is 1,512.50, which rounds to 1,513 EUR and leaves a 1,237 EUR balance.

WCL‑2026‑0719 is the third partial: 9,300 EUR claimed, 60% goodwill, 5,580 EUR settled. None of the three is a won claim, and all three appear in the count.

4. The recovery rate, computed two ways

Both rates below come from the same ten rows. They differ because one counts claims and the other counts money.

By count the plant recovered on 7 of 10 claims, 70.0%. By value it recovered 49,293 of 80,000 EUR, 61.6%.

The gap is 8.4 percentage points, and in counts it is 4 claims: seven recovered something, only three recovered everything asked for.

5. The denominator changes the answer again

Measure against covered value rather than claimed value and the rate moves a third time. Covered value is 80,000 plus the 11,800 never claimed, so 91,800 EUR.

49,293 divided by 91,800 is 53.7%. Same year, same rows, three defensible percentages: 70.0%, 61.6% and 53.7%.

Report the denominator with the rate, every time. The spread between 70.0% and 53.7% is 16.3 points, and it is entirely a definition, not a performance.

Five questions to ask a vendor about warranty data

1. Can a warranty term attach to a component, not just to a machine? Ask them to put a 12 month term on a gearbox inside a five year asset, in front of you, and then show it on the gearbox.
2. Which start event does the clock use, and is the event itself stored? A single date field is the wrong answer. You need start_event and start_date as two fields.
3. Does the coverage check read a meter? Ask which meter, whether it uses the reading at the moment of failure, and what it returns when that reading is missing.
4. Does a claim have its own statuses and a per-line settlement? Ask them to settle parts and refuse labour on one claim, then show you the unrecovered balance.
5. Where does the notification deadline live? If it is not visible to the person recording the failure, it is not a control, and late notification will keep costing you whole claims.

Question three separates real products from date fields with a label on them. Most tools answer yes to the first two and fail the third (CMMS data model).

How Fabrico helps

Fabrico is an OEE platform with a full CMMS built in, and it holds most of the evidence a warranty claim is built from.

Your team records the failure on a work order, books the parts consumed against that work order from inventory, and keeps the machine registry, its files and its history in one place, with timestamps and an audit log on every change.

Downtime from PLC connections, IoT sensors and AI cameras sits in the same system as MTTR and MTBF by machine, and the whole set leaves through Excel export, a REST API, webhooks or an ERP connector such as SAP.

What Fabrico does not have: there is no warranty module, no warranty terms record, no coverage check and no claim object with its own lifecycle. The terms and the claim live in your finance, procurement or supplier system.

Treat this page as a specification to test a shortlist against, not as a feature list, and make sure whatever you buy can reach the evidence described above.

Want the evidence side captured properly before you argue with a supplier? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.