SAP · Procurement · Master data

    SAP Vendor Master Data Migration

    Migrate vendor master data into SAP, covering general, company code and purchasing organisation views, bank details, partner functions and the path to the Business Partner model in S/4HANA.

    Discuss Your MigrationAll Migration Objects

    Object overview

    The SAP vendor master is maintained at three levels: general data that is client-wide, company code data that governs accounting, and purchasing organisation data that governs procurement. A vendor usable for buying and paying needs all three, and each is a separate load that can fail on its own.

    If the target is S/4HANA, the vendor does not stay a vendor. It becomes a Business Partner with the vendor role, which means this object is really a staging point on the way to Business Partner conversion rather than a destination.

    What data is typically migrated

    Scope is agreed in discovery; this is the shape of the object.

    Data areaTypical information
    General dataName, address, search terms, tax numbers, account group
    Company code dataReconciliation account, payment terms, payment methods, dunning
    Purchasing org dataOrder currency, purchasing group, terms, incoterms
    Bank detailsBank key, account, control key
    Partner functionsOrdering address, invoicing party, goods supplier
    Withholding taxWhere applicable by country

    Object relationships

    Dependency drives load sequence: a child cannot exist before its parent.

    Vendor general data (client)
    └─ Company code data → reconciliation account
    └─ Purchasing organisation data
    └─ Bank details
    └─ Partner functions
    └─ Withholding tax data

    Object migration flow

    Source Vendor→DataMove→Map & transform→Validate→SAP Vendor→DataVault reconciliation→Sign-off

    Before you migrate this object

    Confirm each of these before the first migration cycle.

    □Account groups and number ranges are configured
    □Reconciliation accounts exist and are flagged for vendors
    □Company codes and purchasing organisations are configured
    □Payment terms and methods crosswalk is approved
    □Bank master data is loaded
    □Bank detail re-verification policy is agreed
    □One-time vendor handling is decided

    Common source systems

    Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

    SAP ECC Production-provenOracle EBS SupportedOracle JD Edwards SupportedMicrosoft Dynamics 365 Supported

    Source-to-target mapping examples

    Object-level equivalence. Field-level mapping is produced per engagement.

    Source systemSource entityTarget object
    SAP ECCLFA1 / LFB1 / LFM1S/4HANA Business Partner (vendor role)
    Oracle EBSAP Supplier + SitesSAP vendor general + company code + purchasing
    JD EdwardsAddress Book + Supplier MasterSAP vendor general data

    Migration methods for this object

    SAP Migration Cockpit vendor / business partner migration object

    CVI where converting an existing ECC vendor population in place

    Account group configuration decided before load — it drives number range and field selection

    Extraction considerations

    Three levels, not oneExtracting only general data produces vendors nobody can pay or buy from. Company code and purchasing org rows are what make the vendor usable.
    Account group drives everything downstreamIt determines the number range, the field selection and whether numbering is internal or external, so it is established before extraction design is finalised.
    Bank details are fraud-sensitiveExtracted under tighter controls and frequently re-verified with the vendor rather than migrated blind.
    One-time vendorsThese use a shared master record with details on the document. They need a deliberate decision rather than being migrated as normal vendors.

    Transformation rules

    Reconciliation account mappingDetermines which G/L account payables post to. A wrong reconciliation account misstates the balance sheet.
    Payment terms and methods crosswalkMapped to configured values; unmapped terms are a common rejection.
    Account group assignmentDrives number range and field selection, and cannot easily be changed after creation.
    Partner function derivationOrdering address, invoicing party and goods supplier relationships reconstructed from source site or address roles.
    Withholding tax setupCountry-specific and mapped against configured withholding types and codes.

    Data quality and validation

    Account group valid

    And consistent with the numbering strategy.

    Reconciliation account exists

    And is a valid reconciliation account for vendors.

    Company code and purchasing org exist

    For every level being loaded.

    Payment terms and methods exist

    Every crosswalked value resolves.

    Bank key valid

    Bank keys exist in the bank master before vendor bank details load.

    Duplicate vendor check

    On tax number and normalised name.

    Load sequence and dependencies

    What has to exist before this object can load.

    1. 1Configuration: account groups, number ranges, reconciliation accounts
    2. 2Bank master data
    3. 3Vendor general data
    4. 4Company code data
    5. 5Purchasing organisation data
    6. 6Bank details
    7. 7Partner functions
    8. 8Withholding tax data

    Common migration errors

    What actually fails on this object, and why.

    Reconciliation account not valid for vendorsThe G/L account exists but is not flagged as a vendor reconciliation account.
    Company code view without general dataThe general view failed or was out of scope.
    Bank key not foundBank master was not loaded before vendor bank details.
    Unmapped payment termNo configured equivalent exists.
    Account group field selection conflictA mandatory field for that account group is missing.
    Duplicate vendorMatching on tax number and name found an existing record.

    Reconciliation

    Counts alone rarely prove this object migrated correctly.

    General data count: source vendors in scope vs loaded

    Company code view count against the expected vendor-to-company-code matrix

    Purchasing org view count against the expected matrix

    Vendors with open payables reconciled at 100%

    Bank detail coverage where electronic payment is in scope

    Reconciliation account distribution compared to the expected mapping

    How Syntra ETL supports this object

    DataMove

    Extraction, mapping, transformation, validation preparation and target load generation.

    Explore DataMove →

    DataVault

    Preserves source, prepared and target states for reconciliation, lineage and audit evidence.

    Explore DataVault →

    DataLens

    Migration progress, data quality, exceptions and readiness across cycles.

    Explore DataLens →

    Relevant migration routes

    Source-specific guidance for moving this object.

    SAP ECC→SAP S/4HANA

    SAP ECC to SAP S/4HANA data migration

    Explore migration route →    Oracle EBS→SAP S/4HANA

    Oracle EBS to SAP S/4HANA data migration

    Explore migration route →    Oracle JD Edwards→SAP S/4HANA

    Oracle JD Edwards to SAP S/4HANA data migration

    Explore migration route →

    Successfully delivered projects involving this object

    Published case studies whose scope included vendor.

    SAP ECC→SAP S/4HANANetherlands-Based EnterpriseEnterprise · Europe
    • SAP ECC Source platform
    • SAP S/4HANA Target platform
    • Multi-cycle Controlled migration cycles
    Critical SAP data transitioned to S/4HANA with greater cutover confidence through repeatable migration cycles.MIGRATION COMPLETEView Project →

    Frequently asked questions

    What is the difference between vendor general, company code and purchasing data?
    General data is client-wide and describes who the vendor is. Company code data governs accounting — reconciliation account, payment terms, dunning. Purchasing organisation data governs buying. A vendor needs all three levels to be usable end to end.
    Does the vendor master still exist in S/4HANA?
    Not as an independent object. Vendors become Business Partners with the vendor role, so a vendor migration into S/4HANA is really a Business Partner migration with vendor-role data.
    Why does the reconciliation account matter?
    It determines which G/L account payables post to. A wrong reconciliation account misstates the balance sheet and is difficult to correct once transactions have posted.
    Are vendor bank details migrated?
    Where they are in scope, under tighter controls than the rest of the object. Many organisations re-verify bank details directly with the vendor rather than migrating them, because supplier bank data is a known fraud target.

    Planning a similar data migration?

    Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.

    Discuss Your MigrationExplore Migration Routes