SAP Vendors

In S/4HANA, vendors are Business Partners with a supplier (vendor) role, carrying general data (name, address), purchasing data (purchasing organization terms), and accounting data (reconciliation account, payment terms) maintained by the respective functions. This master data drives every purchase order and payment.

• Business Partner roles (FI vendor, purchasing).
• Purchasing data: terms, currencies, partner functions.
• Accounting data: reconciliation account, payment terms.
• Vendor evaluation of performance.

Two settings on the purchasing data are worth knowing because they change downstream behaviour. Goods receipt based invoice verification, set per vendor, forces invoices to match a specific receipt rather than the order overall, which matters for partial deliveries. Automatic purchase order allows requisitions from this vendor to be converted without manual intervention, which is efficient and depends on the source data being trustworthy.

Vendor data splits the same way material data does, and the same rule applies: a level that is missing blocks a process rather than producing a clear message.

General data is true everywhere: name, address, tax numbers, communication. It sits on the Business Partner in its general role.

Company code data is what finance needs to pay: the reconciliation account, payment terms, payment methods, whether payments are blocked. This is the FI vendor role, and a vendor without it can be ordered from and not paid.

Purchasing organisation data is what buying needs: the order currency, the incoterms, the purchasing terms, the partner functions. A vendor without it cannot be put on a purchase order for that purchasing organisation, which is the most common "the vendor does not exist" report when the vendor plainly does.

Partner functions sit inside purchasing data and are worth knowing separately. The ordering address, the invoicing party and the goods supplier can all be different companies, which is how a group with one head office and several depots is modelled correctly.

One more level exists in some designs: purchasing organisation and plant, where terms differ per site. It is available and rarely needed, and switching it on multiplies the maintenance for every vendor. Use it when a supplier genuinely quotes different terms per plant, not because the option exists.

Half an hour, and it demonstrates why vendor creation involves more than one team.

1. Create a Business Partner with BP in the general role. Name, address, and nothing else.
2. Try to raise a purchase order. It refuses, because there is no purchasing organisation data.
3. Add the purchasing role and complete the purchasing organisation data. The order can now be raised.
4. Receive against it. That works, because receiving is about goods rather than money.
5. Now try invoice verification. It fails or posts without being payable, because the FI vendor role and its reconciliation account are missing.
6. Add the FI role, complete the company code data, and the invoice posts to a payable correctly.

Three roles, three teams, one partner. That sequence is exactly why vendor onboarding is a controlled process in any organisation of size.

Poor vendor data blocks or misdirects procurement, wrong payment terms cost money, a missing accounting view stops payment, duplicates cause confusion. Governing vendor/BP data (increasingly with MDG) keeps procurement smooth and payments correct. The BP model in S/4HANA is a key change from ECC’s separate vendor master.

There is also a fraud dimension worth naming. Creating a vendor and paying a vendor is the classic segregation of duties conflict, because together they allow somebody to invent a supplier and send money to it. Bank details in particular are the field attackers target, and a change to them should carry its own verification rather than being an ordinary master data edit. See the purchase order for what the data feeds.

• Who may create one. Central onboarding gives consistency and control and is slower. Local creation is fast and produces duplicates and weak verification.
• How bank details are verified. Independently of the request, by contacting the vendor through a number nobody supplied in the request itself.
• One-time vendors. A single account for occasional suppliers avoids a master record per one-off purchase and carries the address on the document instead.
• Whether vendors are also customers. Business Partner makes that one record, and netting payables against receivables is then possible where it is legally allowed.

Vendor data answers who. The purchasing info record answers how much, and the two are frequently confused.

An info record is the intersection of one material and one vendor, for one purchasing organisation and optionally one plant. It holds the agreed price, the planned delivery time, the minimum order quantity, the vendor's own material number and the last purchase order reference.

When a purchase order is created, the price comes from a contract if one exists, otherwise from the info record, otherwise from the last order, otherwise from whoever is typing. That order of preference is the difference between controlled spend and negotiated-per-order spend.

The delivery time matters as much as the price. MRP schedules backwards using it, so a planned delivery time that was optimistic on day one produces requisitions raised too late, permanently, and nobody looks at the info record when the symptom is late deliveries.

Info records can be created automatically from a purchase order, which is convenient and records whatever price was typed rather than a negotiated one. Creating them deliberately is the better habit.

Suppliers stop being used and the system offers several ways to reflect that, which behave differently.

A posting block stops financial postings. A purchasing block stops new orders, and it can be set for one purchasing organisation or all of them. Both are reversible and both leave everything intact.

A deletion flag marks the record for eventual archiving. It does not delete anything, and existing documents keep working, which is the point: a vendor with three years of invoices cannot simply disappear.

Archiving is the actual removal, and it only runs when nothing depends on the record, which for a vendor means every document referencing it has been archived first.

The practical guidance is to block rather than flag when a supplier might return, flag when they definitely will not, and never attempt to reuse an old vendor number for a different company. The history follows the number, and merging two suppliers' histories is a mess nobody can untangle later.

• Incomplete BP roles/views blocking process steps.
• Duplicate vendors without governance.
• Wrong payment terms costing money.

• Duplicate vendors under slightly different names. Spend analysis becomes fiction and volume discounts are missed.
• Blocked vendors unblocked without recording why. The block existed for a reason.
• Purchasing data maintained for one purchasing organisation only. See purchase requisitions and MM pricing for what reads it.

• Bank details changed on an emailed request. That is the single most exploited weakness in supplier data, and the control is verification through a channel the requester did not supply.
• Reusing a vendor number for a different company. The history follows the number.

Creating a vendor is straightforward, and designing the onboarding, verification and roles so procurement and finance both work is the part you do in the course.

The check to run first on any vendor problem is which roles and which organisational levels are maintained. General data existing is not the same as being usable for purchasing in this organisation or payable in this company code.