Supplier Claims Management System: Data Model

Why a single claims system is needed

Claims to suppliers almost always start small: "the lot has defects", "specs don't match", "packaging is damaged". But when tracking lives in email, messengers and Excel, small things quickly become losses. Production or the warehouse stand idle, staff waste time hunting through threads, and a dispute with a supplier stalls for lack of accurate data.

A unified supplier claims management system acts as one source of truth: one card, a clear status, responsible parties and the history of decisions. That way you can see not only "what happened" but also "what we did" and "who’s next".

From day one it’s important to record three things:

• which delivery and lot the defect relates to;
• what evidence exists (photos, acts, measurements);
• which reaction deadlines are agreed.

Without a link to the lot it’s hard to prove the source of the problem. Without evidence the supplier can easily dispute the fact or scope of the defect. Without deadlines you can’t measure delays or manage them.

A claim typically leads to one of the resolutions: return, replacement or sorting (when part is good, part not). If this isn’t reflected in the data, later you can’t calculate the cost of losses or compare suppliers.

The process usually breaks down at several points: communication happens across different channels, agreements remain verbal, there’s no link to procurement and delivery documents, and response and closure deadlines aren’t tracked.

A simple example: during incoming inspection you found defects, took photos, recorded the lot and the response deadline. In a week you won’t be "trying to remember details" — you’ll show the supplier the facts and the expected resolution.

Minimal data model: entities and relations

For the system to work it must answer three questions: what happened (defect), where exactly (lot and delivery), and what was decided (action and money). The minimal data model is built around links to procurement; otherwise claims remain "notes" with no consequences.

The core looks like this:

• Claim: a single case card, owner and current status.
• Defect: what’s wrong, how it was detected, the severity level.
• Lot: lot identifier, date, quantity, serial info.
• Delivery: invoice/act, warehouse (where it arrived), acceptance date.
• Purchase order: PO line, price, terms, responsible buyer.

Surrounding the core you need reference data, otherwise reports start to drift: items catalog, suppliers, sites and warehouses, defect causes, detection methods (incoming inspection, production, operation). Participants are easier to store as roles on the claim: initiator, warehouse, QA, procurement, supplier, finance. This simplifies approval routes and responsibility allocation.

For the lifecycle five statuses are usually enough: registered, under inspection, agreement, execution, closed. It’s important to log who changed a status and when, so SLA can be measured.

Mandatory fields without which a claim is legally and operationally weak: supplier, item, quantity affected, lot and delivery document, place and date of discovery, defect description and category, resolution (return/replacement/sorting/compensation), amounts and currency (if any), responsible persons and reaction deadlines.

Example: during incoming inspection in production (for instance, at an integrator or manufacturer such as GSE.kz) a defect in 40 units was found. If the defect is tied to a lot, delivery and PO line, procurement can quickly bring up terms and finance will correctly record the return or credit.

Defect card: what to record besides free text

Text descriptions are almost always inconsistent: one person writes "doesn’t work", another — "error on power-up". To compare data, the defect card should be as structured as possible.

Start with identification: internal defect code (e.g., Q-000123), category (electrical, mechanical, software, completeness), severity (critical, major, cosmetic) and a short standard name. This makes filtering and reporting easier.

Next you need a single causes catalog. It’s not about "who’s to blame" but the type of origin: production defect, damage in transit, packaging, picking error, labeling mismatch. Causes should be chosen from a list, not entered freely.

Record measurable parameters: number of defective units, unit of measure, serial numbers or range (if available), detection conditions (on receipt, during installation, in operation).

Add a confirmation block: who inspected, when, in what role (warehouse, QA, engineer) and how it was confirmed (act, inspection protocol, test results).

To make departments describe defects consistently, simple templates help: "Symptom", "Conditions", "Expected", "Actual", "Repeatability".

Lot and delivery: how to prove the source

To avoid turning a claim into a he-said-she-said dispute, the system should distinguish two concepts: lot (what was produced/packed together) and delivery (how and when it arrived to you). That way it’s easier to show whether the defect originated in the supplier’s production, in logistics or at acceptance.

