Vendor onboarding for a small team: what to collect before the first payment, and who checks it

At a small firm, vendor onboarding usually starts with a forwarded invoice and the words "can someone pay this?". The first payment goes out before anyone has a W-9, the bank details arrive in the same email thread as the invoice, and nobody owns chasing the certificate of insurance. Each gap has a price. The IRS expects 24 percent backup withholding when a payee has not given you a correct taxpayer identification number, and a bank-detail email you accept without checking is the business email compromise pattern behind the $55.5 billion in exposed losses the FBI's IC3 counted from October 2013 to December 2023.

This guide gives a team with no accounts payable clerk a vendor file sheet with one owner per item, a rule for what blocks payment, a callback rule for bank details, and a weekly check in Slack that chases whatever is still missing.

The short answer

1. Open one thread per new vendor, in one channel, the moment someone says they want to buy from them.
2. Collect five things before any money moves: legal name and address, a signed W-9, payment terms, bank details confirmed by a callback, and a certificate of insurance when the vendor works on site or touches client work.
3. Block the first payment until the file is complete. No exceptions for urgency.
4. Split the callback and the payment release between two people.
5. Run a weekly check that lists every vendor with a missing item and who owns it.

Why vendor onboarding breaks in a small team

Larger companies have a vendor master, an AP team and a procurement policy. A 15-person agency has a founder who signs contracts, an ops generalist who pays bills, and a project lead who found the freelancer. Three people each hold part of the vendor file, and none of them thinks the whole file is theirs.

The current guides describe the right documents but not the ownership. Melio's vendor onboarding steps cover collecting information, tax forms, payment setup and activation, and note that missing tax forms and bank details are the most common cause of delays, but they do not say who chases them. Trackado's checklist for small and midsize businesses goes further: it tiers vendors by risk, names one internal owner per relationship and holds the first invoice until setup is done. What it leaves open is the follow-up. Nothing in either guide tells you what happens on day four when the vendor has sent the invoice twice and the W-9 not at all.

That follow-up is where small teams lose. The person who needs the vendor wants them paid. The person who pays wants the paperwork. Nobody wants to be the one who emails a supplier for the third time about a tax form, so the payment goes out and the form is chased in January, when you need it for the 1099.

The vendor file sheet

Copy this table into your ops doc or a shared sheet. Each row is one item in the vendor file. The "blocks payment" column is the rule.

Three rules go with the table.

The W-9 name must match the legal name on the invoice and the bank account holder. If the W-9 says "Acme Print LLC" and the bank account is in a person's name, stop and ask. The IRS Form W-9 page has the current form to send; ask for it on the first email rather than after the first invoice.

The person who requested the vendor collects the items they already talk to the vendor about: name, terms, insurance. The ops lead collects the items that need care: the tax form and the bank details. That split keeps the requester in the loop without handing them the risky parts.

A contractor who is already working before anyone filed anything gets the same file, compressed. Collect the W-9 and confirm the bank details within the week; do not let "they already started" become "they never filed".

Try Kipwise Agent free in Slack: mention it once in a thread and it does the repetitive work, with your permissions.

Block the payment, do not review it

For a team without an accounts payable clerk, the strongest control is a payment block: nothing is paid to a vendor until its file is complete, however urgent the invoice looks.

A review step depends on someone remembering to review. A block depends only on a rule everyone can see. Trackado recommends holding the first invoice until setup is complete, and that is the right instinct for a small team, because the pressure to pay always arrives before the paperwork does. The vendor wants money, the requester wants the vendor happy, and a review becomes a formality under that pressure.

Make the block visible. When someone asks for a first payment, the answer is the vendor file sheet with the missing rows highlighted, not a judgement call. If the founder wants to override it, they say so in writing in the vendor's thread, and the override sits next to the missing item for anyone who looks later.

This is a recommendation built from the sources above; none of them states it as a rule for teams this size. It works because it removes the conversation that usually ends in "just pay it".

The callback rule for bank details

Take bank details on a call you start, from a number you found yourself, and treat every later change of bank details as a brand new vendor.

The rule has four lines:

1. Never accept bank details from an email alone, whether at setup or later. Trackado's checklist says the same, and the IC3 advises using a second channel to verify any request to change account information.
2. Find the vendor's phone number from a source other than the email that carried the details: their website, a contract, a past call. Call it. We recommend asking them to read the account holder name, the bank and the last four digits of the account to you, rather than reading your copy to them.
3. Write down who you spoke to, when, and what they confirmed. Bennett Financials' payment controls guide makes the point that a bank change with no callback record is a finding even when the payment turns out to be legitimate.
4. After any change, send one payment and confirm by phone that it arrived before you release the next, which is also Bennett's advice.

