Vendor Lock: Why Used Vendors Can Never Be Deleted
Vendor lock is the control that prevents any vendor tied to historical requests from being deleted — payments, approvals, and audit trails keep their referential integrity, forever.
An audit trail that references a vendor who no longer exists is a trail with a hole in it: "who was paid, by whom, when?" gets an answer of "nobody — that vendor is gone." Vendor lock closes that hole. A short, specialized page — part of the Vendors cluster, alongside master data management and the approval gate.
Deletion vs. deactivation — the distinction that matters
| Action | What happens | Effect on history |
|---|---|---|
| Delete | The vendor record is removed | Every historical request referencing it loses its payee — the audit chain breaks |
| Deactivate | The vendor stops being selectable for new requests | All history intact — the audit trail keeps every reference |
How the lock works
- Used vendors are locked — the moment a vendor is tied to any request, deletion becomes impossible
- Deactivation is the exit — departing vendors stop future payments, never past evidence
- Removal rights are admin-only — and even administrators can only remove never-used vendors: the ones with no historical footprint to protect
- It's structural, not procedural — the system doesn't discourage deleting used vendors; it can't happen
Frequently Asked Questions
Why can't used vendors be deleted?
Because their records anchor historical approvals and payments. Deleting them would break the audit trail's referential integrity — the "who was paid" question would lose its answer.
How do you remove a vendor from active use?
Deactivate: the vendor disappears from new request forms, payment data stays on historical requests, and the full record remains for audit.
Approvdit locks every vendor with history — deactivation only, admin-scoped removal for the rest, and a tamper-evident trail throughout. Book a live demo.