A B2B Webshop on SAP Commerce Cloud with S/4HANA Public Cloud Behind It: Which Data Goes Where?

If you are building a B2B webshop on SAP Commerce Cloud with S/4HANA Public Cloud behind it, you will answer the same question over and over in four variations: does the data move into the shop, or does the shop fetch it live from the ERP at the moment it matters? Answer it with a blanket rule and you build either a sluggish shop or an overloaded ERP. The right answer differs per data class, and that is what this post is about.

TL;DR: Replicate products and catalog into Commerce Cloud and enrich them there. Call customer-specific prices and availability live from S/4HANA, with a cache of a few minutes. Send orders asynchronously through a monitored queue, and read order history live from the ERP. SAP’s standard integration package covers most flows; live pricing is the part you design deliberately.

The core question: replicate or call in real time?

Four data classes, four decisions. From our project experience, the split looks like this:

Products and catalog: replicate. The product master flows into Commerce Cloud and is enriched there: sales copy, images, attributes for faceted search, category tree, SEO data. None of that belongs in the ERP; it belongs in the shop, where content teams work with it. The ERP stays the structural master: material number, units and classification come from S/4HANA and are never overwritten in the shop. Catalogs change rarely enough that replication is entirely sufficient.

Customer-specific prices: call in real time. In B2B, almost every customer has their own conditions: contract prices, scales, discount schemes. That logic lives in S/4HANA and should stay there. SAP’s standard package replicates prices and discounts into the shop, which works for list prices. For contract pricing we let the shop ask S/4HANA at display time, based on the ERP’s pricing simulation, with a short cache of a few minutes. One price truth, no second pricing logic to keep in sync.

Stock and availability: call in real time, cached briefly. In B2B, availability is a promise, not decoration. The shop checks availability against S/4HANA and caches the result for minutes, not hours. If you only replicate stock overnight, you spend the day promising goods that are already gone.

Orders: send asynchronously. The order is confirmed in the shop, then pushed into the ERP through a queue with proper error handling: if creation in S/4HANA fails, the order lands in an error queue with an alert, not in a black hole. Order history in the account area, on the other hand, is read live from S/4HANA, so the customer also sees orders that came in by phone or EDI. How the order lifecycle runs inside the shop itself, from cart to returns, is described in order management in SAP Commerce Cloud.

SAP publishes the building blocks as the SAP Commerce Cloud Integration with SAP S/4HANA Cloud package on the SAP Business Accelerator Hub: materials and classification, B2B customers, prices and discounts, stock levels, order replication to S/4HANA, order and delivery notifications back to the shop, and returns. SAP’s documentation of the S/4HANA order management integration describes the Commerce side.

Why B2B works differently from B2C

The B2C recipes fall short in B2B, for four reasons.

First, prices. In B2C one price applies to everyone, so you can replicate it without a second thought. In B2B, the price is a function of customer, quantity, contract and the current state of the condition tables. Hence the live call.

Second, buying behaviour. B2B customers do not browse, they procure. Order templates, re-ordering from history and quick entry by article number matter more than product staging.

Third, the credit limit. Before checkout, there should be a check against credit management in S/4HANA. An order that immediately hits a credit block in the ERP helps nobody, least of all the back office that has to release it by hand.

Fourth, the ordering channels. Large customers order via punch-out from their procurement system; mid-sized ones upload CSV files with fifty line items. Both have to feed the same order interface as the cart.

What goes wrong in projects, and how to avoid it

The most common mistake we find in existing architectures is nightly full price replication for contract prices. It looks harmless until the first contract is adjusted during the day. The shop then shows the old price until the next morning, the customer orders, the order confirmation from the ERP differs, and the back office makes phone calls. The fix is not faster replication but a live price call with a short cache.

The second classic is posting the order synchronously: the checkout waits until S/4HANA has created the order. That works until the ERP is in a maintenance window or a release upgrade. Then checkout breaks, precisely for the customers who wanted to order at ten in the evening. Orders belong in a queue: the shop confirms immediately, the ERP processes as soon as it can, and errors land in a monitored queue instead of in the customer’s lap.

The third point is less technical: the feature zoo. Configurators, marketplace connections, loyalty, all in phase one. Our advice is a lean first release: catalog, customer-specific prices, ordering, order history. That is the core a B2B customer can work with productively, and it goes live in months, not years. Everything else follows, prioritised by what real customers miss in the real shop. For smaller B2B businesses, the SAP Commerce Cloud ERP Edition packages much of this for S/4HANA Public Cloud.

Built once, used many times

The interface layer that emerges here is not a shop accessory but a building block. Price call, availability check, order queue and history API are cleanly separated from the frontend. Today this layer serves SAP Commerce Cloud; tomorrow it serves a field sales app, a customer portal or another sales channel, without new work on the ERP side. That is what composable means in practice, as described in our post on composable commerce in B2B.

It is also why we plan shop and ERP with one team; our guide to the best SAP partner for Cloud ERP and CRM in Switzerland makes that case, the integrated S/4HANA Public Cloud and Sales Cloud V2 stack shows the CRM side of the same ERP, and the best SAP Commerce Cloud partners in Switzerland lists who to talk to. How we deliver this as a project is described on our page on SAP B2B commerce for distributors in Switzerland.

Frequently asked questions

Does S/4HANA Public Cloud have the APIs for this pattern?

Yes. SAP publishes a standard integration package for SAP Commerce Cloud and S/4HANA Cloud covering materials, B2B customers, prices and discounts, stock, orders, order and delivery notifications and returns. Live price and availability calls use released S/4HANA APIs documented on the SAP Business Accelerator Hub, and SAP Integration Suite handles mapping, queueing and error handling without modifications.

Does guest checkout work in B2B?

Usually not, and that is not a shortcoming. B2B accounts hang off the customer record in the ERP, where conditions, credit limit, delivery addresses and payment terms are anchored. An anonymous cart can use none of that. A lean registration flow, after which the back office links the shop account to the right ERP customer, works better.

Where does product content live, in the ERP or in the shop?

Both, with a clear division of labour. The ERP remains the structural master for material number, units and classification; Commerce Cloud acts as a lightweight PIM for copy, images, attributes and categories. A separate PIM system only pays off once several channels consume the same content in several languages; before that, it is one system too many.

How fresh does stock in the shop need to be?

Fresh enough that the promise holds. A cache of two to five minutes on the availability check is the right trade-off in most B2B scenarios: it shields the ERP from load peaks and keeps the display close to the truth. Nightly stock replication invites delivery conflicts.

---

Planning a B2B shop on SAP Commerce Cloud, or does your existing shop struggle with stale prices and stuck orders? We will walk you through the architecture using your data classes. Talk to our team.