What Has to Be on File Before a New Vendor Is Paid
Adding a vendor is the least controlled act in most finance functions and the one with the largest downside.
In most companies I walk through, a new vendor gets created because somebody forwarded an email with an invoice attached, and the person entering it typed the name and the banking details straight off the PDF. That is the whole process. No form, no approval, no verification, nothing kept afterwards. It takes ninety seconds and it is the single act in the payment cycle with the least friction and the most consequence, because a payment run performs perfectly when the destination is wrong.
The reason it happens is that adding a vendor feels like data entry rather than a financial act. It is not data entry. It is the moment a bank account number enters your system, and every control downstream is an instruction to send money to whatever is in that field.
The AP control matrix covers who may hold this duty and why it must never sit with the person who releases payments. This piece is the other half: what has to exist before the record is switched on, and how the banking details get confirmed by somebody other than the person who received them.
A record is not a file
Two different things, and most companies have the first and not the second.
The record is the fields in the accounting system: name, address, terms, tax settings, bank account. It is what the payment run reads.
The file is the evidence behind those fields: the form, the documents, the checks that were run, the verification note, the approval. It is what somebody reads eighteen months later when a payment is questioned, or when a supplier says they never received it, or when an outside party asks how you knew the account belonged to who you thought it did.
A record with no file is a set of assertions nobody can test. The whole of this checklist is the file.
Before you ask for anything: is this a new vendor?
Run this first, because half of the “new vendor” requests I see are not new.
- Search the vendor list on the legal name, the operating name, and any abbreviation of either.
- Search on the street address and on the postal code separately. The same supplier arrives under three names and one address more often than under one name.
- Search the inactive vendors as well as the active ones. A dormant record being reactivated is a different and shorter path than a new one, and it needs its banking details reconfirmed rather than assumed.
- Search the payment history for the amount and the description, in case this supplier has been paid through an expense claim or a card and is only now becoming a vendor.
Duplicate records are how the same invoice gets paid twice, and duplicate payments cost small companies considerably more money than fraud does.
The onboarding sequence
Nine steps. On a normal vendor with a responsive contact it takes about twenty minutes of actual work spread over two or three days, and most of the elapsed time is waiting for someone to reply.
1. The request is raised by the person who wants to buy, and it names the spend. Who the vendor is, what is being bought, whether it is one-off or ongoing, and which budget it belongs to. A request with no stated purchase is a request to add a payee, which is a different and more suspicious thing.
2. The form goes out from finance, not from the requester. This is the step people skip and it does real work. Finance sends the vendor form directly to the supplier, to a contact obtained from the supplier’s own published channels rather than from the forwarded email chain. It closes the path where a compromised or spoofed thread supplies both the invoice and the banking details, with the requester in the middle in good faith.
3. The form comes back completed, from the supplier. Not retyped by the requester, not summarised in an email. The document the supplier sent.
4. Finance runs the desk checks. These are quick and they are done before anyone is asked to approve anything.
| Check | What you are looking for |
|---|---|
| Legal name against the operating name | A trading name with no legal entity behind it, which changes what you are contracting with |
| Registry existence check | That the entity exists and the name matches. Confirm the correct registry for the jurisdiction rather than assuming one. |
| Sales tax registration numbers | Validated before the first input tax credit is claimed. Confirm the right verification route with whoever reports on your statements. |
| Address against the employee master | An overlap is usually innocent and always worth a question |
| Bank account against the existing vendor list | The same account already attached to a different vendor name is the finding this check exists for |
| Contact details against the ones in the request | A mismatch is not proof of anything and it is the point at which you slow down |
5. Banking details are verified independently. The procedure is below. It is the control this whole document exists for.
6. Approval. The approver is named in your authority grid, and the approval is on the file rather than in a chat message. What the approver is confirming is narrow and should be stated that way: that the vendor is needed, that the checks were run, and that the verification note exists. They are not being asked to vouch for the supplier.
7. The record is created by someone who cannot release payments. System permissions, not an understanding.
8. The first payment is held for a confirmation. The first payment to a new vendor gets a short email to the supplier at the verified contact, on the day it is sent, saying the amount and the date. Not asking for anything. Just telling them. If the money went somewhere else, this is how you find out in days instead of at a statement reconciliation months later. It costs nothing and it is the highest-yield step in the whole sequence.
9. The file is closed and indexed. See below.
The independent confirmation of banking details
This is the part that gets described in one line in most control documents and then performed inconsistently, so here it is in full.
Who calls. Somebody other than the person who received the banking details. That is the entire principle, and every variant of this control that fails, fails on this point. If the requester also verifies, you have confirmed a document against itself.
What number. A number obtained independently: the supplier’s published number, a number on a prior signed contract, or a number from the registry record. Never the number in the email requesting the change, never the number on the invoice, and never a number the requester supplied. This is not a theoretical distinction. A convincing invoice carries a convincing phone number.
What is asked. Ask the supplier to state the account details. Do not read them out for confirmation. “Can you confirm the account ends in these four digits” invites a yes from anyone. “Please tell me the account you would like payment sent to” does not.
Who at the supplier. Someone in their finance or accounts function, reached through their main line, not a direct mobile provided in the correspondence. If the supplier is one person, that is fine, and the number still has to come from an independent source.
What gets written down. A dated note on the vendor file naming: who called, what number was dialled and where that number came from, who answered and their role, that the details were stated by them and matched, and the time. Six fields, one line each. A verification with no note did not happen, because in eighteen months nobody will remember it and the note is the only artifact.
When it is repeated. Every time banking details change, at any amount, for any reason, no exceptions and no thresholds. A change request is an onboarding, not a maintenance task, and it should be routed and worked exactly like one. The attack that actually lands on companies this size uses a real supplier whose account has quietly changed, not an invented one.
When there genuinely are not two people
In a company where one person handles all of accounts payable, the verification cannot be delegated sideways, so it goes up. The owner or the finance lead makes the call, or is copied on a recorded confirmation, and signs the note. That is slower and it is not negotiable, because this is the one duty in the payment cycle where the compensating control is not a review after the fact. A review afterwards finds out that the money went to the wrong place. It does not stop it.
Where this pattern applies more widely, and what to do when a company is too small to split any duty at all, is the subject of the financial controls work rather than something to solve one vendor at a time.
The file index
One folder per vendor, named consistently, with the same seven items in every one so a gap is visible without reading.
- The completed vendor form, as the supplier sent it.
- The contract, engagement letter, quote or accepted proposal, if there is one. If there is not, a note saying so.
- The desk check results, including the registry confirmation and the sales tax number validation.
- The banking verification note.
- The approval.
- A screenshot or export of the record as created, so the file can be compared to the system later.
- The change log: every subsequent amendment, what changed, who requested it, who verified it, who approved it.
The seventh is the one nobody sets up on day one and everybody wishes they had. A vendor file without a change log tells you what was true at onboarding and nothing about the eleven amendments since.
What does not go in the file
Collect what you need to pay a company and nothing else. The file contains banking details, which makes it one of the more sensitive things your company holds, and every additional field is a liability with no offsetting benefit.
Access to the folder is restricted to the people who perform this process. Not the whole finance shared drive, and not a general “Suppliers” folder that everybody can browse. This is a straightforward permission setting that almost nobody has applied, usually because the folder predates anyone thinking about it.
Three vendors that need more than the standard path
A related party. Any entity connected to an owner, a director or their family. Onboard it exactly like any other vendor, and additionally record who the connection is and get the arrangement approved by someone without the connection. Not because anybody is suspected, but because these arrangements get read closely by outside parties, and the file is the answer when they are.
An individual rather than a company. Whether a person you are about to set up as a vendor should instead be on payroll is a real question with real consequences, and it is not one the vendor form can settle. It depends on facts about the working relationship. Put it to whoever handles your payroll and tax reporting before the first payment rather than after the twelfth, because the answer is far cheaper to act on at the start.
A new payee introduced during something urgent. New vendor, plus urgency, plus a payment that cannot wait for the normal run, is the specific combination worth being slow about. The payment run controls treat off-cycle payments to new payees as requiring the owner every time, and the onboarding side of that is simply this: urgency is a reason to compress the elapsed time, never a reason to drop a step.
The emergency path, written down in advance
Because “we need to pay them today” will happen, and a process with no emergency path grows an unofficial one.
The permitted compression is: steps 1 through 4 done inside an hour, step 5 done properly with no shortcut, step 6 by the owner rather than the normal approver, and step 8 mandatory rather than good practice. What is never compressed is the independent verification, and the reason to write that down now is that it is the step under pressure in the moment.
If the supplier cannot be reached to verify, the payment waits. That sentence is the policy. It will be unpopular exactly once.
The vendors already on your list
Do not run a mass re-verification exercise. It is a large amount of work, it annoys every supplier you have, and it produces a file that is complete on the day it finishes and decaying from the next one.
Apply the standard forward instead. Every new vendor goes through the full sequence. Every banking detail change on an existing vendor triggers the verification and opens a file. Every dormant vendor being reactivated is treated as new. Within a year the vendors that actually matter, meaning the ones you pay and the ones whose details move, all have files, and the ones that do not are the ones nobody has paid, which is exactly the right place for the gap to be.