Sign in

Blog · Procurement and supply chain · Procurement

Measure supplier onboarding lead time by recorded stage

Separate registration information waits, review decisions and supplier-master activation from first purchase or delivery timing.

The short answerMeasure one supplier onboarding request through documented submission, complete-information, decision and activation milestones. Show stage durations for completed cases and dated open ages separately, while retaining incomplete information and unknown events.

Measure supplier onboarding through recorded stages rather than one blended interval from request to first invoice. Information gathering, approval and master-data activation can each create a different delay. Completed cases and still-open requests also need separate views.

Microsoft's vendor onboarding documentation describes registration information, review and approval, followed by vendor record creation. This is one example of a staged process; the report should use the actual events and approved meanings in the organization's source records.

Set the request grain and stage definitions

Use one onboarding request per proposed supplier, purchasing company and reviewed process scope. Multiple contacts or requested categories should not automatically create multiple completed supplier onboardings. A reapplication after rejection may be a new request or a new cycle according to the documented policy.

Inputs include request key, source supplier key, company, requested category, submission date, complete-information milestone, review tasks, return and resubmission events, decision outcome, master activation event and cutoff. Keep a history of decisions instead of reading the current supplier master as the entire process.

Use supplier identity normalization to connect aliases carefully. A similar name does not prove two registration requests concern the same supplier or company scope.

Choose clocks that answer a practical question

Submission-to-activation duration describes the entire observed request path. Complete-information-to-decision duration describes the review stage where that completeness event exists. Decision-to-activation duration can reveal a later master-data step.

For open requests, calculate age to the fixed cutoff and identify the current recorded stage. Label calendar days or business days explicitly. If business days are used, name the applicable calendar; never remove weekends without saying so.

Additional-information waits, rejected applications and withdrawals should be separate outcomes or stages. A request that was quickly rejected must not make activation turnaround appear faster. Missing completeness evidence prevents that particular stage calculation even if total submission age is known.

DEMO: four request paths

These requests are synthetic. Every displayed event occurs at 9:00 a.m. Eastern in October 2026. Durations use continuous calendar days, and the snapshot is October 6 at 9:00 a.m.

DEMO request Submitted Complete information Decision Activation or current state
A Oct. 1 Oct. 1 Approved Oct. 3 Active Oct. 4
B Oct. 1 Oct. 4 Approved Oct. 5 Active Oct. 6
C Oct. 2 Oct. 3 Not decided Open review
D Oct. 1 Unknown Not decided Information status unknown

A takes three calendar days from submission to activation: two to decision and one to activation. B takes five: three before complete information, one to decision and one to activation. Their completed total durations are three and five days; their median is four days for this two-case sample only.

C has four days total open age and three days since complete information. D has five days total open age, but its complete-information review age cannot be calculated. The decision is to inspect B's information returns, confirm C's current review task and obtain D's missing status evidence.

Interpret stage waits without implying verification

An approved status can support a process timing measure, but this article's report does not independently verify tax, banking, sanctions, insurance or other supplier checks. Retain references to authorized review evidence without publishing sensitive documents or personal contact details in the analytical pack.

Master activation may lag approval, or a source may create a provisional record before approval. Confirm the actual activation field and process. Do not substitute master creation for approval merely because its timestamp is easier to export.

Keep purchasing and delivery downstream

Requisition approval timing concerns individual purchase requests, not supplier registration. Supplier delivery lead-time variability concerns order-to-receipt timing after purchasing begins.

If first purchase matters, add a separately labeled activation-to-first-order interval with an explicit link. Suppliers with no purchase remain in a no-order-yet group, not as zero-day buyers. First invoice timing cannot reveal when the onboarding decision actually occurred.

Review a bounded process improvement

Reconcile the starting request population to active, rejected, withdrawn, open-known-stage and open-unknown-stage outcomes. Sample milestone histories and report coverage before comparing categories or companies with different review requirements.

The procurement review example illustrates a scoped decision pack with visible unknowns. Contact Covirage with the available milestones to discuss an onboarding-stage review; workflow execution and supplier approval remain in the responsible operating process.

Questions people ask

Does a supplier master record prove onboarding checks were completed?

Not by itself. Record creation and review evidence are separate events. The responsible process must confirm what the activation milestone means.

Should first purchase date end the onboarding clock?

Only for a separately labeled request-to-first-purchase measure. A supplier may be activated but never ordered from, so activation and purchasing answer different questions.