Finance Index
What is the vendor lifecycle and when should a vendor be inactivated?
Reference guide to vendor lifecycle inactivation archiving, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
The vendor lifecycle is the set of statuses a vendor moves through: requested, pending verification, active, inactive, and archived. A vendor should be inactivated when the relationship ends, a contract lapses, a compliance failure can't be cured, or activity stops for your defined inactivity period (commonly 18 months). Inactivation reduces both the fraud surface and the clutter - dormant-but-active records are exactly what fraudsters and duplicate payments exploit.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| The vendor lifecycle | The vendor lifecycle is the set of statuses a vendor moves through: requested, pending verification, active, inactive, and archived. | Keeps vendor records and payment decisions reliable. |
| Related terms | Deactivate (block new transactions, keep the record), archive (retain for history/retention), and delete (remove entirely) are very different. | Keeps vendor records and payment decisions reliable. |
| Vendor impact | On contract end, sustained inactivity (often 18 months), uncured compliance failure, or relationship termination - with AP or the vendor-management owner making the call under a defined policy. | Keeps evidence clear and reduces control risk. |
| Deactivate a vendor | Inactivation typically blocks new POs and invoices but leaves open invoices payable and history intact - though the exact behavior varies by ERP, so verify before bulk-inactivating. | Keeps vendor records and payment decisions reliable. |
| What should vendor reactivation | Treat reactivation like fresh onboarding: re-verify the W-9, re-verify and re-confirm banking through your call-back protocol, re-screen sanctions, and require approval. | Keeps vendor records and payment decisions reliable. |
Deactivate vs delete vs archive - why is deleting almost always wrong?
Deactivate (block new transactions, keep the record), archive (retain for history/retention), and delete (remove entirely) are very different. Deleting a vendor destroys payment history, 1099 totals, and audit trail - which you're often legally required to retain and will need at year-end or in an audit. The right move is almost always deactivate or archive; deletion should be rare and only for genuine errors (a true duplicate created and never used).
When should a vendor be inactivated and who decides?
On contract end, sustained inactivity (often 18 months), uncured compliance failure, or relationship termination - with AP or the vendor-management owner making the call under a defined policy. The decision should be a documented step, not an ad-hoc cleanup, so reactivation later is also controlled.
How do I deactivate a vendor in my ERP and what happens to open items?
Inactivation typically blocks new POs and invoices but leaves open invoices payable and history intact - though the exact behavior varies by ERP, so verify before bulk-inactivating. Settle or account for open items first; the goal is to stop *new* activity without stranding payments in flight.
What should vendor reactivation require?
Treat reactivation like fresh onboarding: re-verify the W-9, re-verify and re-confirm banking through your call-back protocol, re-screen sanctions, and require approval. A vendor dormant for years is effectively a new risk - its old data may be stale, and reactivation is a known fraud entry point.
A vendor inactive for three years suddenly has an invoice - red flag or legitimate?
Both are possible, so verify before paying: confirm the invoice is genuine, re-verify banking independently, and treat any banking that changed during dormancy as high-risk. Quiet reactivation of a dormant record is a classic fraud pattern - the controlled response is re-onboarding diligence, not a reflexive payment.
Why are dormant active vendors a fraud risk?
A vendor that's "active" in the system but hasn't transacted in years is a perfect disguise - a fraudster can reactivate it and redirect a payment with less scrutiny than a brand-new vendor draws. Aggressive deactivation shrinks the population of records that can be quietly exploited, which is the case for short inactivity thresholds.
How do I bulk-deactivate 18-month-inactive vendors without breaking this year's 1099s?
Exclude any vendor with reportable payments in the current tax year from the deactivation batch - deactivation usually doesn't erase 1099 data, but verify your system still includes deactivated vendors in 1099 reporting before relying on it. Run the deactivation, then confirm your 1099 population is still complete.
How long must we retain vendor records and tax forms after the relationship ends?
Retain tax documentation (W-9s, 1099 data) and supporting records for at least the IRS-recommended period - generally several years, with longer holds prudent for certain documents - and follow any industry or contractual retention rules. This is the core reason to archive rather than delete: the retention clock outlives the relationship.
How should vendor offboarding work?
Settle the final payment, refund or resolve any credit balance, revoke portal access, re-verify there's no pending banking change, set the record to inactive/archived, and document the closure. A clean offboarding closes the relationship without leaving an open, exploitable record behind.
Stampli perspective
Stampli keeps each vendor's full interaction history - invoices, payments, documents, and communications - on the record, so inactivating a vendor preserves the trail you'll need for 1099s, audits, and any future re-engagement rather than losing it. Because payment activity is visible per vendor, teams can see which records are genuinely dormant before acting, and controlled reactivation can route a returning vendor back through review instead of silently re-opening a stale, unverified record.