On the delivery card record at least: number and date, recipient warehouse, acceptance conditions (temperature, humidity, package integrity), carrier (if applicable) and the person responsible for acceptance. These fields help reconstruct the chain of events even months later.

Attach documents to the delivery rather than storing them "nearby": invoice, acceptance act, specification. One claim may reference multiple specification lines, and one line can be part of multiple claims (e.g., repeated defects for the same SKU).

Mixed lots and partial deliveries often create confusion. If goods from different lots arrived in one truck, keep the split: "delivery 125" contains lots A and B with different quantities. If a delivery arrived in parts, record multiple delivery events under the same order so deadlines are counted correctly.

For recurring problems it’s useful to link a claim to both the lot and the delivery. That shows whether it’s a one-off issue in one lot or a systemic problem across lots A, B, C.

If data is clarified later (for example you find the lot number on an internal label), use versions: don’t overwrite fields silently. Save who, when and why changed a value. This reduces conflicts and increases trust in the data.

Photos, documents and evidence: how to store without chaos

Attachments are not "for show"; they prove the defect quickly and tie it to a specific lot. A file should be more than an upload — it must be described: type (photo, act, correspondence, test protocol), author, timestamp and at minimum linked to the defect and the lot (preferably also to the delivery).

Which photos really help

Photos should answer: what exactly is wrong and where it’s visible. For PCs, servers or components during acceptance, these shots usually suffice:

• overall view of the item and the defect location;
• close-up of the defect in focus;
• marking (serial number, labels, plate);
• packaging and seals;
• photo of the whole lot/box if the problem is widespread.

After upload record context: where it was taken (warehouse, shop floor, field), who took it and at which stage (acceptance, installation, operation).

Naming, access and integrity

Avoid IMG_1234 by adopting a naming rule (for example: Date_Supplier_Lot_Type) and require file attributes: lot and/or delivery number, location of capture/document creation, author role (acceptance, QA, service), version and status (draft, confirmed), and a short comment explaining what is in the file and why it matters.

Access rights should be split: inside the company see everything, supplier sees only selected attachments (marked "visible to supplier"). To protect integrity, forbid deletion after sending to the supplier, keep an activity log (who added, who opened, who changed visibility) and require a comment for each key file action.

Claim resolutions and how they show up in data

Store a resolution not as a comment but as a separate object. Then it’s clear what was agreed, who approved it, which amounts and actions are expected, and what execution stage it’s in.

Separate the resolution type and conditions, the financial part, and the logistics of execution. Common types repeat: return, replacement, sorting, repair, markdown, compensation, rejection. The type should be chosen from a catalog.

Resolution as an object

On the resolution card record: who decided (role and name), when, on what basis (act, photos, incoming inspection results), and the conditions — deadlines, packaging requirements, acceptable defect percentage, whether a re-check is needed after replacement.

Finance and execution

Store financial consequences in dedicated fields: amount, currency, VAT, compensation method (credit note, invoice adjustment, discount on the next delivery), and links to procurement documents (invoice, waybill). Logistics must also be explicit: who collects the goods, where they are taken, who pays shipping, transport request number.

Record partial satisfaction as resolution lines. For example, in one claim: 20 units — return, 50 — replacement, 30 — sorting at the warehouse with supplier paying sorting labor. This avoids disputes and gives exact figures for reports and KPI.

Reaction times and SLA: how to set and measure

SLA works only when checkpoints are stored in data, not "in someone’s head". Four stages are usually enough: fact registered, supplier notified, resolution agreed, claim closed.

To calculate SLA automatically use separate date/time fields (not a single "claim date"):

• detection date/time;
• supplier notification date/time;
• supplier response deadline (reaction);
• execution deadline (remediation);
• actual closure date/time.

Distinguish two SLAs: reaction and remediation. Reaction is often 1–2 working days for a critical defect and 3–5 for non-critical. Remediation depends on the resolution: return, replacement, sorting, rework. Set different timers for defect types and product categories, otherwise supplier comparisons will be unfair.

Make escalations predictable: at 80% of the time to deadline send a reminder to the responsible party; on overdue notify the manager and procurement; on repeated breaches escalate to the quality commission. Then overdue becomes visible immediately instead of surfacing at month end.

