The short version
You ask
The supplier answers
Coverbase checks it
A reviewer decides (for bank changes)
Your finance system hears about it
Where this lives
Three places, depending on who you are.On the vendor
In a questionnaire
In configuration

The Know Your Supplier tab on a vendor. Bank accounts are masked to the last four digits until someone with the reveal permission asks to see one.
Asking a supplier: the four question types
Supplier information is collected through the questionnaire engine rather than through a separate flow. That means assignment, reminders, progress tracking, autofill and review all work as they already do, and a supplier who has filled in one Coverbase questionnaire knows how to fill in this one. When you author a questionnaire of type Know Your Supplier or Vendor onboarding, four extra response types appear alongside the usual free text and multiple choice:
A bank details question as the supplier sees it. Changing the country changes the fields below it.

The other three types are the same form with a different field set. A country with more than one tax identifier asks which one is being given.
What the answer actually stores
This matters if you export questionnaire responses. The answer to one of these questions is a reference, not a payload. When the supplier submits, the real values go into their own table, encrypted. What lands in the questionnaire response is a row id plus a masked summary: the last four digits, the country, and the validation outcome. Every reader of questionnaire responses, including the CSV export, the follow up spreadsheet round trip and autofill, therefore sees the summary and never the identifier.Offering a live bank connection
A bank details question has one setting: Offer a live bank connection. It is off by default. Turn it on and the supplier gets the option to link their bank directly instead of typing account details. Leave it off and they only see the country form, and none of the connection logic runs. It is a per question choice rather than an organization wide one, because the ask is heavier than typing and you may want it on your main onboarding questionnaire but not on a quick refresh.
With the setting on, the supplier is offered the connection first and can still type the details instead.
Picking a known bank
Some countries ask for details the supplier has no way to look up. A Colombian form wants the bank’s own taxpayer ID, which appears on a bank statement but not on anything a supplier keeps to hand. Where Coverbase holds a bank list for the country, the supplier picks their bank from a searchable list instead of typing its name, and the fields the list knows are filled in for them. Picking a Colombian bank fills in its code and its taxpayer ID. A bank the list has never seen is typed as free text. Nothing is filled in, because there is nothing to fill it in from, and the supplier is asked for a recent bank statement showing the account belongs to them. Colombia is the only country that asks for that statement today.What a supplier is not asked for
Three values reach your finance system without a supplier ever seeing them, because a supplier has no way to know the right answer and a wrong guess is worse than no answer.What happens when a supplier submits
Normalizing first
Before anything is judged, values are cleaned up in the way that country expects. Spaces come out of an IBAN. A United Kingdom sort code shorter than six digits is padded with leading zeros rather than rejected, because people do type five digit sort codes and the leading zero is implied.Then errors and warnings, which are not the same thing
An error blocks
A warning informs
Checksums
A checksum is a self checking digit built into an identifier: an IBAN, a US routing number, a Spanish NIF, a Mexican CLABE. It catches the most common human errors, a mistyped digit and a transposed pair, before the details ever reach your finance system. Coverbase implements the published algorithm for each identifier that has one, and only those. Where an identifier’s check digit rule is not publicly documented, the format is checked and the checksum is not invented. The per country pages say exactly which checks apply. See Supplier countries.Registry confirmation, afterwards
Where a public register exists, a tax or company registration is looked up in the background after it is saved. Companies House and HMRC for the United Kingdom, the VIES service for European VAT numbers, and so on. This is never part of validation. It runs afterwards, it annotates the record with what the register said, and a reviewer can retry it. A register being slow or down has no effect on a supplier’s ability to submit their details, which is why it sits outside the validation path.Rules that read more than one field
Most rules judge a field on its own. These read a second value, so they can only run on submission rather than as the supplier types.Addresses hold more than an address
An address carries the details your finance system needs to pay against it, not only the lines and the postal code.- Purpose. An address is a Primary or a Remittance address. An address is a registration address by carrying a tax registration rather than by being marked as one, so a single address can be both where the supplier is registered and where remittance advice goes.
- Email lists. Two lists per address: where purchase orders go, and where remittance advice goes. A malformed address is refused. A missing one is a warning, on the primary address and on any remittance address, and is never asked for in China.
- Tax registrations. A tax registration can attach to one address rather than to the supplier as a whole, which is how a supplier registered in more than one region records each registration against the site it belongs to.
Registrations a supplier is exempt from
A supplier who is exempt from a registration has no number to give. Ticking Exempt on a tax registration replaces the identifier with a reason, which is required. The two are alternatives: a submission carrying both is refused.Review: the part that stops fraud
Invoice redirection fraud, where an attacker persuades someone to change a supplier’s bank details, is one of the most common and most expensive attacks in accounts payable. The review queue exists for it. By default, a bank change never touches the live account. It goes into a queue and waits. The supplier sees that their submission is recorded and awaiting review. The account your finance system knows about is unchanged, and no webhook fires. When a reviewer approves, the change lands and the webhook goes out. When a reviewer rejects, nothing is restored, because nothing had been replaced.
The supplier changes queue. Each pending change shows what is being changed, who submitted it, and through which surface.
- Submitting and approving are different permissions. Someone who can enter a change cannot necessarily approve it. That includes your own staff entering details on a supplier’s behalf from the vendor tab.
- The change history is append only. Every supplier visible change writes an event, and nothing updates or deletes one. That history is the same source the API delta feed and the webhook payloads read from, so what a reviewer sees and what your finance system received cannot drift apart.
Who can see and do what
Two permission resources, each split three ways, so a reviewer does not have to also be an editor.
Staff entry on the vendor tab. The same country rules the supplier would have seen, and entering a change here still does not approve it.
Configuring it for your organization
Configuration → Know Your Supplier holds the policy. Everything on it is per organization.
Know Your Supplier settings. Bank review is on by default.
Review and approval
Review and approval
What suppliers are asked for
What suppliers are asked for
Limits
Limits
Update requests
Update requests