Vendor onboarding is a structured process that helps businesses register suppliers, collect company information, verify documents, review financial details, and approve vendors before they become available for procurement activities.

For organizations using Keiro with SAP S/4HANA, vendor onboarding may involve both portal-based registration and SAP Business Partner master data management. A well-defined process helps maintain accurate supplier records, establish clear responsibilities, reduce duplicate entries, and support consistent purchasing and finance operations.

This article explains the vendor onboarding lifecycle, including vendor user creation, registration form completion, purchase and finance reviews, approval workflows, SAP vendor code generation, data validation, and integration requirements.

The exact fields, approval levels, and integration methods depend on the organization's configuration. The SAP mappings in this article are based on the supplied draft functional specification and must be validated against the target SAP environment before implementation.

1. Understanding the Vendor Onboarding Lifecycle

Vendor onboarding begins when a company invites a new supplier to register or identifies an existing supplier in SAP that needs portal access.

The process generally involves collecting vendor information, checking its accuracy, completing internal purchasing and finance details, and obtaining the required approvals.

Vendor Onboarding Process

Step	Process	Responsible Team	Expected Outcome
1	Create the vendor user account.	Portal Administrator / Purchaser	The vendor receives login instructions.
2	Complete the vendor registration form.	Vendor	Company information and supporting documents are submitted.
3	Review vendor information and complete purchasing details.	Purchase Team	The vendor record moves to Finance.
4	Complete financial and tax-related information.	Finance Team	The record is submitted for approval.
5	Review and approve the vendor record.	Authorized Approvers	Final approval is completed or corrections are requested.
6	Create the vendor master record in SAP.	Configured integration / SAP process	Vendor code is generated after successful creation.
7	Verify the final record.	SAP Master Data / Support Team	Vendor information is available in the relevant system.

An alternative process is available when a vendor already exists in SAP and needs to be made available in the portal.

2. Vendor User Creation and Access Setup

Before a new vendor can submit registration details, an authorized user must create the vendor's portal account and configure the appropriate access.

The account setup process includes user information, communication preferences, team assignment, and organizational access.

2.1 User Information

Field	Requirement	Description
First Name	Mandatory	First name of the vendor user.
Last Name	Mandatory	Last name of the vendor user.
Full Name	Mandatory	Complete name of the user.
Email	Mandatory	Email address used for login communication and notifications.
Phone	Mandatory	Contact number for account-related communication.

Accurate contact information is important because login instructions and other account notifications may be sent to the registered email address.

2.2 Communication Settings

The administrator selects the default communication method available in the portal configuration.

Configuration	Purpose
Default Communication Method	Determines how supported system notifications are delivered.
Registered Email Address	Receives login instructions and email notifications where configured.
Notification Template	Defines the content of account and registration messages.

The exact communication methods and notification templates depend on the implementation.

2.3 Team Assignment

Team assignment determines the user's access and responsibilities within the configured authorization model.

Example Team	Purpose
Vendor Team	Used for external vendor users.
Procurement Team	Used for internal purchasing users.
Unapproved Vendor	Used for vendors whose access is restricted until approval is complete.

Administrators should assign only the teams required for the user's responsibilities.

2.4 Organizational Business Access Control (OBAC)

OBAC connects a user to the appropriate organizational node.

Option	Description
Use Existing	Select an existing child node from the organizational access tree.
Create New	Create and save a new child node under the appropriate parent node.

The process described in the source follows this structure:

OBAC Tree → Parent Node → Child Node

Before saving the user, the administrator should verify that the selected team and organizational node match the user's intended access.

After the user account is saved, the system may send an email containing the following information, depending on the notification configuration.

Vendor or User ID
Initial login credentials or password-setup instructions
Vendor Portal login link
First-time login instructions
Relevant account information

Vendors should use the supplied login details or password-setup link to access the portal and complete their registration.

3. Completing the Vendor Registration Form

After logging in, the vendor completes the registration form and provides the information required by the organization.

The supplied specification organizes the form into 12 sections. Field visibility and mandatory requirements may be configured according to business needs and vendor type.

3.1 Company Details

This section collects the vendor's basic business information.