Consider calendars: working days, holidays, time zones and warehouse downtime. If the warehouse does not accept returns on weekends, execution deadlines should be counted in the warehouse working days, not calendar days.

Supplier KPIs: what to measure and how to compare

Metrics should answer three questions: how many defects, how quickly they respond, and what it costs. The key rule: normalize by volume (per 1,000 units, per 100 deliveries, per 1 million KZT of purchases), otherwise large suppliers will almost always look worse.

Basic KPI set

Usually 10–12 metrics are enough if calculated consistently:

• Quality: share of defective units, defects per 1,000 units, recurrence of a cause (e.g., same cause 3 times in a quarter).
• Speed: average time to first response, to resolution, to closure; share of SLA breaches by stage.
• Cost: cost of defects (write-offs/repairs), logistics (returns/shipping), losses from downtime and markdowns.
• Agreement: share of acknowledged claims, share of rejections, share of disputed cases (when resolutions were revisited).

A rating without volume bias

Compute a final score 0–100 and recalculate monthly:

• 40% quality (normalized per 1,000 units);
• 30% speed (including SLA breaches);
• 20% cost (per 1 million KZT spent);
• 10% agreement (acknowledgement and disputes).

Example: a packaging supplier has few defects but 60% of responses are after SLA. In the rating they won’t hide behind low cost because speed has weight and breaches carry a penalty.

How to tie claims to procurement and deliveries

For a claim to help procurement it must not be an isolated "complaint" but a record linked to a specific purchase and receipt. Then you can see which supplier, which item and which lot cause losses and quickly stop repeats.

Link by identifiers, not text. At minimum store in the claim:

• purchase order number and line (SKU, description, unit);
• supplier and contract (if any);
• receipt document (waybill) and acceptance date;
• warehouse lot or serial number (if applicable);
• quantities: received, defective, blocked.

The link to receipt and lot is important for actual stock. If 12 of 100 units are defective, these 12 should be set to "quarantine/blocked" so they aren’t issued to production or customers.

Reflect returns and replacements as movements that reduce or restore procurement liabilities and budgets. A return closes part of the delivery, a replacement creates a new expected receipt linked to the original claim so deadlines and responsibility aren’t lost.

To avoid buying the same problem again set rules to block repeat purchases: a defect threshold per item or supplier over a period, temporary freeze on purchases until open claims are resolved, mandatory QA approval for critical categories. Allow exceptions only with documented risk and a corrective action plan.

Useful reports for procurement: monetary and unit losses, delays caused by claims, top items by defects, share of replacements vs returns. Then suppliers are chosen by factual cost of quality, not impressions.

Step-by-step rollout: from process to system

Starting immediately with a system form often creates chaos: varying statuses, scattered reasons, disputed deadlines and reports nobody trusts. It’s more logical to agree the process first and then lock it into data and rules.

Sequence of work

1. Describe the claim flow from detection to closure. Define roles (initiator, warehouse, quality, procurement, supplier), handover points and what counts as "accepted for work".

2. Approve catalogs and templates. Minimum: defect types, causes, resolution options (return, replacement, sorting, repair, discount), unified card fields and mandatory fields.

3. Configure statuses, SLAs and escalations. For each status define who is responsible and which deadlines are measured: receipt confirmation, initial response, action plan, closure. Make notifications targeted and escalate only on deadline breach.

4. Agree reports and KPIs with warehouse and procurement goals. Decide which figures are "official": which date defines an overdue, how to treat partial closures, and what to do with recurring defects.

5. Run a pilot on 1–2 procurement categories — for example components with high defect rates or items critical to production. After 3–4 weeks refine catalogs, statuses and rules, then scale.

A practical rollout quality test: take one real claim and check whether in 2 minutes you can answer what happened, which delivery it relates to, what decision was made and who missed an action. If not, the issue is usually roles, mandatory fields or SLAs.

Common mistakes and traps in claims accounting

The main trap is designing the system "just in case": adding dozens of rarely used fields. The result is partially filled cards and data unfit for analysis or dispute resolution.

