Oracle Fusion · Financials · Master data

Oracle Fusion Supplier Data Migration

Plan and execute supplier migration into Oracle Fusion, including supplier master data, addresses, sites, contacts, tax information, payment attributes and related dependencies.

Discuss Your Migration All Migration Objects

Object overview

Supplier migration is more than loading a supplier name. An Oracle Fusion supplier is a small hierarchy: the supplier itself, its addresses, the sites that connect those addresses to business units, contacts, payment attributes, tax registrations and business classifications. Each level depends on the one above it, so load order is the design.

The part teams underestimate is the site. In Fusion a supplier site is the relationship between a supplier address and a procurement or payables business unit — which means the number of site records is a function of your enterprise structure, not of your source data. A supplier used by six business units becomes six sites.

What data is typically migrated

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

Data area	Typical information
Supplier master	Name, supplier number, type, status, parent supplier, DUNS
Addresses	Address lines, city, country, purpose flags, effective dates
Supplier sites	Address to procurement/payables BU relationships, site-level controls
Contacts	Name, email, phone, contact-to-site assignment
Payment	Payment terms, payment method, currency, remit-to, pay group
Tax	Tax registration numbers, tax classification, withholding setup
Bank details	Bank, branch and account records where the supplier is paid electronically
Classification	Supplier category, business classification, diversity certifications

Object relationships

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

Supplier

└─ Address

└─ Supplier Site

└─ Site assignment (BU)

└─ Contact

└─ Contact → Site assignment

└─ Tax profile / registrations

└─ Bank account → Payment relationship

└─ Business classification

Object migration flow

Source Suppliers→DataMove→Map & transform→Validate→Oracle Fusion Suppliers→DataVault reconciliation→Sign-off

Before you migrate this object

Confirm each of these before the first migration cycle.

□Target business units exist and are configured for procurement and payables

□Payment terms are configured and the crosswalk is approved

□Supplier classifications and categories are mapped

□Tax regimes and registration formats are configured for every country in scope

□Duplicate-matching rules are agreed with the business

□Inactive-supplier policy is agreed (migrate, archive or exclude)

□Attachment scope is agreed

□Bank detail handling and re-verification policy is agreed

Common source systems

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

Oracle EBS Production-provenSAP ECC Production-provenSAP S/4HANA SupportedOracle JD Edwards SupportedPeopleSoft SupportedMicrosoft Dynamics 365 SupportedNetSuite Custom mapping

Source-to-target mapping examples

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

Source system	Source entity	Target object
Oracle EBS	AP Supplier + Supplier Sites	Oracle Fusion Supplier + Sites
SAP ECC	Vendor master (LFA1/LFB1/LFM1)	Oracle Fusion Supplier + Sites
SAP S/4HANA	Business Partner (supplier role)	Oracle Fusion Supplier
JD Edwards	Address Book + Supplier Master	Oracle Fusion Supplier
Dynamics 365	Vendor	Oracle Fusion Supplier

Migration methods for this object

Supplier Import FBDI (supplier, address, site, site assignment, contact files)

Supplier REST services for incremental and corrective updates

ADFdi for small corrective loads

Extraction considerations

One-time and duplicate vendorsLegacy estates accumulate one-time vendors and near-duplicates created because someone could not find the existing record. Profiling for duplicates on tax registration, name and bank account is part of extraction, not a later cleanup task.

Company-code-level data in SAPSAP splits vendor data across general (LFA1), company code (LFB1) and purchasing organisation (LFM1) tables. A usable supplier record is an assembly across all three, and the company-code rows are what become Fusion sites.

Inactive and blocked suppliersDecide the policy before extraction. Most programmes migrate active suppliers plus any supplier with open transactions, and archive the rest rather than carrying a decade of dormant records into a new system.

Bank details and payment securitySupplier bank accounts are a fraud-sensitive data class. They are extracted under tighter controls than the rest of the object and frequently reconfirmed with the supplier rather than migrated blind.

AttachmentsContracts, W-9s, insurance certificates and tax certificates attached to legacy supplier records sit in a separate content store and are their own workstream.

Transformation rules

Vendor number to supplier numberDecide whether the legacy number is retained as the Fusion supplier number or replaced by a generated one with the legacy value held as an alternate reference. This decision drives every downstream transaction load.

Company code to business unit sitesEach source company-code or purchasing-org relationship becomes a Fusion site plus a site assignment. This is where record counts expand relative to the source.

Payment terms crosswalkSource payment terms are crosswalked to terms configured in Fusion. Unmapped terms are the single most common supplier load rejection.

