---
id: KB-CF-015
url: https://app.codecontract.io/help/use-cases-by-capability/offboarding-a-supplier
idioma: en
categoria: casos-por-funcionalidad
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CF-006, KB-TZ-013, KB-CF-016]
citadoPor: [KB-CF-020]
---

# Offboarding a supplier

_Onboarding gets documented in detail and offboarding barely at all, which is where the loose ends are._

**Responde a:** ending work with a supplier · supplier offboarding documentation · what to do when a supply contract ends · closing a supplier relationship

Onboarding a supplier means asking for everything. When you stop working with them, usually nothing happens: you just stop calling. And that leaves open ends that surface months later, almost always at the worst moment.

## What to close

1. **Any access they held** — If they entered your systems or premises, withdraw it the same day.
2. **What was left half-done** — Open orders, live warranties, consigned stock, borrowed tools.
3. **The documentation you must keep** — It is not deleted on offboarding: obligations run their own periods.
4. **And the reason, in one written line** — Price, quality, they closed down. It stops you re-hiring them by mistake in three years.

> [!IMPORTANT]
> The fourth looks like bureaucracy and is the opposite. Without it, two years on someone re-approves the very supplier there was a serious problem with, because whoever knew has left and the file only shows they stopped being used.

## What not to do

| Temptation | Why not |
| --- | --- |
| Delete their file | Obligations and possible claims remain |
| Leave them active "in case they come back" | They appear in lists and alerts, polluting counts |
| Say nothing to the team | Someone will keep asking them for things for months |

> [!WARNING]
> The second is commonest. A supplier neither active nor closed keeps receiving automatic documentation renewal requests, which is awkward for them and consumes on your side for no purpose.

## If the exit is contentious

**En corto**

- Withdraw access first and talk afterwards.
- Record the state of what is outstanding before closing anything.
- And keep the full history: it is what supports any later claim.

The history includes what went well, not only what went badly. A claim stands up better when you can show the whole year and not just the last month.

> [!NOTE]
> The same scheme suits offboarding a client, an external collaborator or a subcontractor. What must be returned changes; that the exit is documented like the entry does not.

**How long must their file be kept?**

Whatever the applicable obligations and claim periods require, with margin.

**What if they work with us again?**

Reactivate with current documentation; the earlier history stays and is useful.

**Must it be communicated formally?**

It depends on the contract: where notice is agreed, that communication has a form and a deadline.

## Ejemplos

**A company stops using a supplier and two years later re-approves them.**

- Writes the reason for offboarding in their file
- Closes access and outstanding items the same day

→ The next approval happens knowing what occurred, instead of repeating the problem.

**You stop working with a supplier and their file stays open and active.**

- Closes the file, stating the reason
- Revokes their access and stops the reminders
- Retains the history per the retention policy

→ The active supplier list becomes true again and the history still exists.

**The supplier is deleted and the history of what they supplied vanishes.**

- Archives rather than deletes

→ What happened stays consultable.

**They keep receiving reminders months later.**

- Stops the open processes on closing

→ Nobody receives requests from an ended relationship.

**Work resumes with them the following year.**

- Reopens the file with its history

→ Nothing already provided is lost.

**Nobody knows which suppliers are genuinely active.**

- Periodically reviews those with no activity for a while

→ The list reflects who you actually work with.