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 vendor onboarding process qualifies a supplier and then enables them to be paid, and the control that matters is the gate between those two halves rather than the thoroughness of either one.
The short version
- Qualification and enablement are two processes, and only a gate should join them.
- A supplier with a master data record and no approval is already payable.
- A risk tier does no work unless it also sets when the supplier is looked at again.
- A purchase order raised before clearance has already committed the money the gate governs.
- Rejection needs a drawn ending, or refused suppliers get re-requested through another buyer.
Two processes sharing one name
Vendor onboarding is usually drawn as one sequence and is in fact two, with different owners and different questions. The first half qualifies: whether this supplier is an exposure the organisation is willing to carry at all. The second half enables: a master data record, bank details, payment terms, a purchase order the supplier can invoice against. Both halves are frequently well run. The failure is hardly ever inside one of them.
It is at the boundary. Enablement is what the requester wants, so it gets started early: a master data record opened to save time, bank details typed from a PDF, an order raised while legal is still reading. From that moment the organisation has a payable supplier nobody cleared, and that one condition is what most vendor fraud and most third-party audit findings share. "Due diligence cleared?" has to be the only route into the second half, and a diagram is what makes that checkable rather than cultural.
The example below is a supplier flow across five functions, and one row governs all of it: everything from "Negotiate and agree contract terms" onwards hangs off "Due diligence cleared?", whose "Rejected" branch is drawn as an ending rather than a pause. One enablement step then carries a gate of its own ("Verify bank details by callback" is followed by "Bank details verified?"), which is the tell that enablement is not administration. Starting it early is not premature, it is unguarded.
Build a vendor onboarding flow in four stages
Qualification then enablement, in six phases. Each stage adds work that leaves the supplier unpayable, until the last, where a single row ends that.
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.
Mistakes to avoid
Master data opened before approval
Creating the supplier record early feels harmless and produces a payable vendor nobody has cleared. Once the record exists an invoice can match against it, and the missing approval stays invisible until an audit samples the ledger.
Enhanced due diligence with no trigger
When the criteria for the high-risk route are not written on the decision, the depth of review is set by who is holding the file and how busy they are. Put the thresholds on the step and the routing becomes repeatable.
A rejected vendor with no ending
A refusal that is not drawn as a terminal state leaves the request half-alive, and half-alive requests get resubmitted through a different buyer who has no idea it was already refused.
Skipping the callback on a bank change
An amendment re-enters the enablement half without passing anything, so the callback (the one step that would have caught a redirect) is the step skipped. Route a change of account through the same verification as a new one.
Create your own vendor onboarding process
Take the example as your own chart, set tier thresholds you would defend, and confirm nothing in payment setup precedes the gate.
Related guides
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.