Field	Mandatory?	Description
Company Name	Yes.	Registered company name.
Owner Name	Yes.	Name of the business owner or relevant representative.
Organization Type	Yes.	Type of organization selected from the available options.
Company Type	Yes.	Company classification.
Company Website	No	Official website, if available.
Corporate Identification Number (CIN)	No	Company identification number, subject to validation.
CIN Date	No	Date associated with the CIN details.
Established Year	Yes.	The year the business was established.
First Time Supplier	No	Indicates whether the supplier is registering for the first time.
Is Existing Supplier	No	Indicates whether the vendor already has a supplier relationship.

The company information should be consistent with the vendor's official registration documents.

3.2 Registered Address

The registered address section records the vendor's business location and billing information.

Field	Mandatory?	Description
Address Line 1	Yes.	Main address.
Address Line 2 / Line 3	No	Additional address information.
City	Yes.	Registered city.
District	Yes.	Registered district.
State	Yes.	Registered state.
Country	Yes.	Country of registration: India is the default in the source specification.
Postal Code	Yes.	Postal or PIN code.
Telephone	No	Business contact number.
Billing Address	Yes.	Billing address information.
Is Primary Address	No	Identifies the primary registered address.
Add Another Registered Address	No	Allows additional address records where supported.

The source specification recommends allowing only one primary address for each vendor.

3.3 Contact Person Information

This section identifies the individuals responsible for communication with the vendor's business.

Field	Mandatory?	Description
Name	Yes.	Contact person's full name.
Email	Yes.	Contact person's email address.
Designation	Yes.	Job title or designation.
Mobile No.	Yes.	Mobile number; the source form defaults to +91.
Contact Person For	Yes.	Contact category, such as commercial, technical, or accounts.
Is Authorized Decision Maker	No	Indicates whether the contact is an authorized decision-maker.

Providing accurate contact details helps purchasing and finance teams communicate with the correct person during registration and subsequent business activities.

3.4 Manufacturer Information

This section collects operational and technical details from manufacturing vendors. Its visibility should be confirmed during form configuration.

Field	Mandatory?	Description
Details of Product Manufactured	No	Description of manufactured products.
Facilities Offered	No	Manufacturing facilities and capabilities.
Lead Time	No	Production or supply lead time.
Established Capacity / Current Capacity Utilized / Spare Capacity	No	Production capacity information.
Type of Premise	No	Type of manufacturing premises.
Working Hours / Weekly Holidays	No	Operating schedule.
Number of Manpower	No	Workforce information.
Organization Structure	No	Supporting file upload.
List of Machinery	No	Machinery details or attachment.
Process Flowcharts	No	Process documentation upload.
Design Parameters	No	Relevant technical parameters.
Quality Control Measures	No	Quality control information.
Calibration List	No	Calibration-related attachment.

These details help the organization understand the vendor's manufacturing capabilities and supporting documentation.

3.5 Trader Information

Trader vendors may be asked to provide information about their materials, stock availability, and authorization.

Field	Mandatory?	Description
Material Description	No	Materials or products supplied.
Minimum Stock Kept	No	Minimum stock maintained by the trader.
Lead Time to Deliver	No	Expected delivery lead time.
Manufacturer Name	No	Name of the manufacturer.
Letter of Authorized Distributor	No	Supporting authorization document.

The implementation should confirm whether the manufacturer and trader sections appear conditionally based on a vendor-type selection.

3.6 Top Customer Information

This section records details of the vendor's major customers and the products or materials supplied to them.

Field	Mandatory?	Description
Customer Name	No	Name of the customer organization.
Location	No	Customer's location.
Material Supplied	No	Material or product supplied.
Annual Share	No	Annual share information.
Add Another Top Customer	No	Adds another customer record.

Multiple customer records may be required to represent the vendor's business relationships.

3.7 Certifications

Vendors can provide certification documents and validity dates where these details are relevant to the registration process.

Certification	Attachment	Validity Date	Mandatory?
ISO 9001:2015	Upload	Valid Upto date	No
OHSMS 45001:2018	Upload	Valid Upto date	No
ISO 14001:2015	Upload	Valid Upto date	No
ISO 50001:2018	Upload	Valid Upto date	No
Bio-based / Recyclable / Recycled Content Certification	Upload	Valid Upto date	No

