> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coverbase.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Supplier information guide
> How supplier bank details, addresses, tax registrations and diversity records are collected, checked against the rules for the supplier's country, reviewed, and handed to your finance system.
For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](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](/user-guides/overview) collection. For what each country asks for, field by field, see [Supplier countries](/user-guides/supplier-countries/overview).
Onboarding a supplier eventually comes down to a handful of facts you have to get exactly right: where to send the money, where the supplier is, what it is registered as for tax, and whether it qualifies under any diversity program you run. Get a digit wrong in a bank account and the payment fails or, worse, lands somewhere else. Ask for the wrong fields and the supplier gives up halfway through the form.
This part of Coverbase is built around one idea: the country decides the questions. A supplier banking in the United Kingdom is asked for a sort code and an eight digit account number. A supplier banking in Japan is asked for a bank code, a branch code and a deposit type. Nobody is asked for a field their country does not use, and nothing is accepted that the country's own format rules reject.
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
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.
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.
On submission, everything is validated again on the server. Errors block the submission and say why. Warnings are recorded and let it through.
A new or changed bank account waits in a queue. The supplier's live account is untouched until someone approves the change.
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.
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.
Four question types you can drop into any Know Your Supplier or onboarding questionnaire. This is how suppliers fill things in.
**Configuration → Know Your Supplier** for the policy, and **Configuration → Legal entities** for the entities suppliers get assigned to.
## 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:
| Question type | What the supplier fills in |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Bank account details | Country, then that country's bank fields, plus IBAN and SWIFT where they apply |
| Supplier site | An address, with the postal code checked against the national format, and the email addresses purchase orders and remittance advice go to |
| Tax registration | The tax and company identifiers that country uses, such as a VAT number or a company number, or a declared exemption in place of one |
| Diversity record | An inclusion category, a business size, the certifying body, and the certificate's validity dates |
They do not appear on assessments or RFPs, because there is no supplier profile behind those to write into.
### 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.
These answers cannot be edited through the follow up spreadsheet. A spreadsheet is a text file that anyone in the chain can edit, and accepting one would let a pasted row point an answer at a record it should not reference. The spreadsheet skips these questions and says so.
### 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.
### 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.
| Value | Where it comes from |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tax region | The address. It is the country code, or the country and state for the four countries that levy tax below national level: the United States, Canada, India and Brazil. |
| Payment method | Whether the account is cross border. An account held in a country none of your assigned legal entities pay from goes out by wire; anything else is domestic. |
| Bank code and bank taxpayer ID, where a bank list exists | The bank the supplier picked, as described above. |
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 people do type five digit sort codes and the leading zero is implied.
### Then errors and warnings, which are not the same thing
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.
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.
Each country page carries a **rule confidence** rating, and it is a statement about our evidence, not about the supplier. Where a rule is confirmed against a primary source such as a tax authority or a central bank, it is enforced strictly. Where it comes from secondary documentation, it warns instead. Promoting a rule without evidence would mean rejecting suppliers who are doing nothing wrong, which is the failure this is built to avoid.
### 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](/user-guides/supplier-countries/overview).
### 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.
| Rule | What it does |
| -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Cross border payment | An account in a country none of your assigned legal entities pay from needs a SWIFT/BIC, because the payment goes out by wire. The supplier is told rather than blocked, and the derived payment method is stored on the account. |
| Currency held for local suppliers only | BRL is refused on an account whose supplier is not in Brazil. The test is the supplier's own country, not the bank's, so a Brazilian supplier banking abroad still qualifies. |
| The IBAN and the fields inside it | Where a supplier gives both an IBAN and the bank, branch or account codes separately, those codes must appear inside the IBAN. A mismatch is a warning, because the two came from different documents and either could be the stale one. |
| A name in the local script | Twelve countries write in a script a romanized name cannot stand in for, among them Japan, China, Korea and Greece. The form asks for the legal name in that script alongside the romanized one, and warns if what is typed is not in it. |
| A registration without its certificate | Thirteen Latin American countries ship the certificate that proves a registration. This warns rather than blocks: a supplier who has the number but not the PDF to hand can still finish. |
## 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.
Two things enforce the control:
* **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.
| Permission | What it allows |
| ------------------------- | ----------------------------------------------------------------------------------- |
| Supplier banking: read | Reveal a full bank identifier. Without it, everyone sees the last four digits only. |
| Supplier banking: update | Enter or edit bank details on a supplier's behalf. Does not approve anything. |
| Supplier banking: approve | Decide a queued bank change. |
| Supplier profile: read | Reveal a full tax identifier. |
| Supplier profile: update | Edit sites, tax registrations, diversity records and legal entity assignments. |
| Supplier profile: approve | Decide a queued legal entity assignment. |
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.
Every reveal of a full identifier is recorded. Everywhere else, and that means change events, webhook payloads, delivery logs and API responses that are not explicitly a reveal, only the last four digits exist.
## Configuring it for your organization
**Configuration → Know Your Supplier** holds the policy. Everything on it is per organization.
**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.
**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.
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 low. Profile edits are rare, so a burst is far more likely to be an attack than a real supplier.
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 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](/user-guides/supplier-countries/overview). 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.
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.
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.
A bank change's webhook fires on approval, not on submission. If you are testing the integration and a submitted change is not showing up, that is almost always why: check the review queue.
## When something goes wrong
| What you see | What it usually means |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The supplier says a valid account number is rejected | Check the country on the form. The fields follow the country of the bank account, not the country of the supplier. |
| A check digit error the supplier insists is wrong | Have them re-read the identifier from the bank's own document rather than from an invoice template. Transposed digits are the most common cause. |
| A warning on an otherwise fine record | The rule is a suggested one for that country. The record saved. The country page says which rules are suggested and why. |
| A supplier's new bank details are not in the finance system | The change is waiting in the review queue. Nothing is sent until it is approved. |
| Nothing was sent after approval | Check webhook delivery, then reconcile with the changes feed. |
| "This supplier already has N bank accounts" | The organization's bank account limit. Raise it in configuration, or retire an account that is no longer used. |
| Registry confirmation stuck as pending | The register was unreachable. It retries on a schedule, and a reviewer can retry it by hand. It never blocks anything. |
| A warning asking for a SWIFT/BIC on a domestic-looking account | The account's country is not one your assigned legal entities pay from, so the payment is treated as a wire. Check the legal entities assigned to that supplier. |
| A Colombian supplier is asked for a bank statement | They typed a bank name the list does not hold. Have them check the spelling against their statement; a bank on the list fills its own details in and asks for nothing. |
| "BRL is not available for this supplier" | BRL is held for suppliers in Brazil. The test is the supplier's own country, not the bank's. |
| A warning that the IBAN and the bank codes disagree | The two were taken from different documents. Have the supplier confirm which is current, usually the IBAN. |
## Where to next
All 109 countries, with the exact fields, formats, checksums and registers for each one.
What happens before any of this: how a supplier gets into Coverbase in the first place.