Retail supplier onboarding: who can approve a vendor?

A buyer has agreed a homeware range and needs to issue the first purchase order. The supplier then emails different bank details. If the vendor master has only one “active” flag, the team faces a poor choice: block the whole relationship or let an unverified payment destination through.

Use separate permissions for commercial ordering, item readiness and payment. Procurement can approve the range without approving a bank account. Finance should be able to hold a payment change while preserving the proposed value, the previous approved value and the decision history.

Define what each approval actually permits

Start with the first transaction, not a long onboarding questionnaire. Record the legal supplier identity, approved contact channels, payment terms, currency, buying entity and required item information. Give each evidence item an owner and a reason for collecting it. Restrict access to bank evidence; a buyer usually needs to know its status rather than see the full document.

A supplier entry is not evidence that all four gates passed. Shopify's supplier documentation describes supplier details used with purchase orders. Treat a stored supplier record as operational data; establish your approval controls separately.

Work through a first order and a bank change

Suppose supplier H17 supplies 120 mugs at ₹250 each. The PO value is 120 × ₹250 = ₹30,000, before any separately configured taxes or charges. Procurement approves those terms. The item record confirms that the buying unit is one mug, not a case of six.

Finance verifies account version A through an established independent contact channel. A later email proposes account B. The proposed account is stored as a change request, with the request time and requester. It does not overwrite A.

The buyer can continue preparing the ₹30,000 order under commercial approval. Payment release for the affected supplier is held until finance decides which destination is valid. Keeping A as the previously approved record does not mean automatically paying A while a potentially legitimate change is unresolved.

If B is verified and approved, the payment batch must reference B's approved version. If the email is rejected, finance records that decision and explicitly clears the hold. A payment file prepared before the decision must be regenerated or revalidated: changing the master record does not repair an already exported bank file.

1. Procurement approvesH17: 120 mugs × ₹250 = ₹30,000; commercial terms recorded.
2. Catalogue validatesThe SKU, supplier item and unit conversion agree.
3. Finance reviewsBank B remains proposed; payment release is held.
4. Payment is releasedAn authorised reviewer selects the approved bank version and invoice.

Exception: A changed bank record or a stale payment export returns to finance; commercial approval cannot clear it.

Compare the two useful software options

An ERP workflow is often enough when suppliers are few, evidence arrives through managed channels and the current system can control both screens and imports. Demonstrate who can propose, approve and activate a change. The approver should see the old and proposed values without needing unrestricted editing rights.

A supplier portal becomes useful when suppliers repeatedly update documents and several internal teams chase the same information. It can improve collection and status visibility, but a portal submission still needs verification. A newly registered portal user must not be allowed to validate their own bank ownership merely by uploading a document.

Microsoft's vendor bank workflow supports protected-field approvals and separate behaviour for data-entity imports. That distinction matters: a controlled user interface can coexist with an import path that allows changes without approval. Test the configured import behaviour, not just the screen shown in a demonstration.

Keep exceptions explicit. An urgent launch may justify a time-limited commercial exception within a named person's authority. It does not make an unverified payment destination safe. Duplicate legal entities, multiple branches and different currencies also need deliberate master-data decisions rather than extra free-text supplier names.

Prove the gate before using real payments

Use redacted test records for a valid new supplier, a duplicate, a rejected bank change, an approved change and an imported update. Add a stale payment-export case. In each run, inspect both the visible status and the actual destination selected by the downstream payment process.

The acceptance condition is observable: an unapproved bank version cannot become a usable payment destination through any permitted entry path. The evidence must show who proposed and approved the change, what they checked, and which version the payment used. An approval notification alone is not sufficient.

For the receiving side, continue with the partial-receipt guide. Supplier readiness should survive the first delivery, including shortages and rejected units.

Make approval specific to the action

A vendor becomes ready for different activities at different times. Separate those decisions so a legitimate order can progress without quietly authorising a risky payment change.

1. Map the order, item, bank and invoice permissions in the current system.
2. Assign a verifier and approver for each protected change, including imports.
3. Run the bank-change and stale-export exercises before enabling the workflow.
4. Review held cases by age and owner; close them with evidence rather than a blanket active flag.