The form also includes a vendor declaration confirming that the submitted information and documents are accurate and that the vendor is responsible for notifying the organization of relevant changes.

3.8 Bank Details

Bank information supports the organization's vendor master-data and payment-related processes.

Field	Mandatory?	Description
Is Bank Account Present	No	Indicates whether bank details are available.
Account Holder Name	No	Name of the account holder.
Bank Name	No	Name of the bank.
Account Number	No	Vendor's bank account number.
Branch Name	No	Name of the bank branch.
Type of Account	No	Bank account type.
City	Yes	Bank city.
IFSC Code	No	Bank branch identification code.
Branch Address	Yes	Address of the bank branch.
PIN Code	No	Branch postal code.
Is Primary Bank	No	Identifies the primary bank account.
Bank Mandate Form	No	Bank mandate attachment.
Cancelled Cheque	No	Cancelled cheque attachment.
Verify Bank	Action	Starts the configured bank verification process.
Add Another Bank Details	No	Adds another bank account record.

The supplied specification requires successful bank verification before submission and recommends allowing only one primary bank account per vendor. Confirm these rules against the final configuration.

3.9 GST and Tax Details

This section collects tax-registration information used for vendor identification and validation.

Field	Mandatory?	Description
Is GST Registered	No	Indicates whether the vendor is GST registered.
GST Registration Number (GSTIN)	No	GST registration identifier.
GST Registration Type	No	Type of GST registration.
GST Certificate	No	GST certificate attachment.
GST Status	No	Registration status, potentially populated by verification.
GST Registration Date	No	GST registration date.
PAN Card	No	PAN document attachment.
Permanent Account Number (PAN)	No	Vendor's PAN.
Vendor Classification	No	Vendor classification used by the organization.
Aadhaar Number	No	Identity-related field requiring appropriate protection.

The source specification states that vendors should update changes to the submitted information and provide supporting evidence.

3.10 MSME and Turnover Details

This section records MSME registration and historical turnover information.

Field	Mandatory?	Description
MSME Registered	No	Indicates whether the vendor is MSME registered.
Udyam Registration Number	No	Udyam registration identifier.
Enterprise Type / Minority Indicator	No	Enterprise classification information.
Certification Date	No	Relevant certification date.
MSME / Udyam Aadhaar	No	Supporting attachment.
Financial Year 1–3 and Annual Turnover 1–3	No	Turnover details for the previous three financial years.

The validation process should follow the organization's requirements for the collection and verification of these details.

3.11 Other Business Information

The vendor may be asked to disclose additional information relevant to its business relationship with the organization.

Question	Additional information requested when applicable
Is the company owned or controlled by a parent company?	Parent company name.
Has the company operated under a different name?	Years operating under the current name.
Are any directors, partners, or employees related to an employee of Gallantt Ispat Limited?	Name and employee ID.
Is any former employee of Gallantt Ispat Limited currently employed by the vendor?	Name, employee ID, and last posting.
Have any contracts been terminated for poor performance or had damages claimed in the last three years?	Relevant details.
Is any sister concern associated with Gallantt Ispat Limited, currently or previously?	Name of the firm.
Is the vendor already registered with Gallantt Ispat Limited?	Purchase order number or vendor code.

The source also includes a previous-experience table.

Field	Description
Vendor Code	Vendor reference code.
Customer Name	Customer organization.
Company Telephone No.	Customer or company telephone number.
Service Provided	Service or material supplied.
Value of Contract	Contract value.
Year 1	First year of experience information.
Year 2	Second year of experience information.
Year 3	Third year of experience information.

3.12 Supporting Documents

The final registration section collects additional company documents.

Field	Mandatory?	Description
Corporate Identification Number (CIN) Certificate	No	CIN certificate upload.
Other	No	Additional supporting documents.

The registration concludes with a declaration confirming that the submitted details are correct and that the vendor will notify the organization of future changes.

After submission, the record moves to the Purchasing team for review.

4. Purchase Team Review and Buyer Information

The Purchase team reviews the submitted vendor details and completes the information required for purchasing and Business Partner master-data maintenance.