The reason for treating a change as a new vendor is that the attack rarely looks like an attack. One Hacker News commenter described a supplier whose mailbox was hijacked: the scammer replied inside a real email chain, quoted earlier messages, used a lookalike domain and asked for new transfer details. The payment went out, and in that account neither the bank, the police nor the insurer helped get it back. That is one person's report. Reading an email carefully for signs of fraud does not protect a small team, because a hijacked supplier inbox sends the change request from inside a real thread, so the only check that adds information is a call to a number you already had.

Split the callback from the payment

The person who phones a vendor to confirm bank details should not be the person who releases the payment, even in a team of five.

This sounds like enterprise process, and in a team of five it feels like overhead. It is the cheapest protection you have. If one person both confirms the bank details and sends the money, a single mistake, a single convincing phone call or a single compromised inbox goes straight through. With two people, the payer sees the callback note in the thread and the caller never touches the payment.

A workable split for most small teams:

• The ops lead makes the callback and writes the note.
• The founder or budget owner approves the first payment, and only after reading that note.
• Any later bank change goes back to step one, with the same two people.

If you only have one person who handles money, the founder becomes the second person. Bennett's guide offers a three-person segregation of duties matrix for firms that have not split these jobs yet; for a team under ten, two people and a written note are enough to start.

Run it in a Slack thread

Most of the work above is chasing: asking for a form, noticing it arrived, reminding someone it has not. An AI agent in Slack can carry that part while people keep the decisions.

Here is how it looks with the Kipwise agent, using only what it does today. The vendor name and amounts are made up for illustration.

A project lead posts in #vendors: "New vendor: Acme Print, first invoice next week, about $2,400 for the client brochures." They mention the agent and ask it to start the vendor file.

The agent drafts an email from the project lead's Gmail to Acme asking for a signed W-9, the certificate of insurance and payment terms. Before anything is sent, it shows an Approve card with the recipient, subject and a preview of the message. Nothing goes out unless the project lead approves it.

When Acme replies with attachments, the agent reads the text of the PDFs and posts in the thread which items have arrived and which are still missing, so the ops lead can check the W-9 name against the invoice without opening three emails.

The ops lead asks the agent to check every Monday morning which vendor threads still have a missing item and post the list in #vendors. A scheduled task like that needs approval once; after that it runs with the same tools and permissions as a live request from the person who set it up.

The ops lead makes the callback themselves, from a number on Acme's website, and writes the note in the thread. Once the founder has read it, the ops lead asks the agent to create Acme as a contact in QuickBooks or Xero. When explicitly asked, the agent creates the contact and always says which organisation or company it acted in.

What stays with people: the callback, the decision to approve the first payment, and any change of bank details later. The agent never makes the phone call and never decides that a file is complete enough to pay. That split matches the rules above, and it is the reason to keep the vendor's whole history in one thread: the next person who asks "did we ever verify these bank details?" finds the answer in the same place as the request.

If you already use Kipwise for bill approvals in accounts payable, the vendor thread is the step before it. A vendor with a complete file moves into the bill flow; a vendor without one cannot.

How it fails, and what to do

The vendor never sends the W-9. Keep the payment block. After two reminders, the requester calls the vendor; a supplier who will not send a tax form before being paid is telling you something.

The founder overrides the block for an urgent job. Let them, in writing in the thread, and keep the missing item on the Monday list until it arrives.

A vendor emails new bank details mid-project. Do not update anything. Start the callback rule from line one, with a number you found yourself, and treat the vendor as new until the call is logged.

The callback number is in the same email as the new details. That number is not yours to trust. Use the one on file or on their website, even if it means a slower answer.

Nobody remembers to look at the Monday list. Post it in the channel where the vendor threads live, mention the owners by name, and review the oldest item first in your weekly ops meeting.

How to know it is working

Three checks each quarter tell you whether the process holds:

• Every vendor paid this quarter has a W-9 on file. In January you should be able to prepare 1099s without emailing anyone.
• Every bank-detail entry and every change has a callback note with a name and a date.
• The Monday list is short and its items are less than two weeks old. A long list of old items means the block is being overridden quietly.

If one fails, fix the rule rather than adding a new tool. Usually the gap is a missing owner on one row of the sheet. For how approvals at different amounts fit together, the purchase order process for a small team and the delegation of authority guide cover the step before a vendor is chosen and the limits on who can approve.

What to do next

Copy the vendor file sheet into your ops doc today, write a name in every "who collects it" cell, and open one thread for the next new vendor before anyone pays them. Then pick your two people for the callback and the payment, and tell them the bank-detail rule in one sentence: no bank details from email, ever, without a call you started.