Address and country normalisationFusion validates addresses against country-specific formats and geography data. Free-text legacy addresses need parsing into structured components.

Supplier type and classificationLegacy vendor account groups and categories map onto Fusion supplier type and business classification, which are separate concepts.

Tax registration normalisationTax registration numbers are format-validated per country and must match the tax regime configured in Fusion.

Status conversionBlocked, inactive and marked-for-deletion source statuses map onto Fusion's supplier and site status model, which is not one-to-one.

Data quality and validation

Mandatory attributes

Supplier name, supplier type, and for each site the business unit and address must be present.

Business unit exists

Every site assignment references a procurement or payables BU that has already been configured in Fusion.

Payment terms exist

Every crosswalked payment term resolves to a configured Fusion term.

Duplicate detection

Suppliers matched on tax registration, normalised name and bank account before load, so the merge decision is made deliberately.

Address format

Country-specific address validation, including postal code format and required components.

Referential integrity

A site cannot load before its address; a contact cannot assign to a site that failed.

Load sequence and dependencies

What has to exist before this object can load.

1Reference data (BUs, payment terms, tax regimes, classifications)
2Supplier
3Supplier address
4Supplier site
5Site assignment
6Contacts
7Payment and bank details
8Tax profile and registrations
9Attachments

Common migration errors

What actually fails on this object, and why.

Missing business unitA site references a procurement or payables BU that does not exist in Fusion. Usually an enterprise structure that was still being configured when mapping was built.

Unmapped payment termThe source term has no approved crosswalk. Fusion rejects the site rather than defaulting.

Duplicate supplierFusion already holds a supplier with the same name or tax registration, typically because the source contained duplicates that were never merged.

Orphaned siteThe address the site depends on failed to load, so the site has no parent.

Invalid address for countryMissing postal code, invalid state or province, or a free-text address that could not be parsed into the required components.

Invalid tax registration formatThe registration number does not match the format the tax regime expects for that country.

Supplier number collisionA retained legacy number clashes with a number Fusion has already generated or with another source system in a consolidation.

Contact assigned to a failed siteContact-to-site assignment references a site that did not load.

Reconciliation

Counts alone rarely prove this object migrated correctly.

Supplier count: source active suppliers vs prepared vs loaded

Site count: expected to be higher than supplier count — reconcile against the expected supplier-to-BU matrix, not one-to-one

Child record counts per supplier: addresses, sites, contacts, bank accounts

Key field comparison on a sample: name, tax registration, payment terms, status

Rejected records categorised by reason code

Agreed exclusions listed explicitly so the difference between source and target is explained

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→Oracle Fusion

Successfully delivered projects involving this object

Published case studies whose scope included suppliers.

Oracle EBS→Oracle FusionMajor Saudi Government OrganizationGovernment · Middle East

18 Business units
1M+ Inventory items
5× Faster than manual loading

Loaded roughly five times faster than manual loading, with every object reconciled.DELIVERED WITH GLOBAL SIView Project →

Frequently asked questions

Should suppliers or supplier sites be migrated first?

Suppliers first, then addresses, then sites. A Fusion site is the relationship between a supplier address and a business unit, so both the supplier and its address must exist before the site can be created, and the business unit must already be configured.

Can inactive suppliers be migrated?

They can, but most programmes do not. The usual policy is to migrate active suppliers plus any supplier with open transactions or a retention obligation, and archive the rest so they stay searchable without cluttering the new system.

How are duplicate suppliers handled?

Duplicates are identified before load by matching on tax registration, normalised name and bank account. The merge or exclude decision is made by the business and recorded, because Fusion will reject a second supplier that collides with one already loaded.

Why do site record counts exceed supplier counts?

Because a site expresses a supplier-address-to-business-unit relationship. A supplier transacting with six business units becomes six sites. Reconciliation therefore compares site counts against the expected supplier-to-BU matrix rather than against supplier counts.

Can supplier attachments be migrated?

Yes, but they are a separate workstream with their own volume profile. Contracts, tax certificates and insurance documents sit in a content store rather than in the supplier tables, and scope is agreed explicitly.

How are payment terms mapped?

Through an approved crosswalk from source terms to terms configured in Fusion. Unmapped terms are the most common cause of supplier site rejections, so the crosswalk is proven before the first full load rather than during it.

Are supplier bank details migrated?

Where they are in scope, they are handled under tighter controls than the rest of the object. Many organisations re-verify bank details with the supplier rather than migrating them, because the object 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 Migration Explore Migration Routes