The supplied specification allows multiple Buyer Info blocks, with each block associated with a company code and purchasing organization.

Field	Mandatory?	Proposed SAP Mapping
Company Code	Yes	LFB1-BUKRS
Purchase Organisation	Yes	LFM1-EKORG
Order Currency	Yes	LFM1-WAERS
Purchaser Name and ID	Yes	Portal/workflow attribute; LFM1-EKGRP may apply if used.
Commodity In-charge Details	Yes	Portal/workflow attribute.
Type of Purchase Details	Yes	Portal attribute; mapping requires confirmation.
Payment Terms	Yes	LFB1-ZTERM / LFM1-ZTERM
Inco Terms	Yes	LFM1-INCO1
Inco Term Location	Yes	LFM1-INCO2; INCO2_L may apply in S/4HANA.
Search Term 1	Yes	BUT000-BU_SORT1
Search Term 2	No	BUT000-BU_SORT2
Title	Yes	BUT000-TITLE
Organisation BP Name	Yes	BUT000-NAME_ORG1
Add Another Buyer Info	No	Additional company-code / purchasing-organization data.

After the Purchase team completes the required fields, the record is submitted to Finance.

These mappings are proposed in the source document and must be validated against the actual SAP configuration.

5. Finance Review and Approval Information

The Finance team completes the accounting and withholding-tax information required for vendor master-data processing.

Field	Mandatory?	Proposed SAP Mapping / Notes
Reconciliation Account	Yes	LFB1-AKONT
Vendor Schema Group	Yes	LFM1-KALSK
Vendor Group	Yes	Account group or Business Partner grouping mapping requires confirmation.
Limits	Yes	Business meaning and mapping require confirmation.
Withholding Tax Code	Yes	LFBW-WT_WITHCD
Withholding Tax Type	Yes	LFBW-WITHT
TDS/TCS Applicability	Yes	LFBW-WT_SUBJCT is proposed in the source.
TDS Section / Percentage	Conditional	Required when applicable; depends on the withholding-tax configuration.
Is the Vendor a Related Party?	Yes	Custom field or flag for reporting.
Subject	To be confirmed	Possible overlap with the TDS/TCS applicability field.
Recipient Type	To be confirmed	LFBW-QSREC

Finance Review Considerations

Confirm the meaning of the Vendor Group and Limits fields.
Determine whether Subject and TDS/TCS Applicability are separate fields.
Validate withholding-tax configuration and conditional field requirements.
Confirm that the information is complete before the record enters the approval workflow.

After completing the required information, Finance submits the record for approval.

6. Vendor Approval Workflow

The approval workflow provides an internal control before the vendor record is created in SAP.

The number of approval levels depends on the organization's configured workflow.

Workflow Stage	Activity	Expected Result
Finance submission	Finance sends the completed record for approval.	Approval workflow starts.
Approver review	Authorized approvers review the vendor information.	Record is approved or rejected.
Rejection	Approver returns the record with remarks.	Record goes back to the relevant Purchase or Finance team for correction.
Final approval	All required approval levels are completed.	Vendor record becomes eligible for the next creation step.
SAP creation	The configured integration creates the vendor record.	SAP vendor code becomes available after successful creation.

The organization should define rejection handling, correction responsibilities, and resubmission rules before implementation.

A record should not be treated as successfully created in SAP merely because the approval workflow is complete. SAP creation must also succeed.

7. SAP Vendor Code Generation

Vendor code generation identifies the vendor in SAP and connects the approved supplier information with relevant purchasing and finance processes.

The source specification describes vendor creation after final approval, followed by verification of the vendor record through SAP Business Partner transaction BP. XK03 or MK03 may be used where supported by the SAP release.

Number Assignment Options

Option	Description
Internal Number Assignment	SAP assigns the number using its configured number range.
External Number Assignment	An external system supplies the number, if supported and agreed in the implementation.
Business Partner Grouping	Determines the relevant Business Partner grouping and numbering configuration.
Vendor Account Group	Must align with the applicable Business Partner and supplier configuration.
Error Handling	Failed creation attempts should be logged, monitored, and handled through a defined recovery process.

