The quick answer
Check the custom request’s status and its Vendor Record link, then verify the saved native Vendor. In this configuration, Approved leaves the link blank and exposes a separate Create Vendor action. A similar-name warning blocks the first creation attempt. The controlled test retry opens a saved Vendor whose name and subsidiary assignments can be checked.
This walkthrough uses an installed vendor-onboarding solution with a custom New Vendor Request record. Its labels, buttons and approval sequence depend on that configuration. It starts after the supplier response is complete. Alex Morgan and Example Supply Co. are fictional example identities.
Before you start
You need an existing completed request and permission to review it, assign subsidiaries, approve it and use its configured creation action. This example uses an Administrator role and a multi-subsidiary configuration. Available fields, selectors, actions and permissions depend on the installed solution, account features, form and role.
The proposed vendor is Harbor Point ERP Services. The example assigns Example Supply Co. as the primary subsidiary and Example Supply Co. : West Operations as an additional subsidiary. The first creation attempt produces a warning that a Vendor with a similar entity name was found.
Use a controlled test request if reproducing this example. In a real duplicate investigation, inspect the existing Vendor and follow your organization’s resolution process. Changing a name to get past a warning is not a general duplicate-resolution procedure.
01. Inspect the request
Open the existing New Vendor Request. Confirm Status: Pending Internal Approval and a blank Vendor Record field. The blank field is one of the states to recheck after approval and after a blocked creation attempt.
02. Save subsidiaries
Click Choose Subsidiaries. Select Example Supply Co. as Primary Subsidiary and Example Supply Co. : West Operations under Other Subsidiaries. Save the request.
Confirm both saved values. They are still fields on the custom request; the native Vendor has not been created by this step.
03. Approve the request
Click Approve. Confirm Status: Approved and the separate Create Vendor action.
Check Vendor Record again. It remains blank. The approved request alone does not establish that a saved Vendor exists.
04. Read the warning
Click Create Vendor. The message says: Found a Vendor with the similar entity name of Harbor Point ERP Services. New Vendor not created!
Click OK, then recheck Approved and the blank Vendor Record field. The request approval remains, while this creation attempt is blocked. A similar name does not prove that two records represent the same legal entity, and this example does not establish the guard’s complete matching algorithm.
05. Follow the test retry
In the controlled test, the proposed name is changed before the successful retry. Click Edit, set New Vendor Name to Harbor Point ERP Services Demo, and save. This sequence does not establish that renaming resolves a real duplicate.
Confirm the saved proposed name, Approved status and blank native-record link. Click Create Vendor again. For an actual suspected duplicate, resolve the identity question through your organization’s process before attempting creation again.
06. Verify the Vendor
The resulting page is the native Vendor record. In this controlled result, confirm Vendor ID and Company Name both show Harbor Point ERP Services Demo. Vendor numbering and display behavior can differ by account configuration.
Confirm Primary Subsidiary: Example Supply Co. in Classification. The field and subtab locations shown here depend on the native Vendor form and your role.
Open Subsidiaries. Check the Example Supply Co. row with Primary: Yes and the additional Example Supply Co. : West Operations row.
The final check establishes the saved Vendor name and these subsidiary rows. The walkthrough stops here. It does not verify whether the custom request later receives a Vendor Record link, changes status, becomes read-only or permits another creation attempt. Every mapped field, bank authenticity and payment readiness are also outside this check.
Common questions
Why can an approved request still have a blank Vendor Record field?
In this installed configuration, approving the custom request and creating the native Vendor are separate actions. In this sequence, the request displays Approved while Vendor Record remains blank before Create Vendor runs.
Does this sequence apply to every NetSuite account?
No. New Vendor Request, Choose Subsidiaries, Approve and Create Vendor belong to the demonstrated custom onboarding solution. Check the record type, workflow, permissions and controls installed in your account.
Does a similar-name warning prove that the vendor is a duplicate?
No. The warning reports that a Vendor with a similar entity name was found and says that no new Vendor was created. It does not prove legal identity or establish all fields used by the guard. Investigate the existing Vendor before resolving the request.
Should I rename a real vendor request to bypass the warning?
Follow your organization’s duplicate-resolution process. The name edit here is a controlled demonstration that exercises successful creation; it is not a recommended response to a real suspected duplicate.
Where should I verify subsidiary assignments?
First check the saved request fields. After creation, check Primary Subsidiary and the Subsidiaries subtab on the native Vendor. This example shows Example Supply Co. as primary and West Operations as an additional row.
Does the final Vendor prove bank approval or payment readiness?
No. The demonstrated result confirms the saved Vendor’s name and subsidiary assignments. Bank approval, bank authenticity, payment readiness, registration and VAT validation require their own evidence and checks.
Does the walkthrough show a final Vendor Created status on the custom request?
No. It ends on the native Vendor. Do not infer the post-creation custom request status or its link update from that page alone.