SpendYou may know it as accounts payable
Automatic vendor setup
Collect vendor details through one request route, run your required checks, and prepare a vendor record for a person to approve before it is created.
What to expect: ideas for what could change, what you need first, and how to test whether it helps. Nothing here is a measured result.
- Impact: High
- Ease: Medium
- Prep: Some
Indicative rating based on the workflow described. Your readiness and implementation effort may differ.
Evidence status: Editorial / indicative assessment
What it does
Each vendor request is gathered into one record. Your required checks, such as tax details, bank details, sanctions screening and a search for existing vendors, are run and the results are shown beside the request.
A person reviews the record and the check results, and approves it under your policy. Nothing is created or activated for payment until they do.
Why it may help
Vendor setup is one place where bad data and fake vendors can get in.
- Details arrive by email and form, get retyped, and a duplicate or a false vendor can look like any other request. Fixing the vendor master later is slow.
- Gathering the details once and showing the check results with the request may cut retyping and make duplicates and odd details easier to see. Run it on past requests and compare with your baseline before you rely on it.
- The AP manager and the person who maintains the vendor master would see it first, as one record per request with the checks already run.
Where it starts, where it stops
- Starts at
- A requester asks for a new vendor.
- Ends at
- A person approves the record and it is created under your policy, or the request is rejected.
- Left out on purpose
- Approving or activating a vendor for payment
- Deciding which checks are mandatory, which stays with your policy
- Approving later bank-detail changes
- Payment release
One way it could run, and where people stay in
Illustrative workflow
This is an illustrative improvement approach, not a final solution design. The workflow, level of automation, integrations, and review requirements will depend on your existing tools, available capabilities, data quality, company policies, and team needs. Confirm these during discovery and a controlled pilot before implementation.
Today, by hand
- A requester emails details or a form to AP.
- A person retypes the details into the vendor master and checks what they can.
- Duplicates and wrong details can be found later, when a payment fails or a vendor is paid twice.
If you adopt it
- A requester submits a vendor request through the agreed route.
- The details are gathered into one record.
- Required checks are run and results shown, with possible matches to existing vendors.
- A person reviews the record and the results.
- A second approver reviews anything that failed a check, as your policy requires.
- After approval, the vendor is created, and the checks are kept with the record.
Checks that remain: Your policy still decides which checks are mandatory, and a person still approves. The requester cannot approve their own request or edit bank details.
When a field is uncertain: A passed check shows what was tested, which is different from proof that the vendor is genuine. Tell reviewers which checks ran and which did not, and send anything doubtful to a person.
Work it may add: A review of check results may add a step for some requests. Compare that with the time spent chasing missing details by email today.
Who does what
What AI does
- Gathers the request details into one record
- Runs the checks your policy requires and shows the results
- Suggests possible matches to existing vendors
What your system checks
- Blocks creation until a person has approved
- Raises items that fail a check for a second approver
- Keeps the request, results and approvals together
Finance team
- Review the record and the check results
- Approve, reject or ask for more information
- Complete any manual verification your policy requires
Process owner
- Sets which documents and checks are required
- Decides who may request, approve and edit vendors
- Reviews new vendors and bank changes each month, as someone outside AP
The system never creates or activates a vendor for payment without a person approving it.
What it could move, and how you would check
Of the five measures below, this use case may help five. These are expected effects to test against your own baseline, not measured results. The last column says how to check each one.
| Fact | Expected effect | Why |
|---|---|---|
| Process steps | Potential direct benefit | Less retyping per request, since the requester's details are gathered into one record before AP sees them.How to check it in a pilot: Compare handling steps and minutes per vendor request with your baseline. |
| Cycle time | Possible downstream benefit | Fewer email exchanges may get vendors ready sooner, though checks and approvals still take the time they take.How to check it in a pilot: Measure days from request to a vendor ready to pay. |
| Exception loops | Possible downstream benefit | Catching duplicates and wrong details earlier may mean fewer vendor records corrected later.How to check it in a pilot: Count vendor records corrected after creation and duplicate vendors found. |
| First-time-right rate | Potential direct benefit | More vendor records may be right the first time, with checks already run before creation.How to check it in a pilot: Track records created without later correction, and duplicates caught before creation. |
| Cost per invoice | Possible downstream benefit | Fewer email exchanges may lower the cost of each request, if review time and tool cost do not cancel the saving.How to check it in a pilot: Track time and tool cost per vendor request. |
What you need first
Ease of getting started: Medium. The tools exist. Some of the setup work is yours.
- A cleaned vendor master with duplicates merged and inactive vendors blocked.
- A written vendor setup policy covering required documents and approvers.
- ERP user roles that can be restricted so only approved records create vendors.
- The person who requests a vendor cannot approve it or edit its bank details.
- Every bank-detail change is verified by a call-back to a phone number already on file, not one supplied in the request.
Evidence to keep
- Each request with the details received and the check results
- The approval trail showing requester and approver as different people
- The call-back record for each bank-detail change
- The list of who can create or edit vendors in your ERP or AP system
- A monthly report of new vendors, reviewed by someone outside AP
What can go wrong, and how a pilot would show it
- A false vendor passes the checks that were run, because a needed check was not part of the setup.
- A duplicate vendor is created because the search missed a variant of the name.
- Manual vendor creation stays open, and people go around the request route.
- Reviewers approve without reading the check results.
- Some vendors cannot be covered by every check and need a manual path, such as a vendor with a foreign tax ID that cannot be checked against local records, or one whose country a bank-account check does not cover.
Year one, in hours
- New vendors per month, 300-person SaaS company (assumption)assumption
- 40
- Minutes per vendor today (assumption)assumption
- 60
- Minutes per vendor with the portal (assumption)assumption
- 15
- Hours saved per month (40 x 45 min)
- 30
- Hours saved per year
- 360
Illustrative, for a 300-person SaaS company. Every input is an assumption; replace it with your own monthly new-vendor count and a timed setup.
Your next step
List the vendors added in the last six months and time how long a typical setup took. Mark any duplicates found since. That gives you a baseline to compare the pilot against. Run the pilot on past requests only. Do not create live vendors from it until you have your own results.
The pilot steps are under "See how to test it" in the Ways to start panel. Paid support is optional: use Get implementation support if you want help.
How to test whether it improves the work
Effort by stage
- Pilot:
- Map the current setup, time a typical request, and run a starter set of about 100 past vendor requests, with a few known duplicates, as a discovery exercise. Mostly AP time, with some configuration help.
- Production:
- Connect the request route to your ERP or AP system, set the checks and approvals, and restrict manual vendor creation. Effort depends on your tools and the state of the vendor master.
- Ongoing:
- Work the review queue, keep the checks and approver lists current, and review new vendors each month.
What to measure, before and after
- Baseline:
- Handling minutes per vendor request today, and days from request to ready to pay.
- Duplicate vendors:
- How many known duplicates are flagged, and how many good requests are flagged wrongly.
- Check results:
- Which checks ran, which failed, and how each failure was handled.
- Approvals:
- Whether requester and approver were always different people.
- Time:
- Days from request to a vendor ready to pay.
- Starter set:
- About 100 requests is enough to learn from, not enough to prove it is ready for live use.
What we assumed when rating how easy this is
- Your vendor master has been reviewed for duplicates and inactive vendors.
- A written vendor setup policy lists required documents and approvers.
- Your ERP or AP system can limit who creates vendors.
- Someone owns the review queue and has time to work it.