The source specification does not finalize whether internal or external number assignment will be used. This decision must be confirmed before implementation.

8. Integrating Existing SAP Vendors with the Portal

Organizations may already maintain vendor records in SAP before introducing portal-based registration. In such cases, the SAP-initiated route can make an existing vendor available in the portal.

SAP-to-Portal Process

Step	Activity	Responsible Team
1	Create or maintain the vendor as a Business Partner in transaction BP.	SAP Master Data Team
2	Maintain the relevant supplier roles, such as FLVN00 for FI and FLVN01 for purchasing, as applicable.	SAP Master Data Team
3	Open the configured Vendor Portal Supplier Detail application.	SAP Master Data Team
4	Enter the vendor code and select the correct record.	SAP Master Data Team
5	Select Push to Portal.	SAP Master Data Team
6	Confirm that the vendor is available in the portal.	SAP Master Data / Portal Team

According to the source specification, a vendor pushed from SAP is treated as already approved in the portal and does not pass through the portal approval workflow.

Recommended Controls

Restrict SAP Business Partner creation and modification permissions to authorized master-data users.
Define how required tax and bank validations are applied to SAP-originated vendors.
Confirm how the portal handles missing or invalid vendor information.
Ensure the SAP and portal records can be matched reliably.
Maintain monitoring and logging for unsuccessful data transfers.

These controls help maintain consistent data quality across both onboarding routes.

9. Vendor Data Validation and Uniqueness

Vendor validation helps identify incomplete information, duplicate records, and inaccurate tax or banking details before the record progresses.

9.1 Uniqueness Rules

Identifier	Validation Requirement	Important Consideration
GSTIN	Unique per vendor, according to the configured rule.	Check against relevant SAP Business Partner tax numbers where applicable.
PAN	Unique per vendor, subject to an agreed exception policy.	One legal entity may have multiple GSTINs across states.
CIN	Unique per vendor.	Check for duplicate company identifiers.
MSME / Udyam Number	Unique per vendor.	Apply the agreed verification rules.
Aadhaar Number	Unique per vendor, where collected.	Apply strict access and data-protection safeguards.

The source references DFKKBPTAXNUM for SAP Business Partner tax-number checks. Confirm the applicable table, tax-number category, and validation approach for the target SAP environment.

9.2 Verification Methods

Data	Proposed Verification Method	Purpose
GSTIN	GST portal or an available GSP API.	Validate legal name, registration status, and registration date.
PAN	Available income-tax / PAN verification service.	Compare the legal name and check PAN–GSTIN consistency.
Bank Account	Bank verification service or penny-drop API, together with IFSC validation.	Verify account details and account-holder name.
CIN	Ministry of Corporate Affairs lookup.	Check company name and registration status.
MSME / Udyam	Available Udyam registration verification service.	Validate registration details and enterprise classification.

These verification methods are proposed options from the source specification. Actual integration availability depends on the selected service, API access, credentials, and implementation design.

9.3 Validation Outcomes

Condition	Expected Handling
Mandatory information is missing.	Display a validation message and prevent submission.
Duplicate identifier is detected.	Display a duplicate warning or error and apply the configured blocking rule.
GST verification fails.	Display the result and prevent progression where required by policy.
Bank verification fails.	Do not mark the bank as verified; apply the agreed submission rule.
PAN, CIN, or Udyam verification fails.	Request correction or route the record for review, according to policy.
Required supporting document is missing.	Request the missing document when required by the configured form.

The organization should document which validation failures block submission and which require manual review.

10. Vendor Data Mapping Between the Portal and SAP

The following table summarizes the proposed data mapping in the source specification.

