How to create a vendor onboarding process
How to design a vendor onboarding process that keeps qualification and enablement apart: the gate that has to be the only way into payment setup, and why enablement steps carry controls too.
A worked example, stage by stage
The one legitimate bypass
Intake is one row, and the rule arrives with it. "Submit vendor request form" is the only way in, and "Existing vendor can cover?" sends its "Yes" to "Raise order with existing vendor" — an order raised without diligence, allowed only because that supplier cleared it once already.
Five rows, nothing payable
The qualification half in full: "Collect due diligence pack", contract terms, "Run financial and credit check", the data protection review, then "Assign vendor risk tier". None of it creates a record an invoice could match against, which is what makes it safe to run this half slowly.
The gate between the halves
"High risk tier?" routes the suppliers that warrant it through "Run enhanced due diligence", and then "Due diligence cleared?" — where the only exit drawn so far is "Rejected", ending at "Reject vendor and notify requester". The approved route opens the second half, in the next stage.
The half that is not admin
The approved route reaches contract signature, then enablement produces a gate of its own: "Verify bank details by callback", held by "Bank details verified?". Only past it does "Create vendor master data record" appear — the first row an invoice could match, and the register entry follows.
How it works
Split qualification from enablement
Write two lists. Qualification is everything that establishes whether the organisation should trade with this supplier at all — due diligence, contract terms, financial standing, security and data protection, sanctions and ownership screening. Enablement is everything that makes them payable. Nothing from the second list belongs in the first.
Set the tiering rules before the first vendor
Decide what places a supplier in each risk tier — data sensitivity, annual spend, system access, how hard they would be to replace — and write the thresholds down. The tier has two jobs: setting the depth of this review, and setting the interval at which the supplier comes back. A tier that does neither is decoration.
Build both halves in one row list
Put every step in the Box text column in order, qualification first, then fill the Line to column with the row numbers each step leads to. Keep one action per row: a single row reading due diligence cannot show which of the four checks inside it is holding the file up, and that is the number people ask for.
Make the gate the only way in
Read the Line to column of every enablement row and confirm none of them is reachable except through the due-diligence row. Set that row's Shape to Decision and put both outcomes in Line text so the refusal is on the diagram. A gate that can be walked around is documentation rather than a control.
Put the two halves in the phase column
The phase goes in the Horizontal lane column — the example runs request, due diligence, risk tiering, contract, payment setup, activation — so the boundary between the two halves is a visible edge rather than something you trace by hand. A payment-setup row whose inbound arrow starts before the gate is the bypass.
Reconcile the vendor master against the gate
Export the current vendor master and mark every supplier with no cleared diligence behind it. Those are the records the gate would have refused, and their count is the backlog you inherit rather than a reason to start again: work the highest-spend ones down first, and give each survivor a tier and a reassessment date on the register.
Frequently asked questions
What is the difference between vendor onboarding and vendor approval?
Approval is the decision; onboarding is the whole path either side of it. Vendor approval answers whether the organisation is willing to trade with a supplier, and it is one gate. Onboarding covers the request behind it, the due diligence that informs it, and everything after it that makes the supplier operational — contract, bank verification, master data, register entry, review date. Conflating them is how organisations end up with an approved supplier who cannot be paid, or a payable one who was never approved.
What should a vendor due diligence pack contain?
At minimum: legal entity details and registration number, beneficial ownership, audited accounts or a credit report, insurance certificates with cover levels and expiry dates, tax registration, and the policies covering whatever the supplier touches — information security, data protection, anti-bribery, modern slavery. Add a sanctions and politically exposed person screen. What matters as much as the list is that every item has an expiry: an insurance certificate from three years ago evidences nothing.
What if a purchase order was raised before the vendor was approved?
Withdraw or hold the order, then finish qualification and re-issue it against the vendor record created afterwards. A purchase order against an uncleared vendor is a commitment nobody was asked to agree to, and clearing the vendor retrospectively is worse than not clearing them at all: the reviewer now knows a refusal costs a supplier relationship, which is exactly the pressure the gate exists to remove. Count these cases rather than settling them quietly — a rising count says qualification has become too slow.
How often should vendors be reassessed?
On the tier, and on events rather than on the calendar alone. Annual for high risk, every two years for medium and at renewal for low is a common baseline, but the triggers earn more than the cadence does: a new system integration, a breach at the supplier, a change of ownership, a material rise in spend, a bank detail change. Keep the date on the approved vendor register, because a register survives a reorganisation and a personal reminder does not.