B2B Commerce and SAP: which data flows where?

Between Salesforce B2B Commerce and SAP, data flows four ways. Master data such as accounts, products, price books and entitlements comes into Salesforce by batch. During cart and checkout the store asks SAP live for price, availability and credit through Commerce extensions. The finished order goes out to SAP. Order confirmation, delivery and invoice come back so buyers see the status in the store. SAP stays the master for prices, stock, credit and the order. Salesforce holds the buying experience and a copy of what it needs for that. The real design work is deciding, per data item, whether it is copied or called live.

What flows between B2B Commerce and SAP?

I draw the same map at the start of every integration discussion. For a typical B2B store on Salesforce it has four blocks:

Data	Direction	When	Typical mechanism
Customer accounts, buyers, products, categories, price books, buyer groups, entitlements	SAP to Salesforce	Batch, nightly or on change	Import APIs, middleware
Price, availability, credit, tax, shipping	Store asks SAP	Live, in cart and checkout	Commerce extensions
Order with PO number, ship-to, requested date	Salesforce to SAP	When the order is placed	Order export after checkout
Order number, confirmed dates, delivery, invoice	SAP to Salesforce	On change	Update of the order summary

The table looks simple. The decisions sit in the second column of every row: which system writes, and how old the data in the store may be.

A note on names: Salesforce now also markets the product as “Agentforce Commerce for B2B”. The integration architecture is the same.

Master data comes in by batch as a copy

Everything that changes less often than a buyer clicks belongs in a copy. That covers SAP customer masters, which become accounts and buyer accounts in Salesforce, contacts who become buyers, materials that become products, product hierarchies that become categories, and prices for the store.

For products Salesforce offers a product import API1. It reads a CSV file whose column headings map to product, category and price book information, and it runs as an asynchronous job with a status you can query. Price books are mapped through the import settings of the same job. That is enough for a first load and for regular updates from a middleware that writes the file.

Buyer groups and entitlement policies decide who sees which product. They are rarely in SAP as such. They have to be derived, for example from sales organisation, customer group or brand. Write that derivation down as a rule, because otherwise someone maintains buyer groups by hand in Salesforce and the store drifts away from SAP within months.

Who owns which object is the question my object ownership matrix answers. For a store I add one column: copied or live.

Price, stock, tax and shipping live through extension points

Salesforce B2B Commerce has named extension points where your own Apex code takes over a service. The list of available extensions2 shows the ones that matter for SAP:

• Commerce_Domain_Pricing_Service for prices. By default it uses Salesforce price books.
• Commerce_Domain_Inventory_Service for stock. By default it uses Omnichannel Inventory.
• Commerce_Domain_Tax_CartCalculator and Commerce_Domain_Shipping_CartCalculator for tax and freight. By default there is no shipping charge at all.
• Commerce_Domain_Checkout_PlaceOrder with its validate method, the place for a credit or order block check right before the order is placed.
• Commerce_Domain_Checkout_CreateOrder, which creates the order from the cart.

Each extension can call SAP live. Each live call also means waiting time for the buyer, load on SAP and a question nobody likes to answer: what does the store do when SAP does not respond?

My rule: call live where a wrong value costs money or trust, copy everything else. Contract prices from SAP condition logic often fall into the first group, which I cover in customer prices in B2B Commerce. Stock is a case of its own and has its own article on live or copied stock. The credit check belongs in validate before the order exists, as described in B2B checkout with purchase order.

Extensions or the older integrations?

The integration architecture page3 is clear: since Winter ’24 Salesforce has offered Commerce extensions for pricing, inventory, shipping, tax and other services and recommends them over the older checkout integrations framework. The older framework is still supported, and the page names no date for retiring it.

There is one exception. According to the extensions guide4, payments cannot be customised with an extension yet; for those the integrations remain the way. In practice that rarely touches SAP, because dealers usually buy on account with a purchase order.

For new stores I would build every SAP call as an extension. Registration and store mapping run through the Salesforce CLI, so they can live in the repository and the pipeline. More on that in Commerce extensions: custom code that survives updates.

How does the order get to SAP, and what comes back?

When the buyer places the order, B2B Commerce creates an order and an order summary in Salesforce. The order summary has a field OrderLifeCycleType. According to the developer guide5, “unmanaged” marks a summary created by B2B Commerce whose lifecycle runs in an external system, and changes there “must be reflected in Salesforce”.

That is the normal case with SAP. The order goes out, SAP creates the sales order, and the integration writes the status back:

Users with the permission B2B Commerce Integrator User or Edit Unmanaged Order Summaries may update these summaries. Who should own the order, and when Salesforce Order Management makes sense instead, is the subject of B2B store orders to the ERP.

Plan the return flow as carefully as the outbound one. A dealer who sees “order received” for three days calls inside sales, and the store has saved nothing.

Middleware or direct callouts?

MuleSoft offers an Accelerator for SAP6 for SAP ECC, S/4HANA and Salesforce. Its quote-to-cash use case syncs order, inventory and customer data between Sales Cloud and S/4HANA, and a second use case covers B2B EDI. It gives you API templates to start from. It does not contain a ready-made B2B Commerce store integration, so the store side remains your work.

Direct Apex callouts with named credentials are fine for one store with two or three live calls and one order export. A middleware layer pays off when the same SAP data also feeds Field Service, Manufacturing Cloud or Agentforce agents. Then one order status API serves the store, the order status agent and the service team. The AI masterclass explains in the chapter on MCP and interfaces why agents should reuse such APIs instead of getting their own.

Worked example: S/4HANA and 300 dealers in Europe

A machine builder runs SAP S/4HANA and wants a store for 300 dealers in Europe with 15,000 spare parts. The interface list after the first workshop could look like this:

1. Customer master to accounts and buyer accounts, nightly.
2. Materials and product hierarchy to products and categories, nightly, through the product import.
3. List and dealer tier prices to price books, nightly.
4. Contract prices of the 40 largest dealers live through the pricing extension.
5. Stock status copied hourly, confirmed date live at checkout.
6. Credit and order block live in validate.
7. Order to SAP, order number and status back within minutes, deliveries and invoices on change.

Seven interfaces, three of them live. That is a realistic scope for a first release, and each of them needs an owner on the client side.

First step: object ownership matrix and interface list

Write the object ownership matrix and the interface list before anyone designs the store pages. For every data item, note the master system, copy or live, maximum age and what happens when SAP is down. The ERP integration chapter of the B2B Commerce masterclass puts these decisions in order, and an independent review of interfaces is part of my work on Salesforce integration.

Sources6

1. 1product import API (opens in a new tab)developer.salesforce.com
2. 2list of available extensions (opens in a new tab)developer.salesforce.com
3. 3integration architecture page (opens in a new tab)developer.salesforce.com
4. 4extensions guide (opens in a new tab)developer.salesforce.com
5. 5developer guide (opens in a new tab)developer.salesforce.com
6. 6Accelerator for SAP (opens in a new tab)anypoint.mulesoft.com