Oracle Fusion · Financials · Master data

Oracle Fusion Customer Data Migration

Migrate customer master data into Oracle Fusion, covering the party, customer account, account sites, site uses, contacts, profile classes and tax attributes.

Discuss Your Migration All Migration Objects

Object overview

Oracle Fusion does not have a flat customer table. It has the Trading Community Architecture: a party that describes who the organisation is, one or more customer accounts describing your commercial relationship with it, account sites that place those accounts at addresses, and site uses that say what each site is for — bill-to, ship-to, dunning. A single legacy customer row typically becomes four or five TCA records.

That expansion is why customer migration reconciles differently from supplier migration. Counting customers in and customers out proves nothing on its own; the party, account, site and site-use counts each need their own expected figure.

What data is typically migrated

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

Data area	Typical information
Party	Organisation name, party number, party type, DUNS, party classification
Customer account	Account number, account name, status, account type, class
Party sites and account sites	Addresses and the accounts placed at them
Site uses	Bill-to, ship-to, dunning, statements — with primary flags
Contacts	Party contacts and their role at each account site
Profile classes	Credit limits, payment terms, dunning and statement settings
Tax	Tax registrations, tax classification, exemption certificates

Object relationships

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

Party (organisation)

└─ Party site (address)

└─ Customer account

└─ Account site

└─ Site use (bill-to / ship-to)

└─ Account profile / credit

└─ Contact

└─ Contact role at account site

└─ Tax profile

Object migration flow

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

Before you migrate this object

Confirm each of these before the first migration cycle.

□Business units and receivables configuration exist

□Profile classes are designed and configured

□Geography and country address validation is loaded for every country in scope

□Party-versus-account rules are agreed with the business

□Duplicate match-and-merge rules are approved

□Tax regimes are configured for every country in scope

□The Original System Reference strategy 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 SupportedSalesforce Production-provenMicrosoft Dynamics 365 SupportedPeopleSoft Supported

Source-to-target mapping examples

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

Source system	Source entity	Target object
Oracle EBS	Customer + Account + Site Uses	Fusion Party + Account + Site Uses
SAP ECC	Customer master (KNA1/KNB1/KNVV)	Fusion Party + Account + Sites
SAP S/4HANA	Business Partner (customer role)	Fusion Party + Account
Salesforce	Account	Fusion Party + Customer Account

Migration methods for this object

Customer Import FBDI (party, account, site, site use, contact files)

Trading Community REST services for incremental updates

Original System Reference to carry the legacy key onto the party

Extraction considerations

Sold-to, bill-to and ship-to in SAPSAP partner functions on the customer master already express what Fusion calls site uses. Extracting them is what lets you rebuild bill-to and ship-to correctly rather than defaulting every site to both.

Sales-area and company-code dataSAP customer data splits across general, company code and sales area tables. The company-code and sales-area rows drive how many Fusion accounts and sites the customer becomes.

Customers with open receivablesAny customer with an open AR balance must migrate regardless of activity policy, because the receivable cannot land without its customer.

Duplicate parties across systemsIn a consolidation the same organisation exists in several sources with different keys. Match-and-merge rules are agreed before extraction, not after load.

Transformation rules

Flat customer to party plus accountThe single largest transformation on this object. Deciding when one legacy customer becomes one party with several accounts, versus several parties, is a business rule not a technical one.

Partner functions to site usesSource bill-to and ship-to relationships become Fusion site uses with primary flags set deliberately rather than defaulted.

Credit and payment terms to profile classesFusion groups credit limit, terms and dunning behaviour into profile classes. Legacy per-customer values are mapped onto a designed set of classes.

Original System ReferenceThe legacy customer key is carried onto the party so AR transactions can resolve to the right customer and so reconciliation has a join key.

Address and geography normalisationFusion validates against country-specific formats and geography structures, so free-text legacy addresses are parsed.

Data quality and validation

Party and account completeness

Every account resolves to a party; every site resolves to a party site.

At least one bill-to

A customer account that will carry receivables needs a bill-to site use.

Profile class exists

Every mapped profile class is configured in Fusion.

Duplicate party detection

Matched on tax registration, normalised name and address before load.

Tax registration format

Validated per country against the configured tax regime.

Load sequence and dependencies

What has to exist before this object can load.

1Reference data (BUs, profile classes, tax regimes, geography)
2Party
3Party site
4Customer account
5Account site
6Site use
7Account profile
8Contacts
9Tax profile

Common migration errors

What actually fails on this object, and why.

Account without a bill-to site useReceivables cannot be created against the account.

Party site missing geographyThe address could not be resolved against Fusion's geography hierarchy for that country.

Unmapped profile classThe customer references a credit profile that does not exist in the target.

Duplicate partyFusion already holds a party matching on name and tax registration.

Site use primary conflictTwo sites flagged primary for the same use on one account.

Orphaned account siteThe party site it depends on failed to load.

Reconciliation

Counts alone rarely prove this object migrated correctly.

Party count, account count, site count and site-use count each against their own expected figure — not against a single customer number

Customers with open AR reconciled separately and at 100%

Bill-to and ship-to coverage: every account carrying receivables has a bill-to

Key field comparison on a sample: name, tax registration, credit limit, terms

Rejected records categorised, agreed exclusions listed

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 customers.

SAP ECC→Oracle Fusion CloudLarge UK EnterpriseEnterprise · UK

SAP ECC Legacy source platform
Oracle Fusion Target cloud platform
Multi-cycle Rehearsals before cutover

Successful SAP ECC to Oracle Fusion migration with comprehensive source-to-target reconciliation across cycles.MIGRATION COMPLETEView Project →SAP R/3→Oracle Fusion CloudLarge German EnterpriseEnterprise · Europe

SAP R/3 Legacy source platform
Oracle Fusion Target cloud platform
Multi-cycle Controlled migration cycles

Successful migration to Oracle Fusion Cloud with reduced manual conversion and comprehensive reconciliation and auditability.MIGRATION COMPLETEView Project →

Frequently asked questions

Why does one legacy customer become several Fusion records?

Because Fusion separates who the organisation is (the party) from your commercial relationship with it (the customer account) and from where it transacts (sites and site uses). A single legacy row typically becomes a party, an account, one or more sites and their site uses.

How do bill-to and ship-to get set correctly?

From the source's own partner functions or site-use equivalents. Defaulting every site to both bill-to and ship-to is a common shortcut that causes invoicing and delivery problems after go-live.

Can inactive customers be excluded?

Usually yes, with one hard exception: any customer with an open receivable must migrate, because the AR transaction cannot load without its customer account.

How are duplicate customers handled across multiple source systems?

Match-and-merge rules are agreed before extraction and applied in transformation, with the surviving party carrying an Original System Reference for each source key so both legacy identities remain traceable.

How is customer migration reconciled?

At each TCA level separately. Party, account, site and site-use counts each have their own expected figure derived from the source and the enterprise structure, because they are not one-to-one with each other.

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