Vendor Onboarding Process in India: Steps, Documents and Checklist
Vendor problems rarely show up on day one. They surface months later, in places that look unrelated to onboarding.
Finance finds that TDS was deducted at the wrong rate. The buyer discovers it can't claim input tax credit on a run of invoices. A small supplier turns out to be owed interest for late payment. Now and then, a payment has already gone to an account the vendor never owned.
In India, these usually trace back to the same cause: a document collected at onboarding and never checked against its source.
That's why the vendor onboarding process deserves more than a document list. PAN, GSTIN, bank account and Udyam registration each carry a tax or payment consequence for the buyer, and they rarely sit with the same team. If they're filed away as attachments, the buyer ends up carrying risk it could have closed on day one.
This guide runs from intake to first payment. It covers what to verify on each core document, who should own each part of the vendor file, and a checklist you can use as it stands.
What is vendor onboarding?
Vendor onboarding means collecting, verifying and approving a new vendor's details so that the vendor can be contracted, entered in the vendor master and paid. The supplier onboarding process is the same thing under another name, and supplier selection (the sourcing decision about which vendor to use) happens before it begins.
Vendor registration is the vendor's half of the exchange, in which it submits its details and documents through a form or portal. Onboarding layers the buyer's checks, risk review and approvals on top of that, so a vendor that has registered is not yet cleared for payment.
Vendor due diligence is the risk review that sits inside onboarding. It goes deeper for vendors that will handle customer data, systems or funds, and KYC Hub's guide to vendor due diligence covers that review in depth.
The vendor onboarding process, step by step
Onboarding is the middle of the vendor lifecycle. Sourcing and selection come before it, and ongoing monitoring comes after.
Onboarding a vendor in India moves through seven stages. The seven stages below cover what happens between the decision to use a vendor and the first payment.
Stage | What happens | Owner | Output |
|---|---|---|---|
1. Intake and risk tier | Business team raises the request; scope, spend and access are assessed; a tier is assigned | Requesting team, procurement | Approved request with risk tier |
2. Collect information | One structured request to the vendor, sized to the tier | Procurement | Completed vendor submission |
3. Verify against source | PAN, GSTIN, bank account, Udyam and company records checked with the issuing systems; names matched | Finance / AP | Verified identity and tax data |
4. Risk screening and due diligence | Screening and deeper review, scaled by tier | Risk / compliance, information security | Risk decision on record |
5. Approvals | Each function signs off on its part | All owning functions | Recorded approvals |
6. Contract and vendor master | Contract, NDA, SLA signed; vendor code created from verified data | Legal, finance / AP | Signed contract, vendor master record |
7. Activation and first payment | First payment to the verified account; re-verification triggers set | Finance / AP | Active vendor |
1. Intake and risk tier
Everything starts when a business team raises a request to engage a vendor. That request should say what is being bought and roughly what the spend will be. It should also state whether the vendor will touch customer data, internal systems, funds or any regulated activity, since those answers set the risk tier; the tier, in turn, decides how much of the remaining process applies.
Tiering belongs at intake, ahead of any commercial commitment. Once procurement has chosen the vendor and agreed terms, a risk review that only begins at that point tends to become a formality (few organisations will reverse a decision already announced internally).
Intake is also when the vendor master should be searched for an existing record under the same PAN or GSTIN. A second code for the same vendor splits spend reporting and makes duplicate payments possible.
2. Collect information and documents
The vendor should receive one structured request, via a form or a vendor portal, asking for everything its tier requires. Asking once matters to the vendor as much as it does to the buyer. A well-built request explains what is needed and why, and it lets the vendor see where its application stands. The documents section below covers the core Indian set.
3. Verify the documents against the source
Here each identifier is checked against the system that issued it:
- PAN: the Income Tax e-filing portal
- GSTIN: the GST portal
- Bank account: the vendor's bank, through penny drop
- MSME status: the Udyam portal
- Companies and LLPs: Ministry of Corporate Affairs master data
Once the sources respond, the names they return are compared with one another; any divergence has to be explained before the file moves on.
4. Risk screening and due diligence (by tier)
Low-tier vendors usually need little beyond identity verification. Higher tiers bring in beneficial ownership, sanctions and adverse-media screening and a look at financial standing, plus an information security assessment whenever the vendor will access data or systems. How deep this stage goes should follow the tier set at intake. What that screening covers is set out in KYC Hub's guide to Know Your Vendor (KYV) checks.
5. Approvals
Every function signs off on the part of the file it owns, under approval rules that follow tier and spend. Each approval belongs on the vendor record, together with the approver's name and the date.
6. Contract and vendor master set-up
Legal finalises the contract, NDA and SLA while finance creates the vendor code. The vendor master is the real output of onboarding. Several of its fields should be populated from verified sources:
- Legal name as per PAN
- PAN and its operative status
- GSTIN for each state of supply, with registration status
- Applicable TDS section and rate
- MSME flag and enterprise type (micro, small or medium)
- Payment terms, capped where the supplier is a micro or small enterprise
- Bank account, verified by penny drop
Expiry dates for insurance, licences and certifications are entered at the same stage, which is what allows renewals to be tracked later.
7. Activation, first payment and re-verification triggers
Only the verified account should receive the first payment. Activation is also the moment to define which events reopen the vendor file. A request to change bank details is one; so is a GST registration that gets cancelled or suspended. A PAN that becomes inoperative should send the file back as well, and so should a change in the vendor's ownership or legal name. Ongoing monitoring is its own discipline, and onboarding's part is limited to defining what sends a vendor back through verification.
Vendor onboarding documents in India: what to collect and what to verify
Each core document establishes a particular fact about the vendor, and when its check is skipped the cost lands on the buyer in a predictable form. This is guidance on process design, not legal or tax advice, and each organisation should confirm the applicable provisions against its own facts.
Document | What it proves | What to verify | If skipped |
|---|---|---|---|
PAN | Tax identity of the vendor | PAN exists, name and date match, PAN is operative | TDS at a higher rate; shortfall falls on the buyer |
GSTIN | GST registration in a state | Status is Active, legal name matches PAN, returns filed | Input tax credit at risk |
Bank account | Where payments go | Holder name via penny drop matches PAN/GST name | Payment to an account the vendor does not own |
Udyam registration | MSME status and type | Number valid on Udyam portal, enterprise type recorded | Late-payment interest and deferred tax deduction |
CIN / LLPIN | Company or LLP exists | Status and name on MCA master data | Contracting with a struck-off or misnamed entity |
Contracts, licences, certifications | Legal terms and category permissions | Signatory authority, validity and expiry | Unenforceable terms, lapsed cover |
PAN
A PAN check passes when the PAN exists and the name and date of birth or incorporation match the vendor's declared legal name. On the Income Tax e-filing portal, the pre-login "Verify Your PAN" service tests a PAN, full name and date of birth or incorporation against the PAN database. The methods are covered in KYC Hub's guide to PAN verification.
With individual and proprietor vendors, whether the PAN is operative matters as much as whether it is valid. The Income-tax Act, 2025 has been in force since 1 April 2026. Under it, a PAN holder who is eligible for Aadhaar must intimate the Aadhaar number, and the PAN of a holder who fails to do so is made inoperative (s.262(6)). Since 1 July 2023, payments to holders of inoperative PANs have attracted TDS and TCS at the higher rates (CBDT Circular 3/2023, 28 March 2023). In the 2025 Act the higher-rate rule sits in s.397(2), formerly s.206AA and s.206CC of the 1961 Act: where a valid PAN is not furnished, tax is deducted at the higher of the specified rate, the rates in force, or 20% in most cases.
Any shortfall falls on the buyer as deductor. That is why operative status belongs in the onboarding check; at that point, any problem can still be resolved before the first payment goes out. Companies, LLPs and firms have no linkage to check, because Aadhaar is issued to individuals.
GSTIN
Without any login, the GST portal's Search Taxpayer function returns the registration status (Active, Suspended or Cancelled, with the date of cancellation), legal name and trade name, constitution of business, principal place of business and the return-filing record. For the check to pass, the registration must be active and its legal name must match the PAN name; the filing record should also show no unexplained gaps. Because GST registration is PAN-based (CGST Act s.25(6)), the PAN behind the GSTIN has to be the vendor's own.
Skipping this check puts the cost on the buyer's input tax credit. CGST Act s.16(2) makes credit conditional on several things. The buyer must hold an invoice from a supplier registered under the Act (clause (a)). Clause (aa), in force from 1 January 2022 under Notification 39/2021-Central Tax, requires the supplier to have furnished the invoice details in its outward-supply statement (GSTR-1) and for those details to have been communicated to the buyer. Rule 36(4) of the CGST Rules adds that credit can be taken only on invoices reflected in the buyer's GSTR-2B. Tax must also have actually been paid to the Government (clause (c)). Credit is exposed whenever a vendor is unregistered, cancelled or not filing, so GST status needs rechecking for as long as the vendor remains active.
Registration under GST is state-wise (CGST Act s.25). A vendor supplying from several states may therefore hold a GSTIN in each, and the vendor master should record whichever GSTIN matches each supply location.
Bank account
The vendor provides a cancelled cheque or a bank letter. Finance then verifies the account by penny drop, which sends a small credit to the account and returns the holder's name as the bank holds it. That name should match the PAN and GST legal name. If it does not, onboarding stops until the mismatch is explained; a cancelled cheque proves only that a cheque leaf exists. KYC Hub's guides to penny drop verification and bank account verification explain the methods.
After onboarding, no event in the vendor relationship carries more risk than a request to change bank details. A fraudster who controls or imitates a vendor's mailbox needs just one accepted change request to redirect the next payment. The control should be a written rule: a bank change is never actioned on email alone, and before it takes effect the new account is re-verified by penny drop and the change confirmed through a contact already on file. How these schemes unfold is described in KYC Hub's analysis of invoice redirection fraud.
Udyam (MSME) registration
The Udyam Registration Number can be checked on the official Udyam portal, under Print/Verify, using "Verify Udyam Registration". Finance should record the enterprise type alongside the number.
Payment terms depend on that enterprise type. Where supplies come from micro and small enterprises, the MSMED Act, 2006 caps the agreed payment period at 45 days from acceptance or deemed acceptance (s.15). Late payment attracts compound interest, with monthly rests, at three times the bank rate notified by the Reserve Bank of India (s.16). The Income-tax Act, 2025 then layers a tax cost on top: a sum owed to a micro or small enterprise and paid later than the s.15 time limit (the agreed payment period, which cannot exceed 45 days) is deductible only in the year it is actually paid (s.37(2)(g), formerly s.43B(h)). Paying before the return due date cures every other item in that list; this one is the exception (s.37(3)).
Since the MSME flag drives payment terms, it needs to be in the vendor master before the first invoice is booked. Medium enterprises fall outside the 45-day limit, so recording the enterprise type matters as much as recording the flag itself.
Company or firm identity (CIN, LLPIN)
For companies and LLPs, Ministry of Corporate Affairs master data confirms the entity's status and registered name; both should agree with the PAN and GST records. KYC Hub's guide to verifying a company through MCA and GSTIN goes into the detail.
Contracts, licences and certifications
What remains of the file is the NDA, SLA and signed contract, along with the authorised signatory's identity and authority to sign. Any licences, insurance and security certifications the category requires also belong here. Each carries an expiry date, and renewal tracking is only possible if that date is captured at onboarding.
Vendor onboarding checklist
The checklist is grouped by stage, with each item written as a check that has a pass condition. Items marked (tier) apply to higher-risk vendors only. It serves equally well as a supplier onboarding checklist.
Intake - The request covers scope and expected spend, and states any access to data, systems or funds. - A risk tier is assigned before commercial terms are agreed. - No existing vendor record shares the PAN or GSTIN.
Documents - The vendor has received a single request sized to its tier. - Every document mandatory for the tier is in.
Verification - PAN is valid and operative, and it matches the declared name and date. - GSTIN status is Active, with a legal name that matches the PAN name. - The GSTIN filing record has no unexplained gaps. - The penny-drop name matches the PAN and GST legal name. - The Udyam number verifies on the portal; enterprise type is recorded. - For companies and LLPs, the CIN or LLPIN shows active status and a matching name.
Risk - Sanctions and adverse-media screening returns no unresolved match (tier). - Beneficial ownership is identified and recorded (tier). - Where the vendor accesses data or systems, the information security review is complete (tier).
Approvals - Each owning function has signed off on its part. - Approvals agree with the spend and tier matrix.
Vendor master - Legal name, PAN, GSTIN per state, TDS section, MSME type and bank account all come from verified data. - Payment terms for micro and small suppliers do not exceed 45 days. - Expiry dates for insurance, licences and certifications are on record.
Activation - The first payment goes only to the verified account. - Re-verification triggers are set for bank changes, GST status, PAN status and ownership changes.
Who owns what: the vendor file across teams
Several functions assemble a vendor file between them, and each is responsible for a different part of the risk.
Function | Owns | Typical sign-off |
|---|---|---|
Procurement | Intake, commercial terms, vendor communication | Commercial approval |
Finance / AP | PAN, GST, bank account, TDS, MSME terms, vendor master | Vendor master creation, payment release |
Information security | Data and system access review | Security approval (tier) |
Legal | Contract, NDA, SLA, signatory authority | Contract execution |
Risk / compliance | Screening and due diligence | Risk approval (tier) |
Onboarding usually stalls in the gaps between these teams. Each keeps its piece of the file in its own inbox or spreadsheet, so the security questionnaire waits in one place while the financials sit somewhere else, and nobody has sight of the file as a whole. Later, when an auditor or inspector asks how a vendor was approved, someone has to rebuild the answer by hand from email threads.
The design remedy is a single shared vendor record. Every team works its own part of it, while each check and approval is written to the record as it happens. KYC Hub's Know Your Supplier workflow is built on this model: procurement, finance, information security, risk and legal each have their own queue on the same vendor record, and the checks and approvals they complete are kept in one regulator-ready audit trail.
Vendor onboarding policy and questionnaire
What a vendor onboarding policy should fix in writing
A vendor onboarding policy converts the process into rules that hold regardless of who handles the file. It should define the risk tiers, the mandatory checks for each tier and an approval matrix keyed to tier and spend. The bank-change rule belongs in it, as does the list of re-verification triggers. The policy also needs to set payment terms for micro and small suppliers and to specify how long onboarding records are retained.
The vendor onboarding questionnaire
A vendor onboarding questionnaire is most useful when it confines itself to what data cannot show. Identity and tax facts (legal name, PAN, GST registration, bank account holder, MSME status) should be verified from source, because a questionnaire answer is only a declaration. Ownership detail, internal policies and information security posture are a different matter; the questionnaire is the right instrument for those, and for subcontractors and business continuity arrangements too. For higher-risk suppliers, KYC Hub's supplier due diligence questionnaire guidance sets out a deeper question set.
Where vendor onboarding goes wrong
Documents collected but never checked. An uploaded GST certificate says nothing about whether the registration is still active.
Names that do not match, accepted anyway. Suppose the PAN is in one name, the GSTIN in a trade name and the bank account in a third. There may be an innocent explanation, such as a proprietor trading under a business name, but the pattern can equally indicate a payment routed to someone else. The mismatch is therefore resolved and recorded before activation.
GST status checked once. Registrations get cancelled and suspended after onboarding. When a vendor stops filing, the buyer's credit is affected on every invoice that follows.
MSME flag missing. A vendor without the flag defaults to the organisation's standard payment terms, which may exceed the 45-day limit on every invoice from day one.
Bank details changed on an email. A change actioned this way bypasses every check performed at onboarding.
Duplicate records on the same PAN. Spend fragments across two vendor codes, and duplicate payments become possible.
The vendor bears a cost as well. Being asked for the same document three times by three teams slows onboarding, and it pushes business users toward engaging vendors informally, outside the process altogether.
With the Income-tax Act, 2025 in force and GST credit tied to what the supplier actually files, much of a buyer's own tax position is now settled in the vendor master, often months before the first invoice is booked.
Onboarding is one stage of a longer relationship
PRISM runs the whole life of a vendor as one workflow: finding and selecting the vendor, checking it, deciding on it, bringing it on board, and reviewing it again at renewal. The seven stages mentioned in this guide are the onboarding part. Book a demo today.