Portal Data	Proposed SAP Object / Field	Notes
Company Name	BUT000-NAME_ORG1 / NAME_ORG2	Organization Business Partner name.
Registered Address	BP address / ADRC	Includes city, state, country, and postal code.
Contact Person and Communication Details	BP contact-person relationship and communication data	Multiple contacts may be supported.
GSTIN	BP tax number category IN3	Confirm the configured tax-number category.
PAN	BP tax number category IN4 / India vendor data, including J_1IMOVEND-J_1IPANNO where applicable	Depends on SAP release and localization.
MSME / Udyam Details	Relevant India vendor MSME fields, including J_1IMOVEND where applicable	Confirm the actual target fields.
Bank Details	BP bank details / BNKA / LFBK, as applicable	Verify bank key and primary-bank handling.
Company-Code Data	LFB1	Includes reconciliation account and payment terms.
Purchasing-Organization Data	LFM1	Includes currency, Incoterms, and purchasing information.
Withholding Tax	LFBW	Includes tax code, type, subject, and recipient type.
Certifications and Supporting Documents	Portal repository or DMS link	Source proposes storing documents separately and linking them where required.

All mappings must be reviewed by the SAP functional and technical teams. Actual fields and object relationships may differ according to the release and configuration.

11. SAP Configuration Requirements

The SAP configuration approach depends on whether the organization uses On-Premise, Private Cloud, or Public Cloud.

Configuration Area	On-Premise / Private Cloud Reference	Public Cloud Reference
Business Partner Number Ranges	SPRO → Cross-Application Components → SAP Business Partner → Basic Settings → Number Ranges and Groupings.	Relevant SSCUI activities for number ranges and groupings.
Business Partner Supplier Roles	SAP Business Partner role configuration.	Roles and configuration available in the target tenant.
Customer-Vendor Integration	Business Partner and Customer/Vendor Integration settings in SPRO.	Supported configuration options for grouping and account-group assignment.
Vendor Account Groups and Field Control	OBD3, OBD2, and relevant Business Partner field-control settings, where applicable.	Available tenant configuration options.
Payment Terms	OBB8.	SSCUI for defining terms of payment.
Incoterms	Relevant International Trade / Incoterms configuration in SPRO.	Relevant SSCUI for Incoterms.
Vendor Schema Groups	Materials Management → Purchasing → Conditions → Define Schema Group → Schema Groups, Vendor.	Relevant purchasing configuration activity.
Reconciliation Accounts	FS00 and vendor reconciliation-account assignment, as applicable.	Manage G/L Account Master Data and supported configuration.
Withholding Tax	Extended Withholding Tax configuration under Financial Accounting.	Relevant withholding-tax configuration and SSCUI activities.
Portal Fiori Application	Custom Fiori app, catalog, and role configuration.	Supported custom tile and launchpad content configuration.
Vendor Code Generation	Confirm the supported number-assignment approach.	Confirm the corresponding options in the target tenant.

Configuration paths and activities must be verified for the actual SAP release. In particular, Public Cloud configuration identifiers can vary between releases and tenants.

12. System Integration Requirements

The onboarding process connects vendor registration, procurement, finance, workflow, and SAP master-data management.

System / Module	Integration Purpose
FI – Accounts Payable	Reconciliation account, payment terms, withholding tax, bank information, and related-party data.
MM – Purchasing	Purchasing-organization data, schema group, Incoterms, currency, and vendor information for purchasing documents.
Portal PO / ASN Processes	Use of approved vendor records in portal purchasing or advance shipping notice processes, where enabled.
SD / PP / WM	Potential relevance in specific scenarios involving vendors also maintained as customers or Business Partners.
Workflow	Approval routing, approval decisions, and rejection handling.
Integration Layer	Data transfer through the selected API, SAP Integration Suite / CPI, OData, RFC, or another approved integration method.

Integration Best Practices

Define the source of truth for each vendor field.
Establish a reliable relationship between the portal vendor record and the SAP Business Partner.
Maintain integration logs for successful and unsuccessful requests.
Define safe retry behavior for failed SAP creation or update operations.
Synchronize approval and SAP creation statuses where required.
Establish a correction and resubmission process for rejected vendor records.
Test both portal-initiated and SAP-initiated processes before production deployment.

The actual integration technology and error-handling design must be confirmed during the implementation workshop.

13. Testing and Validation Scenarios

Testing should verify that vendor registration, validation, approvals, and SAP integration work according to the agreed design.

