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

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

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 via replication and gets 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 here.

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 it should stay there. The shop fetches the price at display time via a pricing call, with a short cache of a few minutes. One price truth, no nightly price exports, no second pricing logic that would need to be kept in sync for years.

Stock and ATP: 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’ll spend the day promising goods that are already gone.

Orders: inject 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 my-account area, on the other hand, is read live from the S/4HANA APIs. That way the customer also sees orders that came in by phone or EDI, not just the ones from the shop.

Why B2B Ticks Differently Than B2C

The B2C recipes from the textbook 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 don’t browse, they procure. Order templates, re-ordering from history and quick entry by article number matter more than any 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 then has to dig it out by hand.

Fourth, the ordering channels. Large customers order via punch-out straight 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. It looks harmless until the first contract gets adjusted during the day. Then the shop shows the old price until the next morning, the customer orders, the order confirmation from the ERP differs, and the back office gets to make phone calls. The fix isn’t faster replication; it’s switching to real-time pricing with a short cache. After that, there is exactly one place where prices are made.

The second classic: posting the order synchronously. The checkout waits until S/4HANA has created the order. That works fine until the ERP sits in a maintenance window or takes a release. Then checkout breaks, and it breaks precisely for the customers who wanted to place their order at ten in the evening. Orders always 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 than human: the feature zoo. Configurators, marketplace connections, loyalty, all in phase one. Our advice is a buy-side MVP: catalog, customer-specific prices, ordering, order history. That’s the core a B2B customer can work with productively, and it goes live in months, not years. Everything else comes afterwards, prioritised by what real customers miss in the real shop.

Built Once, Used Many Times

The interface layer that emerges here isn’t a shop accessory, it’s a building block. Pricing call, ATP 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 just as well, without building anything new on the ERP side. In the end, composable simply means the investment in the API layer pays off again with every additional frontend.

Frequently Asked Questions

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

Yes. Released OData and SOAP APIs are available for prices, availability, orders and business partners, documented in the SAP Business Accelerator Hub. The orchestration, meaning mapping, queueing and error handling, is done by SAP Integration Suite. You work within the Public Cloud standard, without modifications, and stay release-proof.

Does guest checkout work in B2B?

Usually no, and that’s not a shortcoming. B2B accounts hang off the customer record in the ERP: conditions, credit limit, delivery addresses and payment terms are anchored there. An anonymous cart can use none of that. A lean registration flow makes more sense, behind which the back office links the shop account to the right ERP customer.

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 takes on the role of a lightweight PIM: copy, images, attributes, categories. A separate PIM system only becomes necessary once several channels consume the same content in several languages; before that, it would be 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 ATP check is the right trade-off in most B2B scenarios: it shields the ERP from load peaks and keeps the display close enough to the truth. Nightly stock replication, by contrast, is de facto an invitation to delivery conflicts.

You’re planning a B2B shop on SAP Commerce Cloud, or your existing shop struggles with stale prices and stuck orders? We’ll gladly walk you through the architecture using your data classes. Talk to us.