A second common error is keeping claims separate from lots and documents. If a defect in server components or a PC lot lacks delivery number, invoice, serial numbers and the accepting person, proving the source is hard. Discussion quickly becomes exchange of opinions.

Another problem is confusing "status" with "resolution". Status answers where we are (under inspection, with supplier, closed). Resolution is what’s agreed (return, replacement, sorting, discount). When mixed, no one understands what’s approved and what’s still being discussed.

Accounting usually breaks due to:

• many optional fields with no "minimum to close" priority;
• no link to lot, delivery and evidence (photos, acts);
• statuses that describe resolutions and resolutions that act as statuses;
• reaction times not recorded so breaches are invisible;
• KPIs calculated without volume normalization.

If KPI aren’t normalized (for example defects per 1,000 units and share of SLA breaches), a small supplier can look worse after a few incidents, while a large supplier may appear better by scale. This leads to wrong conclusions and procurement decisions.

Short checklist: what to check in every claim

A claim is valuable only if it can be proven, linked to a specific delivery and brought to resolution. Before sending to the supplier check the basics.

Identification: unique number, creation date, exact link to supplier (legal entity, contract, contact).

Origin: filled lot and delivery (delivery number, date, warehouse/place of acceptance, quantities by document and actual), attached acceptance documents (waybill, act, incoming inspection results). If deliveries are partial it must be clear which part of the lot is affected.

Evidence: photos with visible marking (serial number, label, packaging) and defect close-ups. QA confirmation added: who checked, by which criteria, how many units checked and how many recognized as defective.

Deadlines and roles: SLA deadlines for stages (confirmation, decision, closure) and responsible persons — who awaits supplier response, who prepares the return, who controls the replacement.

Resolution and plan: chosen action (return, replacement or sorting), volumes, logistics, who and when performs, and closure criteria (e.g., 100% of confirmed defects replaced or sorting completed with an act).

Example scenario: defective lot resolved by sorting

A lot of fasteners arrives under contract, but 20 of 200 boxes have stripped threads. The warehouse has already assembled orders for shipment, and stopping issuance will affect delivery times. It’s important to quickly record the fact, separate usable units and keep procurement linked.

It’s convenient to create one claim for the delivery but with multiple defects inside: "stripped thread", "damaged packaging", "label mismatch". Link the claim to the lot and to specific PO lines so you can later calculate which SKU and which price were affected.

The resolution is combined: sorting at the warehouse within 1 working day and replacement of critical items within 5 days. In data this appears as two actions in the resolution card: for sorting record the executor, labor costs and result (how many good, how many defective); for replacement record the quantity to replace, supplier promise date and compensation amount (for example, payment for sorting work).

To make this work keep at least:

• photos of defects linked to defect and lot;
• acceptance act or internal sorting report;
• correspondence and reference numbers;
• dates: detection, supplier notification, first response, closure;
• outcome: how many written off, replaced, and how many hours spent sorting.

In supplier KPI this increases the defective units share and worsens SLA on first response if the supplier delayed. Next month procurement can rely on facts: reduce volumes, increase incoming inspection for the SKU, or include contractual compensation for sorting and replacement deadlines.

Next steps: how to start without extra bureaucracy

Begin with an inventory of facts: where claims currently live (email, Excel, messengers), who actually makes decisions, and what deadlines are currently achieved for stages (registration, supplier response, closure).

Then lock in a minimal set of fields without which disputes always derail. Fields should help prove the source and calculate KPI, not exist "for show". A common mistake is trying to cover every scenario at once and drowning in mandatory fields.

To avoid process gaps, design links to procurement, warehouse and finance from the start. A claim must "know" the purchase order, PO line, lot/serial, receipt event and financial outcome: credit note, return, additional charge or write-off. Then supplier reports won’t diverge from accounting.

A practical rollout order:

• 1–2 weeks to gather current data and actual deadlines;
• agree 10–15 mandatory fields and 3–5 KPIs;
• configure roles: who creates, who confirms, who closes;
• connect integrations with procurement/warehouse/financial adjustments;
• run short training and introduce data quality checks.

If you need help with process and integrations, you can involve GSE.kz as a system integrator to reach a working system faster with clear data, SLAs and execution control.