Tags
Business Partner, Master Data, MK01, MK02, MM, P2P, PortSAP, Ray Hornbrook, SAP, SAP MM, vendor, XK01, XK02
If you grew up in ECC, “vendor master” (XK01/XK02/XK03) was second nature for procurement. You created account groups, filled company code and purchasing organization views, and moved on. In S/4HANA, that world is replaced with Business Partner (BP) a single, central master that can wear multiple hats: supplier, customer, employee, and more.
From a P2P (Procure-to-Pay) perspective, this change isn’t just a new screen. It’s a different way of structuring and governing data that buyers, AP, and supply chain teams rely on every day. This post translates the shift from Vendor Master → Business Partner into practical implications for MM stakeholders.
TL;DR for MM P2P
- BP replaces Vendor Master with a role-based model (Supplier FI & Purchasing) and one central set of data.
- Customer-Vendor Integration (CVI) is the bridge get number ranges, mappings, and data quality right before you convert.
- The win for P2P: fewer duplicates, cleaner POs, better governance, and simpler compliance.
Treat migration as a data governance upgrade, not just a technical step.
The ECC Baseline: What We’re Moving From
In ECC, procurement used Vendor Master:
- Transactions: XK01/XK02/XK03
- Structure: Vendor account groups, with Company Code and Purchasing Organization data
- Reality: Vendors and customers were maintained separately even if they were the same legal entity
- Pain: Duplicate records, redundant maintenance, inconsistent addresses and tax IDs, and extra effort to keep data synchronized for compliance and reporting
That duplication wasn’t just annoying it showed up as wrong terms on POs, mismatched remit-to details in AP, and messy vendor lists for audits and supplier risk reviews.
Note: The old ECC transaction now point to Business Partner (BP) in S/4HANA. MK01/MK02/MK03/ XK01/XK02/XK03
The S/4HANA Shift: Business Partner as the Single Source
Business Partner (BP) becomes the single point of entry for master data. One BP record can be assigned roles such as:
- Supplier (FI) – often labeled FLVN00 (replaces company-code vendor data)
- Supplier (Purchasing) – often labeled FLVN01 (replaces purchasing-org vendor data)
- Customer (FI / Sales) – FLCU00 / FLCU01, if relevant
- Additional roles (Employee, Contact Person, etc.) as needed
Key differences vs. ECC:
- One master, many roles: The same entity can be both supplier and customer without duplicating records.
- Central data once, role data where needed: Address, identification numbers, bank details live centrally; purchasing and company-code specifics live in the appropriate supplier roles.
- Single transaction: You use BP (or the “Maintain Business Partner” Fiori app) instead of scattered classic transactions.
Bottom line: BP reduces redundancy, increases consistency, and creates a cleaner foundation for compliance and analytics.
Why Procurement Should Care (More Than a Little)
From a P2P lens, the BP model improves daily life:
- Cleaner sourcing and PO creation
- Buyers get consistent vendor names, addresses, tax numbers, and banking data because it’s one central truth.
- Fewer surprises on POs when terms, incoterms, and schema groups are maintained in the right Supplier roles.
- Fewer master data potholes
- No more maintaining “the same company” twice; change the legal name or address once and both supplier & customer roles inherit it.
- Blocking/approval can be controlled centrally and at the role level, giving MM and AP better governance.
- Better supplier lifecycle management
- A single BP record supports onboarding, performance, risk, and relationship management whether you’re using SAP tools, Ariba, or third-party SRM.
- Audit & compliance, simplified
- Centralized personal and company data makes it easier to meet privacy and traceability standards (e.g., GDPR), and to answer “Who are we paying and why?” during audits.
What Changes in the Day-to-Day MM Flow?
Requisitions → POs → GR → IV still run as you expect, but the master data anchor is different.
- Source of supply & vendor selection
PR and PO processes reference the Supplier tied to the BP. Your info records, source lists, and outlines still function but data quality is now driven by BP governance. - Terms, incoterms, partner functions
Payment terms, incoterms, and partner functions (e.g., Ordering Address, Goods Supplier, Invoicing Party) are maintained in the Supplier (Purchasing) role. If partner roles were messy in ECC, use the migration to standardize them. - Company-code vs. purchasing-org data
What used to be vendor “views” are now part of BP roles:- Supplier (FI) → reconciliation account, payment block, dunning data
- Supplier (Purchasing) → order currency, purchasing group defaults, schema group, partner functions
- Blocking logic
You can block at BP central level (no usage anywhere), Supplier (FI) (no postings), or Supplier (Purchasing) (no POs). This gives finer control than ECC and helps align SOD policies. - Reporting & analytics
Cleaner master data means more reliable spend analysis, duplicate detection, and vendor performance tracking.
The CVI Bridge: Making Legacy Data Play Nice
The practical enabler is Customer-Vendor Integration (CVI). CVI synchronizes your existing Vendor/Customer masters with BP during conversion.
What procurement teams need to know:
- Number range strategy: Decide whether the BP number matches the Supplier number. Many teams prefer same number to reduce confusion for buyers and AP.
- Groupings and account groups: Map ECC vendor account groups to BP groupings and roles.
- Field mapping & defaults: Align ECC fields to BP attributes so purchasing and FI data lands in the right place.
- Data quality first: De-duplicate and cleanse addresses, tax IDs, bank data, terms, and contact persons before you synchronize. CVI won’t fix dirty data; it will centralize it.
Migration Playbook for MM (P2P-Focused)
Use conversion as a chance to improve master data not just port it.
- Preparation (Pre-CVI)
- Vendor list hygiene: Merge duplicates, retire inactive records, normalize names (no ALL CAPS + trailing punctuation), and standardize abbreviations.
- Tax & bank validation: Validate tax IDs and bank accounts; correct country formats.
- Partner functions & terms: Normalize schema groups, default terms, incoterms, and partner functions to enterprise standards.
- Agree the numbering: Same number for BP & Supplier, or not? Decide once, document it, and socialize.
- CVI Customizing
- Map account groups → BP groupings, define roles for Supplier (FI/Purchasing), and complete field mapping/defaults.
- Set up blocking rules and governance (who can create, who approves, what’s mandatory).
- Dry Runs
- Synchronize a pilot set of high-volume suppliers.
- Validate PR/PO creation, partner functions on POs, GR/IV, and vendor evaluation reports.
- Check interfaces (AP automation, tax engines, Ariba/SRN, banks) against the BP/Supplier data model.
- Cutover
- Freeze changes, perform final CVI sync, and communicate how to create/maintain suppliers using BP (and related Fiori apps).
- Ensure buyers know where procurement views live inside the BP roles and how blocking/approval works post-go-live.
- Post-Go-Live Stabilization
- Run duplicate detection and exception reports weekly for the first month.
- Monitor invoice holds due to master data gaps (terms, partner functions, bank details).
- Lock down who can create/update which BP fields; central data needs central ownership.
Governance: Who Owns What in the BP World?
Clarity on ownership is half the battle:
- Master Data or Supplier Management
Owns central BP data (name, address, identification, bank), controls de-duplication, and operates approval workflows. - MM/Purchasing
Owns Supplier (Purchasing) role data: order currency, schema group, partner functions, incoterms, purchasing blocks, and purchasing-org assignments. - FI/AP
Owns Supplier (FI) role data: reconciliation account, payment terms (if AP-driven), dunning, posting blocks. - Risk/Compliance
Owns KYC, sanctions, ESG attributes, and attestations ideally captured as BP attributes or linked objects.
Document these RACI lines and embed them in your Fiori/MDG or workflow approvals to prevent “everyone and no one” owning supplier data.
Common Pitfalls (and How to Dodge Them)
- Treating BP as a skin-deep UI change
It’s a data model change. If you don’t rethink ownership, validation, and approvals, you’ll centralize chaos. - Skipping number range alignment
Buyers and AP live by vendor numbers. If BP ≠ Supplier number, train hard or align the ranges. - Forgetting partner functions
Inconsistent partner roles cause the classic “wrong invoicing party” or “goods supplier mismatch” errors at PO and IV time. - Partial blocking policies
If blocks aren’t aligned across central/Supplier (FI)/Supplier (Purchasing), documents sneak through. Define and test your block matrix. - Dirty bank/tax data
Bad central data now breaks every downstream process. Validate up front.
What Buyers Will Notice on Day 1
- New screen, familiar outcomes: They’ll use BP (or the Fiori app) to search and display suppliers.
- Cleaner drop-downs and fewer duplicates: The supplier pick in PR/PO creation is tidier.
- More consistent POs: Terms/incoterms and partner roles show up more reliably if you’ve done your mapping and cleanup.
- Clearer blocks: If a supplier is on hold, it’s obvious and it applies correctly where intended.
Quick Starter Checklist
- Decide BP ↔ Supplier number strategy and communicate it
- Map account groups → BP groupings; confirm Supplier roles in scope
- Clean names/addresses/tax/bank; standardize partner functions and terms
- Configure field mapping and defaults for CVI; define blocks and approvals
- Pilot convert top suppliers; test PR/PO, GR, IV, and interfaces
- Train buyers on where to maintain purchasing data in BP roles
- Monitor post-go-live duplicates, invoice holds, and blocks
Final thought: Moving to Business Partner in S/4HANA isn’t about losing the Vendor master. It’s about gaining a single, trusted supplier master that makes procurement faster, cleaner, and easier to control. If S/4 is on your roadmap, treating BP as a core P2P deliverable (with real data stewardship) is a smart move that pays back from day one.
If you have question on this or any other PortSAP Consulting blog please feel free to contact us at Blog@PortSAP.com. Or if you are looking for Top Quality SAP Consultants please feel free to contact us.
The author, Ray Hornbrook, has over 19 years of SAP functional and technical experience. Ray started his career in SAP as a MM/PP Subject Matter Expert (SME) for a SAP implementation in 1998 and is now a Senior Level SAP Consultant. Since Ray has worked both sides of SAP, business end user and IT professional, he is able to communicate effectively with both IT and Business team members. Having a background as an SAP business end user has helped Ray greatly in his consulting career. The business background helps him better communicate with the business members of the team. As well as helping bridge gaps in communication between the IT and Business team members.
To find out more about Ray Hornbrook please check out his LinkedIn profile by clicking HERE.
End of document – www.portsap.com
PortSAP Blogging 