SAP Vendor vs Business Partner in S/4HANA:
What Changed, What Didn't, and How to Create Vendors

The Business Partner (BP) is a single master data object in SAP S/4HANA that represents any external party — vendors, customers, employees, banks — in one unified record. In ECC, vendors and customers had completely separate master records with duplicate general data. If the same company was both a vendor and a customer, you maintained two records with the same name and address entered twice. The BP solves this: one record holds the general data, and you assign roles to activate vendor, customer, or other functions. In S/4HANA, BP is mandatory for vendor and customer creation — XK01 and XD01 are replaced by transaction BP.

XK01 (Create Vendor: Accounting) and MK01 (Create Vendor: Purchasing) are replaced by transaction BP in SAP S/4HANA for creating new vendors. Attempting to use XK01 to create a vendor in S/4HANA redirects you to BP or shows an error. However, display-only transactions XK03 and MK03 still work for viewing existing vendor data. Change transactions XK02 and MK02 are also redirected to BP. The practical rule: use BP for all create and change operations; XK03/MK03 for display only.

FLVN00 is the Financial Accounting vendor role — activates company code data screens including the reconciliation account (mandatory AP balance sheet account), payment terms, payment method, bank details, and withholding tax. Without FLVN00, no accounting documents (invoices, payments) can be posted to the vendor. FLVN01 is the Materials Management purchasing role — activates purchasing organisation data screens including purchasing org, order currency, incoterms, and GR-based invoice verification. Without FLVN01, the vendor will not appear in ME21N purchase orders. Both roles must be assigned for a fully functional vendor in the procure-to-pay process.

Go to transaction BP. Click Create Organisation. Enter BP grouping (vendor number range), company name, and address. Save to get the BP number. Then switch to role FLVN00 — enter company code, reconciliation account (mandatory), payment terms, and payment method. Save. Switch to role FLVN01 — enter purchasing organisation, order currency, incoterms, and tick GR-based invoice verification. Save. Verify in ME21N (vendor appears in purchasing) and XK03 (FI data displays correctly). Both verifications confirm the vendor is fully functional.

The same tables as ECC — SAP maintained backward compatibility. LFA1 — vendor general data (name, address, country). LFB1 — vendor company code data (reconciliation account, payment terms). LFM1 — vendor purchasing organisation data (purchasing org, order currency, incoterms). Additionally in S/4HANA, BP general data is stored in BUT000 and address data in ADR* tables. Creating a vendor via BP automatically populates all these tables simultaneously, so existing reports and custom ABAP programs querying LFA1/LFB1/LFM1 continue to work without changes.

Yes — XK03 (Display Vendor: Accounting) and MK03 (Display Vendor: Purchasing) still work in SAP S/4HANA for viewing existing vendor records. XK04 (Vendor Account Changes) and XK05 (Block Vendor) also still function. What changed is the create and change path: XK01, XK02, MK01, and MK02 are replaced by BP. For day-to-day display and lookup, the familiar ECC transactions work identically in S/4HANA.

In ECC, a vendor is a standalone record in XK01/MK01, stored in LFA1/LFB1/LFM1, with no unified concept for a party that is both vendor and customer. In S/4HANA, a vendor is a BP record (transaction BP) with roles FLVN00 and FLVN01 assigned. The underlying LFA1/LFB1/LFM1 tables are still populated for compatibility. For purchasing users in ME21N, MIGO, and MIRO, the functional experience is identical — vendors still appear by number, POs and GRs work the same way. The change is in the creation and maintenance path, and in the ability to combine vendor and customer into one record.

A BP grouping determines how BP numbers are assigned (internal system-generated or external user-entered) and which number range is used. Every Business Partner must be assigned to a grouping at creation. For vendors, organisations create a dedicated grouping (e.g. 'VEND') with a number range matching their existing ECC vendor range. The BP grouping maps to the vendor account group — the same field selection rules (required, optional, hidden fields) apply. Misconfigured groupings cause new vendors to get unexpected number ranges or the wrong field selection. Configured in SPRO under Cross-Application Components > SAP Business Partner.

SAP's Migration Cockpit (LTMC) converts all existing vendor records (LFA1, LFB1, LFM1) into BP records automatically. Each vendor gets a BP record with FLVN00 and FLVN01 roles assigned, and the vendor numbers are preserved — your ECC vendor 100001 becomes S/4HANA BP 100001. The LFA1/LFB1/LFM1 tables are also populated in S/4HANA for backward compatibility. Existing POs, GRs, info records, and invoices require no changes. What migration does not handle automatically: duplicate records for parties that are both vendor and customer (may need manual merging), and custom ABAP that writes directly to LFA1 without using standard function modules.

Yes — this is one of the key benefits of the Business Partner model. If a company both supplies to you (vendor) and buys from you (customer), create one BP record and assign all four roles: FLVN00 (FI vendor), FLVN01 (MM vendor), FLCU00 (FI customer), and FLCU01 (SD customer). The general data — name, address, communication — is maintained once. This eliminates the data duplication that existed in ECC where you needed two completely separate master records for the same organisation, often leading to address inconsistencies between the vendor and customer records.

