Vendor onboarding process flowchart

What the vendor onboarding process is

Vendor onboarding is the path a new supplier takes from an initial business request to an active record in your finance system that can legitimately be paid. It normally crosses five functions: the requester who needs the vendor, procurement who runs the process, legal who reviews and signs the contract, finance who checks solvency and sets up payment, and security or compliance who decides how much risk the vendor carries. Most of the delay in the process comes from hand-offs between those groups rather than from the reviews themselves.

Two parts of the process do most of the work. The first is risk tiering. Rather than putting every supplier through an identical review, you classify them on data sensitivity, spend, system access and business criticality, then reserve enhanced due diligence for the high tier. The second is bank detail verification, which is the practical control against invoice redirection fraud. Verifying the account by calling the vendor on a number taken from the signed contract, and treating any later change of bank details as a fresh verification rather than a quick edit, is what stops payments reaching an attacker.

This template lays the process out as a cross-functional swimlane diagram so every hand-off is visible: where procurement passes to legal, where security returns a risk tier, where finance takes over for payment setup and master data. It carries on past the point where many documented processes stop, ending at the approved vendor register with a reassessment date attached, because a register that is never re-reviewed stops describing who you actually buy from within about a year.

What this flowchart covers

In this template

• Five swimlanes (Requester, Procurement, Legal, Finance, Security & compliance) across six phases: Request, Due diligence, Risk tiering, Contract, Payment setup and Activation.
• Intake in the Requester lane: identify the need, then submit a vendor request form carrying the business justification, spend estimate, the data or systems involved and a named internal owner.
• A duplicate check before any review work starts, where procurement asks whether an existing vendor can cover the need and routes those requests straight to an order against the existing contract.
• Three due diligence hand-offs in sequence: legal reviews contract terms and clauses, finance runs a financial and credit check, and security runs a data protection and information security review.
• Risk tiering with a real branch: 'Assign vendor risk tier' feeds 'High risk tier?', the Yes path runs enhanced due diligence, and both paths rejoin at the 'Due diligence cleared?' decision, which either moves to contract or rejects the vendor and notifies the requester.
• Contract negotiation, signature and filing of the executed copy in the Legal lane, then bank detail verification by callback in Finance with a re-verify loop when it fails, master data record creation, entry on the approved vendor register and a review date set before the vendor is marked active.

When to use this template

• You are writing or refreshing a procurement policy and want the steps and hand-offs agreed before anyone drafts the wording.
• Vendor requests keep stalling because nobody can say which function is currently holding the file.
• You have been asked to show how suppliers are assessed and approved, for a customer security questionnaire, an internal audit, or an ISO 27001 or SOC 2 readiness exercise.
• A payment fraud attempt or near miss has prompted a review of how bank details are captured, verified and changed.
• You are bringing new procurement or finance staff up to speed and want a one-page picture rather than a twenty-page procedure.

How it works

1. Match the swimlanes to your organisation

   Rename the five lanes to the functions that actually exist in your company. Smaller teams often merge Legal into Procurement, or run Security & compliance as a part-time role held by IT. Delete a lane rather than leaving it empty, and make sure every box sits in the lane that genuinely owns the work rather than the one that gets blamed for it.

2. Write down your risk tiering criteria

   Replace 'High risk tier?' with the test your company actually applies. Most organisations tier on whether the vendor processes personal or regulated data, annual spend, whether they get access to internal systems or premises, and how disruptive it would be to lose them. Record the thresholds next to the node so the decision is repeatable by whoever is on duty.

3. Define what enhanced due diligence requires

   Fill in what the high risk branch demands in practice: a SOC 2 report or penetration test summary, a subprocessor list, beneficial ownership and sanctions screening, references, or a site visit. If the branch does not name specific evidence, it will be skipped under time pressure.

4. Assign the bank verification control to a named role

   Decide who performs the callback and confirm it is not the same person who creates or edits the vendor master data record. Separating those two duties is the whole point of the control. Add the source of the phone number, which should be the signed contract or an independently obtained number, never the invoice or the email requesting the change.

5. Add your systems, owners and service levels

   Put real system names on the steps: where the request form lives, which ERP holds vendor master data, where the approved vendor register sits. Add the role that owns each box and a target turnaround for each lane so the process can be measured rather than only described.

6. Set the review cadence, then circulate for sign-off

   Choose reassessment intervals per risk tier and record the date on the register itself rather than in a personal calendar. Share the chart with procurement, legal, finance and security for comment, and keep it under version control so the approved diagram and the written procedure do not drift apart.

Frequently asked questions

How long should vendor onboarding take?

For a low risk vendor on standard terms, three to five working days is realistic once the due diligence pack is complete. High risk vendors typically take two to six weeks, because enhanced review, negotiated contract terms and security evidence all sit on the critical path and often run into the vendor's own approval cycles. The single biggest delay is usually waiting on documents from the vendor, which is why the request form and the due diligence pack come first in this flowchart, before any review work begins. If your median time is much longer than this, measure how long each lane holds the file rather than the process end to end.

What is vendor risk tiering, and how many tiers do we need?

Risk tiering classifies a vendor so the depth of review matches the exposure. Three tiers, high, medium and low, is enough for most companies; more than that tends to produce arguments about placement rather than better decisions. Common inputs are whether the vendor processes personal or regulated data, annual spend, whether they receive access to internal systems or premises, and how disruptive it would be to lose them at short notice. The tier should drive two separate things: what evidence you require before approval, and how often the vendor is reassessed afterwards.

Why is bank detail verification shown as its own step and decision?

Invoice redirection fraud works by sending a plausible request to change a supplier's bank account, usually from a spoofed lookalike domain or a genuinely compromised mailbox. The defence is procedural rather than technical: verify the account by calling the vendor on a number taken from the signed contract or independently sourced, never one supplied in the email or printed on the invoice, and record who verified it and when. Giving it a decision node with a re-verify loop makes it explicit that payment setup does not proceed on an unverified account, and the same check should apply to any change of bank details after onboarding.

Where should the approved vendor register live?

Wherever it lives, it needs a single owner and a review date against each vendor. A spreadsheet is workable at small scale provided changes are dated and attributable; dedicated procurement or third-party risk tooling handles it better once you pass a few hundred vendors. The failure mode is identical either way: vendors get added and never removed, so the register gradually stops reflecting who you actually buy from. Reassessing on the cadence set by the risk tier, and closing out vendors you no longer use, is what keeps it accurate.