Salesforce to SAP Customer Testing
Salesforce to SAP customer testing validates the master data journey that makes every downstream order possible — an account created or changed in Salesforce becoming a customer in SAP with the right business partner roles, sales area data, partner functions, addresses and tax details, and the SAP number returning to Salesforce. It proves that sales can hand a customer to SAP without finance or order management fixing the record by hand.
Cross-application journeys, including SAP customer synchronization, are on the active roadmap and available for proof-of-concept engagements.
Why customer synchronization is a business process
Customer synchronization is often treated as a technical interface, but its outcome is a business event: a prospect in Salesforce becomes a customer SAP can sell to, ship to and invoice. In SAP S/4HANA that customer is a Business Partner with a customer role, general data, company code data for accounts receivable, and sales area data for each combination of sales organization, distribution channel and division. In SAP ECC the same information sits in the customer master tables. Each of these layers must be correct before a sales order can be created.
The trigger usually sits in Salesforce: an account reaching a status such as Approved for Order, a closed-won opportunity, or a request submitted by sales operations. The data then moves through middleware — commonly SAP Integration Suite or MuleSoft — into SAP via OData APIs, SOAP services or IDocs such as DEBMAS, and an acknowledgment writes the SAP customer or business partner number back to the account.
Testing that journey end to end catches the failures that neither the Salesforce nor the SAP team sees on its own. It is the natural precursor to Salesforce to ERP order testing, because an order cannot land correctly for a customer that did not.
What goes wrong with customer handoffs
Customer master defects are rarely dramatic. They surface as blocked orders, misdirected invoices and duplicate customers weeks after the sync ran.
Incomplete sales area data
The business partner is created, but without sales area data for the sales organization the order will use, so order entry fails in SAP.
Wrong partner functions
Sold-to, ship-to, bill-to and payer are collapsed into one party when the Salesforce account hierarchy intended separate ship-to locations.
Address and tax formatting
Region codes, postal formats or VAT and tax numbers valid in Salesforce fail SAP validation, and the record is rejected or created without them.
Duplicate customers
The SAP number is not written back, so a later account update creates a second business partner instead of changing the first.
Lost updates
Changes to an existing customer, such as a new billing address, are not sent, or overwrite values SAP owns such as credit or payment terms.
Hierarchy mismatches
Parent and child accounts in Salesforce do not map to the SAP customer hierarchy, affecting pricing and reporting.
Field mapping to assert on both sides
The specific fields depend on the SAP release and integration design. These are the groups a customer test typically reconciles.
| Salesforce source | SAP target | What to assert |
|---|---|---|
| Account Name, legal name fields | Business partner organization name fields | Names split and truncated according to the agreed rules |
| BillingAddress and ShippingAddress | Business partner addresses and address usages | Country, region and postal codes valid and mapped to the right usage |
| Tax and VAT number fields | Business partner tax numbers by category | Correct tax number category per country; validation passes |
| Sales org, channel and division fields or rules | Customer sales area data | Sales areas created with required fields such as currency, incoterms and shipping conditions |
| Related ship-to accounts or addresses | Partner functions on the sales area | Sold-to, ship-to, bill-to and payer relationships match the design |
| Payment terms and currency | Company code and sales area terms | Terms and currency match, or SAP-owned values are left untouched |
| SAP customer number field | Business partner and customer number | Number written back to Salesforce and used as the key for updates |
The happy path, step by step
SyntraFlow is designed to run customer creation and change as one cross-system scenario, asserting on the Salesforce account and on the SAP customer as read through the interfaces the customer provides.
Create a qualified account
Sales creates an account with legal name, addresses, tax number and the attributes that determine the SAP sales area, under the profile that normally does this work.
Trigger the handoff
The account reaches the status or approval that sends it to SAP, and the test confirms the trigger fires once and only for eligible accounts.
Read the SAP customer
The business partner or customer is retrieved from SAP, and general data, roles, addresses, tax numbers and sales area data are compared to the source.
Confirm the write-back
The SAP number and integration status appear on the Salesforce account, so later changes and orders can reference the customer reliably.
Change the customer
A billing address and a contact detail are updated in Salesforce, and the test confirms the same SAP record is updated rather than a new one created.
Prove order readiness
Where in scope, a simple order is simulated or created in SAP for the new customer, confirming the master data is complete enough to sell.
Negative and exception paths
Master data integrations need to reject bad data as reliably as they accept good data.
- An account with an invalid VAT number for its country, confirming SAP rejects it and the error is visible on the Salesforce account.
- An account that already exists in SAP under another number, confirming duplicate checks match rather than create.
- An address in a country whose region values are not mapped, confirming a clear failure rather than a blank region.
- An update to a field that SAP owns, such as credit limit or payment block, confirming Salesforce does not overwrite it.
- Middleware downtime followed by recovery, confirming queued changes apply in the right order, as covered in error recovery testing.
- Merging two Salesforce accounts that each have an SAP number, and confirming the agreed survivorship rule is applied.
- Deactivating or blocking a customer and confirming the status is communicated as designed.
Roles, access and test data
Several roles shape this process. Sales reps create and edit accounts, sales operations or a data steward approves them for SAP, the integration user performs the create in SAP, and the SAP master data team owns the fields Salesforce should never touch. Each has different access, and the integration user in particular needs exactly the SAP authorizations and Salesforce permissions required — no more. Integration user testing covers the Salesforce side of that least-privilege check.
Test data must reflect the organizational setup in the SAP test client: valid sales organizations, distribution channels, divisions, account groups or business partner groupings, and number ranges. Account data should cover the countries the business trades in, because address and tax validation differ widely. Coordinating those values, and knowing which SAP numbers a run created, is part of cross-system test data.
Suggested test scenarios
A starting set for customer creation and maintenance across Salesforce and SAP.
| Scenario | What it proves |
|---|---|
| Domestic customer creation | A standard account becomes a complete SAP customer with write-back |
| Cross-border customer with VAT | Country-specific address and tax rules are satisfied |
| Multiple ship-to locations | Partner functions reflect the Salesforce account structure |
| Billing address change | Updates reach the existing SAP record without duplication |
| Invalid tax number | SAP validation failures return visibly to Salesforce |
| SAP-owned field protection | Credit and payment fields are not overwritten |
| Retry after outage | Queued creates and updates apply once and in order |
Evidence and regression coverage
Each run is designed to record the Salesforce account at the point of handoff, the middleware transaction reference where accessible, the SAP business partner or customer as read back, the write-back values, and a field-by-field reconciliation. Master data owners on both sides can review that evidence without needing access to the other system.
The integration is exposed to change from three directions: Salesforce releases and account configuration, SAP support packs and customizing, and middleware updates. Rerunning the scenarios after each keeps customer data trustworthy. Deeper integration mechanics are covered on the Salesforce to SAP integration testing page.
Related pages
Business Processes
The full library of Salesforce business process tests this journey belongs to.
Salesforce to SAP Integration Testing
The middleware, interface and reconciliation mechanics behind this process.
Salesforce to ERP Order Testing
The order handoff that depends on a correctly synchronized customer.
Data Reconciliation Testing
Field-level comparison techniques for customer master data.
Cross-System Test Data
Aligning organizational values and tracking records across Salesforce and SAP.
Integration User Testing
Least-privilege checks for the user that moves customer data.
Salesforce → SAP Customer testing FAQs
What is Salesforce to SAP customer testing?
It is testing the process that turns a Salesforce account into an SAP customer and keeps the two aligned. Tests create and change accounts in Salesforce, read the resulting business partner or customer in SAP, and reconcile names, addresses, tax numbers, sales area data, partner functions and the SAP number written back.
Does this apply to both SAP S/4HANA and SAP ECC?
The approach applies to both. S/4HANA uses Business Partner as the entry point for customers, while ECC uses the classic customer master. The target fields and interfaces differ, so the mapping and assertions are configured for the customer's SAP release.
Why test updates separately from creation?
Creation is usually tested during implementation, while updates run for years afterward. Update defects — duplicate customers, lost changes, or Salesforce overwriting fields SAP owns — are among the most common and costly, and they only appear when a record already exists in both systems.
Does SyntraFlow integrate Salesforce with SAP?
No. SyntraFlow does not move data between the systems. It is designed to test the existing integration by its result, comparing what Salesforce holds with what SAP holds through the access the customer provides.
What SAP access is needed to run these tests?
Read access to a non-production SAP client for the business partner or customer data, typically through an API or service the SAP team approves. The exact method and authorizations are agreed with the SAP basis and security teams per engagement.
Is SAP customer testing available in SyntraFlow today?
Cross-application journeys, including SAP customer synchronization, are on the active roadmap and available for proof-of-concept engagements. SAP releases, interfaces and scenarios in scope are confirmed per engagement.
Hand customers to SAP without rework
Walk through your Salesforce account to SAP customer flow and see how both sides can be reconciled in one scenario.