Salesforce SAP Integration: Options, Data Flows and Pitfalls

Who owns what: the front office and back office split

In almost every company that runs both, Salesforce is where customers are won and SAP is where orders are fulfilled and paid. Reps live in Salesforce. Finance, supply chain and customer service live in SAP, whether that is SAP ECC or S/4HANA, on premise or in the cloud.

The integration exists so that reps stop asking the back office questions SAP already knows the answer to: "Is this customer on credit hold?", "What is the real price?", "Can we ship 400 units by the 15th?", "Did they pay the last invoice?". And so that back office staff stop retyping orders that reps already entered.

Before choosing any tool, write down the system of record for each kind of data. This table is the most common starting point:

The rule of thumb: whatever SAP needs to ship, bill or collect, SAP owns. Salesforce may display it, but changes go back through SAP's own processes.

What typically flows between Salesforce and SAP

Most projects cover the same six flows, roughly in this order of value:

1. Account to customer. When an opportunity is won (or a credit application approved), Salesforce asks SAP to create the customer or business partner. SAP returns its customer number, which is written back to the Account.
2. Products and prices to Salesforce. Materials sold in each sales organization, with list prices, land in Salesforce products and price books on a schedule.
3. Live price and availability. While a rep builds a quote, Salesforce calls SAP to simulate the order: net price after all conditions, tax, and an ATP date for each line.
4. Quote to sales order. When the customer accepts, the order is created in SAP from the quote, and the SAP order number comes back.
5. Order status, deliveries and invoices back to Salesforce. Reps and service agents see whether an order is open, partly delivered, shipped or billed without logging into SAP.
6. Credit and payment visibility. Credit limit, current exposure, blocks and overdue invoices appear on the Account, so reps don't quote customers who can't be shipped to.

Integration options compared

There is no button in Salesforce Setup that connects it to SAP. Every real project uses a middleware layer, a custom service, or both. Salesforce Connect is the one exception for read-only views: it can show SAP data in Salesforce through OData without copying it. The main options:

Third-party Salesforce adapters for SAP Integration Suite and SAP Process Orchestration also exist and are listed on SAP's partner pages. Many SAP shops still run SAP PI/PO; if yours does, factor its own end of maintenance into the decision rather than building new flows there. According to SAP, SAP Process Orchestration 7.5 follows the same timeline as SAP NetWeaver 7.5: mainstream maintenance ends at the end of 2027, with optional extended maintenance through 2030, and SAP points PI/PO customers to SAP Integration Suite as the successor.

Which option fits you

Six questions. The answer is a starting point for the conversation with your SAP and Salesforce teams, not a final architecture.

Real time vs batch: decide per flow

"Real time everything" is the most expensive mistake on these projects. Real-time calls need SAP services that respond fast, under load, every time a rep clicks. Use them only where a rep or customer is waiting for the answer.

How to set up a Salesforce SAP integration, step by step

The order below works for any of the platforms above. Steps 1–3 are where most of the real decisions happen.

1. Map ownership and scopeFill in a table like the one at the top of this page with your SAP and Salesforce owners in the same room. For each flow, agree on the system of record, direction, timing and what happens on conflict. Cut phase one to the flows that remove the most retyping and phone calls.
2. Clean and match master dataBefore anything syncs, match existing Salesforce Accounts to SAP customers and store the SAP number on the Account. Agree on which duplicates to merge, on which side. This step often takes longer than building the flows.
3. Choose the SAP interfaces with your SAP teamFor each flow, pick the interface: standard OData or SOAP APIs where your release has them (S/4HANA), BAPIs over RFC (for example for order creation and order simulation), or IDocs for asynchronous messages such as order confirmations. On S/4HANA, prefer released APIs over custom ABAP to keep the core clean.
4. Set up the integration user on each sideIn Salesforce, create a dedicated integration user. According to Salesforce's documentation, Enterprise, Performance and Unlimited editions include a small number of API-only Salesforce Integration user licenses; give that user a permission set with only the objects and fields it needs. In SAP, ask Basis for a technical user (system or communication user) with authorizations limited to the BAPIs and services in scope.
5. Build the canonical model and mappingDefine one middle format for customer, product, order and status, and map each system to it. Map picklists and code lists explicitly: sales organization, distribution channel, division, plant, payment terms, Incoterms, units of measure, currencies.
6. Build flows in value order, with logging from day oneStart with account to customer and products to Salesforce, then price and ATP simulation, then quote to order, then status back. Every message gets a correlation ID, a log entry and a place in an error queue if it fails.
7. Test in a Salesforce sandbox against an SAP QA systemUse a full or partial copy sandbox connected to SAP QA, never production. Test the unhappy paths on purpose: customer on credit block, material not released for the sales org, SAP down during order creation, the same order sent twice.
8. Load, reconcile, then go live in wavesRun initial loads, then reconcile counts and totals between systems (open orders, customer count by sales org). Go live with one region or business unit, watch the error queue daily for two to four weeks, then widen.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Aviation33%faster baggage weigh-inWeb and Mobile application for Airlines→Healthcare+30%lab test ordersMedical Lab Web and Native Mobile Applications→Retail · Startup700+stores aggregatedMobile application for Grocery shops→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