The reconciliation account is the G/L account that summarises all individual vendor postings into the balance sheet (Accounts Payable). For example, account 21000 — Trade Creditors. Every invoice posted to a vendor records the detail in the vendor sub-ledger; the reconciliation account records the total on the balance sheet. It is mandatory in the FLVN00 role — without it, no accounting documents (invoices, payments, credit memos) can be posted to the vendor. It is the most common missing field when a newly created vendor cannot be used in MIRO. Assign the reconciliation account in the Company Code data section of the BP FLVN00 role.

GR-based invoice verification (GR = Goods Receipt) is a control setting in the FLVN01 purchasing role that requires a goods receipt to exist before an invoice can be posted in MIRO, and matches each invoice line to a specific GR document. This strengthens the three-way match (PO → GR → Invoice) and prevents premature or duplicate payments. Recommended for all trade vendors. In the BP FLVN01 role, it is on the Purchasing Data screen — field "GR-Based Inv. Verif." Tick it to enable. Without it, invoices can be posted against the PO even when goods have not arrived.

The most common cause is that FLVN01 (MM purchasing role) was not assigned, or was assigned but the purchasing organisation data is incomplete. Check the BP record: open BP, find the vendor, check whether FLVN01 role exists and whether the purchasing organisation is entered in the role data. If FLVN01 is missing, add it and enter the purchasing org. If it is present but the vendor still does not appear, check whether the vendor has a purchasing block (in FLVN01 data, there is a purchasing block indicator that prevents the vendor appearing in new POs).

FLVN00 is the FI vendor role — activates Accounts Payable data (reconciliation account, outgoing payment terms, payment method). FLCU00 is the FI customer role — activates Accounts Receivable data (receivables reconciliation account, dunning settings). A BP can have both roles if it is both vendor and customer. FLVN00 feeds the AP subledger; FLCU00 feeds the AR subledger. Both are company code-level roles — a separate entry is needed per company code.

No — purchasing info records (ME11, stored in EINE/EINA tables) migrate automatically with the vendor master. Vendor numbers are preserved during migration, so all existing info records remain valid and continue to default prices on purchase orders exactly as before. Standard info record data requires no rework for S/4HANA migration. Custom ABAP that directly updates EINE or EINA may need review, but the data itself migrates cleanly and purchase order pricing continues to work from day one in S/4HANA.

SAP MDG (Master Data Governance) adds an approval workflow layer on top of BP maintenance. With MDG, creating or changing a vendor BP triggers an approval workflow — a data steward reviews and approves the change before it goes live. This enforces vendor onboarding controls: anti-bribery checks, bank detail verification, duplicate check. Without MDG, authorised users can create or change BP records immediately. MDG uses the BP model as its foundation — all vendor, customer, and supplier records are managed as Business Partners within MDG. For organisations with SOX or strict procurement governance requirements, MDG on top of BP is the recommended approach.

Vendor account groups (OBD3 in ECC) still exist in S/4HANA and serve the same purpose — controlling which fields are required, optional, or hidden when creating a vendor, and driving the number range. In S/4HANA, the account group is mapped to the BP grouping. Each BP grouping corresponds to a vendor account group. During ECC to S/4HANA migration, existing account groups are mapped to BP groupings. New vendor creation via BP uses the BP grouping, which behind the scenes references the account group to enforce the same field selection rules as before.

Yes — standard vendor reporting transactions and programs continue to work in S/4HANA because LFA1, LFB1, and LFM1 are still populated. Reports like S_ALR_87012085 (Vendor Balances in Local Currency), FK10N (Vendor Balance Display), and ME2M (Purchase Orders by Material) all function identically. Custom ABAP that reads LFA1/LFB1 also works without changes. What may need updating is custom ABAP that writes directly to LFA1/LFB1 without using standard SAP function modules — those writes may bypass the BP layer and create inconsistencies in the BUT000 table.

Central Business Partner (Central BP) means managing all BP master data — vendor, customer, employee — in one central hub (typically SAP MDG or a dedicated master data system) and distributing it to operating systems. Changes made to the central BP record automatically flow to the FI subledger (via FLVN00), MM purchasing (via FLVN01), and SD customer roles simultaneously. This is the design goal: one record, one maintenance point, all module views derived from it. "BP harmonisation" in an S/4HANA project refers to deduplicating and aligning all party records into this model.

For daily purchasing users — buyers in ME21N, goods receipt clerks in MIGO, invoice processors in MIRO — the Business Partner change is almost entirely invisible. Vendors still appear by number, purchase orders are created identically, goods receipts and invoice verification work the same way. The change is felt by the people who create and maintain vendor master data (procurement master data teams, AP teams), who now use BP instead of XK01/MK01. The number of screens and data fields is similar — the navigation path is different but the underlying data and procurement process are unchanged.

Yes — VoiSAP's SAP MM and FICO training covers S/4HANA fundamentals including the Business Partner model, vendor creation via BP, purchasing configuration, and the full procure-to-pay cycle — all on a live SAP S/4HANA system. You work on real transactions, not a simulation. Book a free demo to discuss your background and the right training path for your goals.