No.	Test Scenario	Expected Result
1	Create a vendor user with mandatory information, team, and an existing OBAC node.	User is created and login notification is received.
2	Create a vendor user with a new OBAC child node.	New node is saved and assigned.
3	Register a manufacturer vendor.	Manufacturer section is available when configured and submission succeeds.
4	Register a trader vendor.	Trader section is available when configured and submission succeeds.
5	Submit a form with a mandatory field missing.	Validation error appears and submission is blocked.
6	Enter duplicate GSTIN, PAN, CIN, Udyam, or Aadhaar information.	Duplicate validation is triggered.
7	Enter invalid or cancelled GSTIN or incorrect bank / IFSC details.	Verification fails and the agreed blocking rule is enforced.
8	Complete Buyer Info and submit.	Record moves to Finance.
9	Select TDS/TCS applicability as Yes but omit the required section information.	Conditional validation error appears.
10	Complete all approval levels.	Final approval is completed and the vendor is created in SAP after successful integration.
11	Reject the record at an approval level.	Record returns with remarks and no vendor code is generated.
12	Compare portal and SAP company-code, purchasing-organization, tax, bank, and withholding-tax data.	Values match the agreed mapping.
13	Push an existing SAP vendor to the portal.	Vendor appears in the portal with the agreed status.
14	Push a vendor with missing GSTIN or PAN.	The agreed block-or-warn behavior is applied.

Test results should be recorded and reviewed before production release. The expected results above are based on the supplied specification and are not confirmation that these tests have already passed.

14. Important Implementation Decisions

The supplied functional specification identifies the following points for confirmation before the solution is finalized.

Decision Area	Required Clarification
Integration Technology	Confirm the selected portal integration method and middleware.
Vendor Group	Define its business meaning and SAP mapping.
Limits	Clarify whether this represents a credit limit, purchase-order limit, tolerance, or another control.
Type of Purchase Details	Confirm its purpose and SAP mapping, if any.
Subject and TDS/TCS Applicability	Determine whether these are separate fields or overlapping indicators.
Vendor Code Assignment	Decide the supported internal or external number-assignment approach.
Manufacturer / Trader Sections	Confirm conditional visibility based on vendor type.
Rejected Records	Define correction, remarks, and resubmission handling.
PAN Uniqueness	Agree on exceptions for legal entities with multiple GSTINs.
Sensitive Data	Define access restrictions, retention, and protection for Aadhaar and uploaded documents.
SAP Deployment Model	Confirm On-Premise, Private Cloud, or Public Cloud.

These decisions should be documented before development and user acceptance testing.

15. Best Practices for Accurate Vendor Master Data

A reliable onboarding process requires both process controls and data-quality checks.

Collect accurate company, address, tax, bank, and contact information.
Clearly identify mandatory and conditional fields.
Make the required supporting documents easy for vendors to understand.
Separate vendor-submitted details from internal purchasing and finance information.
Apply appropriate access restrictions to banking and identity-related information.
Use consistent duplicate-checking rules across portal-originated and SAP-originated records.
Keep approval decisions and rejection remarks traceable.
Monitor SAP integration errors and confirm successful vendor creation.
Validate all technical mappings against the target SAP system.
Review the process periodically as business and system requirements change.

Conclusion

A well-defined vendor onboarding process helps organizations collect accurate supplier information, coordinate purchasing and finance reviews, enforce appropriate validations, and manage vendor master-data creation in SAP.

By documenting each stage—from vendor account creation and registration to internal approval, SAP integration, and final verification—organizations can establish a more consistent and traceable supplier onboarding process.

The exact workflow, field requirements, and integration behavior should always be aligned with the organization's Keiro configuration and SAP environment.

Frequently Asked Questions

1. What is vendor onboarding?

Vendor onboarding is the process of registering a supplier, collecting information, verifying documents, and obtaining internal approval.

2. Who reviews the vendor registration?

The Purchase team reviews the submitted information, followed by the Finance team and configured workflow approvers.

3. When is the SAP vendor code generated?

In the portal-initiated process described in the source, vendor creation follows final approval and successful SAP integration.

4. Can an existing SAP vendor be added to the portal?

Yes. The described process uses a configured SAP application to push an existing vendor into the portal.

5. Why are vendor validation checks important?

They help identify duplicate records, incomplete information, and incorrect tax or bank details before the vendor record progresses.