ECC end of maintenance and the move to S/4HANA

If you are still on SAP ECC, the integration you build now will probably have to survive an ERP migration. According to SAP's published maintenance strategy, mainstream maintenance for SAP ERP 6.0 (enhancement packages 6–8) ends at the end of 2027, with optional extended maintenance through 2030 at an extra fee. SAP has also announced the SAP ERP, private edition, transition option: eligible RISE with SAP customers who move their ECC systems to SAP ERP, private edition, before the end of 2030 can keep running them from 2031 through 2033 while they finish the move to S/4HANA. Check your enhancement package and contract terms with SAP.

What changes for the integration when you move:

• Business partner replaces customer master. In S/4HANA, customers are business partners with a customer role. Account-to-customer flows built on ECC customer BAPIs or IDocs need rework.
• APIs change. S/4HANA offers released OData and SOAP APIs for many objects. S/4HANA Cloud, public edition, allows only released APIs, so integrations that depend on custom function modules or direct table reads will not carry over.
• Numbers may change. Migrations sometimes renumber customers or materials. Keep a cross-reference table in the middle layer so Salesforce does not depend on SAP's internal numbers alone.
• Both ERPs may run at once. During a phased migration, some regions sit on ECC and others on S/4HANA. A middleware layer can route each message to the right system; point-to-point code cannot.

Pitfalls and how to fix them

• Two masters for customer data. Reps edit an address in Salesforce, the credit team edits it in SAP, and the sync overwrites one with the other. Fix: make SAP the owner of fields SAP needs to ship and bill; make those fields read-only in Salesforce once a customer number exists, and route change requests through a case or approval flow.
• Number range clashes. Teams try to create SAP customers with Salesforce IDs, or Salesforce reuses an SAP number from another sales org. Fix: let SAP assign its own numbers (internal number range), store them in an external ID field on the Account, and keep a cross-reference table for every object.
• Pricing logic copied into Salesforce. SAP pricing often combines many condition types, customer agreements, rebates and freight. A copy in Salesforce CPQ drifts within weeks, and quotes stop matching invoices. Fix: sync list prices for speed, and call SAP order simulation for the final net price before a quote is sent.
• Slow SAP calls freezing Salesforce pages. A live ATP or pricing call that takes several seconds feels broken to reps, and Salesforce limits how long callouts can run. Fix: call SAP only on an explicit button such as "Check price and availability", tune the SAP service with your Basis team, and cache results for a short time.
• Sync loops. An update from SAP changes the Account in Salesforce, which triggers an update back to SAP, and so on. Fix: ignore changes made by the integration user in outbound triggers, and send only fields that actually changed.
• Code list mismatches. Salesforce picklists say "Net 30", SAP says "Z030". New values are added on one side and orders start failing. Fix: keep the mapping table in the middleware, owned by one person, and alert on unmapped values instead of failing silently.
• Salesforce API limits. Bulk loads of products, prices and invoices can eat the org's daily API allocation and break other integrations. Fix: use the Bulk API for large loads, send changes instead of full loads, and monitor API usage.
• No error queue, no reconciliation. Failed messages vanish into logs and someone finds out from an angry customer. Fix: every failed message goes to a queue that a named person reviews daily, with a retry button. Run a weekly reconciliation report: open orders, customers and invoice totals compared across both systems.
• Data that should not sync. Full payment history, bank details, employee data from SAP HR, and every SAP customer ever created rarely belong in Salesforce. Fix: sync only what reps and service agents use, and show the rest live on demand.

Timeline and budget at a glance

These ranges are typical for mid-market and enterprise projects, not guarantees; SAP-side changes and data quality move them most. Platform licenses (BTP, MuleSoft, iPaaS) come on top of build cost. For how integration budgets break down, see our guides on API integration cost and data integration cost.

When a custom integration makes sense

A custom service between Salesforce and SAP is reasonable when you have only these two systems to connect, your logic does not fit a connector (for example complex configurable products or multi-plant ATP rules), or platform licenses would cost more over five years than building and running the service.

A solid custom build typically includes: a small service or set of functions hosted in your cloud, connections to SAP through OData, SOAP or the SAP Java Connector for BAPIs, Salesforce REST, Bulk and Pub/Sub APIs, a message queue for asynchronous flows, a cross-reference store, an error queue with a simple admin screen, alerts and runbooks. If you go this way, treat it as a product with an owner, not a one-off script. Our API development and custom software development pages describe how such builds are usually scoped.

For other Salesforce connections, from email and phone systems to other ERPs, start with the Salesforce integration guide. If you are comparing ERPs, the Salesforce NetSuite integration guide covers the mid-market alternative.

Go-live checklist

Tick what is already true for your project before the first real order flows through.

FAQ

Where Gilzor fits

Gilzor builds and maintains Salesforce integrations. Our engineers can map the data flow between Salesforce and SAP, build the integration on your chosen platform or as a custom service, add the error queues and reconciliation reports, and support it after launch (see Salesforce integration services). Gilzor works from Poland and Cyprus, with a few shared hours a day with the US East Coast.

Tell us which SAP release you run, which platform you already license and which flows hurt the most. We'll help you map ownership, compare the integration options and scope a realistic first phase.