---
id: KB-IC-012
url: https://app.codecontract.io/help/reports-and-quality/raising-a-quality-claim-with-a-supplier
idioma: en
categoria: informes-y-calidad
subcategoria: calidad
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IC-002, KB-IC-005]
citadoPor: [KB-CS-032, KB-IU-007, KB-DI-016]
---

# Raising a quality claim with a supplier

_What has to be gathered before writing the claim, not after._

**Responde a:** supplier claim for defective product · documenting a supplier non-conformance · claiming for defective material · evidence for a supplier claim

A quality claim is won or lost in the first few hours, before anything is written. What decides it is not the wording: it is what was gathered while the problem was in front of you and could still be documented.

## What to gather the same day

1. **The batch and its intake documentation** — Delivery note, certificate, receipt date. It ties the defect to that supply.
2. **Photos of the defect and of the whole** — Detail and context: a close-up with no context identifies nothing.
3. **How much is affected** — Whether it is the whole batch or part, and how you checked.
4. **And the real impact** — Line stoppage, rework, missed delivery. It is what quantifies the claim.

> [!IMPORTANT]
> The fourth is barely ever documented in time and is the only one that turns a complaint into a claim. "The material was bad" opens a technical argument; "the material was bad and stopped the line for six hours" opens a negotiation.

## What to have in place beforehand

| Element | Why beforehand |
| --- | --- |
| An agreed written specification | Without it, "bad" is an opinion |
| Acceptance criteria at goods-in | It defines what is checked and to what tolerance |
| The supplier's incident history | It changes the conversation if this is the third time |

> [!WARNING]
> The third row carries the most weight and survives the worst, because incidents usually live in different people's emails. Held in the supplier's file, the claim stops being an isolated case and becomes a pattern, which is a different conversation.

## When writing it

**En corto**

- Dated facts, not judgements.
- What you want, concretely: replacement, credit, deadline.
- And the response time you expect.

> [!NOTE]
> Communicating with proof of delivery matters more here than elsewhere: defect claim windows are usually short and run from receipt or from detection, depending on the case.

**What if the defect appears months later?**

You can still claim, but what was recorded at goods-in weighs heavily.

**Should we return the material before it is resolved?**

Not without agreeing: returning the evidence early complicates proving the defect.

**Should an internal non-conformance be raised too?**

Yes, and linked: the claim looks outward, the non-conformance inward.

## Ejemplos

**A factory receives out-of-spec material and claims a week later.**

- Gathers batch, photos, affected quantity and impact the same day
- Links the supplier's incident history

→ The claim is settled with replacement and no technical argument, because the facts were dated.

**A supplier is challenged on quality and replies that it is the first time.**

- Checks their incident history with dates
- Provides the specific impact of each
- Agrees a plan with a review date

→ The claim rests on facts and the supplier knows exactly what is being asked.

**The complaint is made by phone and nothing remains.**

- Records it with what was agreed

→ What was agreed stops depending on two memories.

**The complaint comes late and the deadline has passed.**

- Records the incident on detection

→ The claim goes out in time.

**A complaint is made and nobody checks whether it improved.**

- Sets the review date when complaining

→ The plan is met, or you know it is not.

**The supplier improves and is still treated the same.**

- Checks the period's trend

→ The relationship matches what is happening now.