For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
This guide is part of the User Guides collection. For what each country asks for, field by field, see Supplier countries.
This is a gated feature. If you do not see a Know Your Supplier tab on your vendors, it has not been switched on for your organization yet. Ask your Coverbase contact.
The short version
1
You ask
Add a bank details, site, tax registration or diversity question to a questionnaire, and send it as you would any other. There is no separate portal for a supplier to learn.
2
The supplier answers
They pick their country, and the form changes to that country’s fields. Each field is checked as they type, so a mistyped check digit is caught while they are still looking at it.
3
Coverbase checks it
On submission, everything is validated again on the server. Errors block the submission and say why. Warnings are recorded and let it through.
4
A reviewer decides (for bank changes)
A new or changed bank account waits in a queue. The supplier’s live account is untouched until someone approves the change.
5
Your finance system hears about it
Approval fires a webhook and the record shows up in the API feed your integration polls. Rejection does not, because from your finance system’s point of view the change never happened.
Where this lives
Three places, depending on who you are.On the vendor
A Know Your Supplier tab on every vendor. Bank accounts, sites, tax registrations, diversity records, legal entity assignments, pending changes, and the full change history.
In a questionnaire
Four question types you can drop into any Know Your Supplier or onboarding questionnaire. This is how suppliers actually fill things in.
In configuration
Configuration → Know Your Supplier for the policy, and Configuration → Legal entities for the entities suppliers get assigned to.
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 is a deliberate choice and it buys you a lot: assignment, reminders, progress tracking, autofill and review all work exactly as they already do, and a supplier who has filled in one Coverbase questionnaire already 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:
They do not appear on assessments or RFPs, because there is no supplier profile behind those to write into.
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, or if you have ever wondered where the account number goes. 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.
An import from your own finance system can carry its own tax region, and that value wins. Nothing else overwrites it.
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 a five digit sort code is a real thing people type and the leading zero is genuinely implied.Then errors and warnings, which are not the same thing
An error blocks
The field is required and empty, the length is wrong, the pattern does not match, or a checksum failed. The submission is refused and the message names the field and the reason.
A warning informs
Something looks unusual but we are not certain enough about that country’s rules to reject a real supplier over it. The record saves, the warning is recorded against it, and a reviewer sees it.
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 the whole reason 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 just 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 genuinely 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.
These are organization wide permissions rather than per vendor ones. There is no assignment model on a bank account, so “owns the vendor” is not a route to approving its bank changes. That is on purpose.
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; turning it off is a deliberate decision.
Review and approval
Review and approval
Bank changes need a reviewer is on by default and is the fraud control described above. Legal entity assignments need approval is off by default, because an assignment is an administrative fact rather than a payment instruction. Notify these people decides who hears about a queued change; leave it empty and the vendor’s relationship owners are told instead, so a half configured organization still reaches a human.
What suppliers are asked for
What suppliers are asked for
Collect IBAN and Collect country specific extras apply across every country. Turning an extra off skips fields such as a building society roll number or a branch code that only some countries use. Diversity certifications narrows certificate collection to named countries; leave it empty to collect everywhere.A diversity record carries an inclusion category and a business size. The category list follows the certification programs the United States and Canada run, so a supplier picks the one they hold a certificate for rather than describing themselves. Business size is Large, Medium or Small, and is taken from the certificate rather than worked out from headcount, because the size a supplier is certified under is the one the program counts.
Limits
Limits
How many bank accounts and sites one supplier may hold, and how many profile writes a supplier portal may make per hour. The rate limit is deliberately low. Profile edits are rare, so a burst is far more likely to be an attack than a real supplier.
Update requests
Update requests
When you ask an existing supplier to refresh their profile, these are the defaults: which sections the request covers, and how long the supplier’s link stays usable. The person sending a request can narrow the sections for that request.
Legal entities
Configuration → Legal entities is the list of your own contracting entities that suppliers get assigned to. The entity code is the field that matters: it is what your finance system matches on, so it has to be exactly what that system expects. Entities can be imported from CSV, which upserts on the entity code and reports the outcome per row. Deactivating an entity blocks new assignments and leaves existing ones alone. One assignment request covers up to five entities. A request that quotes a purchase requisition raised more than thirty days ago needs a justification before it is accepted; a request quoting no requisition cannot be stale and is not asked for one.Country rules
The 109 countries ship with rules already configured, and those are documented per country in Supplier countries. Your organization can override any country’s rules for its own suppliers, which is how a late correction from your finance team becomes a configuration change rather than a release.Getting it into your finance system
Two ways, and most integrations use both.Webhooks
Fired when a record is created, changed, approved or rejected. Payloads carry masked identifiers and an idempotency key drawn from the change event, so a redelivery cannot double apply.
The changes feed
A polling endpoint that returns everything that changed since a cursor you hold. Use it to reconcile after an outage, or as your primary path if you would rather poll than receive.
When something goes wrong
Where to next
Supplier countries
All 109 countries, with the exact fields, formats, checksums and registers for each one.
Requesting a vendor
What happens before any of this: how a supplier gets into Coverbase in the first place.