SAP S/4HANA Public Cloud + SAP Sales Cloud V2: The Integrated CX + ERP Stack

S/4HANA Public Cloud and Sales Cloud V2 are designed to share one customer: the same Business Partner, the same products and prices, one order flow. Most DACH companies running SAP already have a CRM and an ERP; the problem is that the two do not agree on who the customer is.

TL;DR: Both products build on SAP’s Business Partner model, and SAP publishes standard integration content for Sales Cloud V2 and S/4HANA Cloud Public Edition that runs on SAP Integration Suite. Master data, pricing and fulfilment stay in the ERP; pipeline, activities and service cases live in Sales and Service Cloud V2; integration and extensions sit on BTP. What still needs deciding in your project is scope: which fields replicate, which direction each flow runs, how errors are monitored and who owns the integration after go-live.

This post explains how that integration works, where the logic lives, and how to sequence an implementation so you do not carry the old data quality problems into a newer system.

Why pair S/4HANA Public Cloud with Sales Cloud V2?

Because a salesperson quoting a deal and a finance person booking an invoice should be looking at the same customer.

In many SAP landscapes we walk into, they are not. The CRM holds a customer record with a different name format, different address fields and a different credit status than the ERP record. Sales does not know the customer has an overdue invoice. Finance does not know the customer just signed a new contract.

The traditional fix is an integration that syncs fields between two different data models. That works, but it is brittle: every schema change on either side breaks something, and eventually one person maintains an interface nobody else understands.

The S/4HANA Public Cloud and Sales Cloud V2 combination reduces that problem because both use the Business Partner concept. S/4HANA is the master, Sales Cloud V2 receives the replicated record, and the mapping between the two is largely predefined in SAP’s content package instead of invented per project. When a sales rep looks up a customer, they see the account the finance team maintains in the ERP. There is still an integration to run and monitor, but it connects two compatible models rather than translating between incompatible ones.

For DACH companies moving off SAP S/4HANA on-premise or ECC, this is one of the real arguments for the public cloud route: a CRM and an ERP that share the same foundation.

One customer data model, not two

The Business Partner model is the backbone of both systems. In S/4HANA Public Cloud, every customer is created as a Business Partner. Sales Cloud V2 receives that record via SAP Integration Suite, so account data in Sales Cloud reflects what S/4HANA holds: company name, addresses, payment terms and, where you include it in scope, credit and dunning information.

For sales reps, this changes the conversation they can have with a customer. When a rep opens an account in SAP Sales Cloud V2, they can see the financial picture: open items, credit exposure, order history. They do not need to call finance to find out whether a deal is at risk.

For service teams, the same model means cases in SAP Service Cloud V2 are tied to the same customer entity that lives in the ERP. No separate lookup, no “which system do I trust?”.

The synchronisation is a design decision, not an automatism. Business Partner records are maintained in S/4HANA as the master system, and changes flow to Sales Cloud V2 through integration events. New customers created in Sales Cloud V2 during acquisition can flow back to S/4HANA for ERP onboarding. The direction of each flow and the field mapping are decided at implementation time, not discovered after go-live.

The quote-to-order-to-invoice loop

This is where the integration pays off most visibly for sales teams.

A rep builds a quote in Sales Cloud V2. Products and prices come from S/4HANA; if you run SAP CPQ, the configuration and pricing logic runs there. The customer sees a quote built on real pricing data, not a spreadsheet the rep maintains separately. Our post on quote-to-cash between Sales Cloud V2 and S/4HANA Public Cloud goes through that flow step by step.

When the customer accepts, the order is passed to S/4HANA for fulfilment instead of being emailed to an internal team for manual entry. The warehouse picks it, logistics ships it, finance invoices it.

Delivery and invoice status (posted, paid, overdue) flow back into the Sales Cloud account view. The rep can see whether last month’s order has been paid without opening a finance portal, and service can see delivery status without calling the warehouse.

That loop, quote to order to invoice, visible in Sales Cloud, is what “integrated CRM and ERP” means in practice: a flow where data moves without manual re-entry.

Clean core: where the integration logic lives

SAP’s clean core principle matters here. The goal is to keep customisation out of the S/4HANA core and put integration and extension logic on the SAP Business Technology Platform.

For a Sales Cloud and S/4HANA integration, that means:

• Released standard APIs on both sides (OData, SOAP, events), documented on the SAP Business Accelerator Hub
• Integration flows in SAP Integration Suite on BTP
• SAP’s pre-built content packages as the starting point for the standard scenarios
• Custom logic (pricing rules, approval workflows, special mappings) in BTP extensions or SAP Build, not in modifications of S/4HANA

The benefit is practical. S/4HANA Public Cloud is upgraded by SAP on a fixed release schedule for every customer, and an integration built on released APIs and side-by-side extensions is designed to survive those upgrades. Logic that depends on unreleased objects is what turns an upgrade into a regression test campaign.

What stays in S/4HANA vs Sales Cloud V2 vs BTP

Responsibility	Where it lives
Customer master data (Business Partner)	S/4HANA Public Cloud
Product catalogue, pricing conditions	S/4HANA Public Cloud
Order management, fulfilment, invoicing	S/4HANA Public Cloud
Opportunity management, pipeline, forecasting	Sales Cloud V2
Customer interactions, activities, visit reports	Sales Cloud V2
Service cases, SLA tracking, escalations	Service Cloud V2
Integration flows, event processing, error handling	BTP Integration Suite
Extensions, custom apps, AI features	BTP (side-by-side)

There are edge cases, but as a starting model it is cleaner than most landscapes we inherit. The integration architecture guide covers the patterns in more technical depth.

What this looks like in Spadoom projects

The pattern before a project is consistent: sales reps maintain customer data in a CRM that is loosely synced with SAP, finance has the authoritative customer record but sales cannot see it, order entry is manual, and the sales team learns about a credit block when the customer complains.

After the project, the Sales Cloud account view shows open items and order history from the ERP, quotes are built on real prices, and orders flow in without re-entry.

Three published projects show different parts of this:

• At intelligentfood, Spadoom delivered Sales Cloud V2, the integration with Cloud ERP and work in parts of MM and SD. The Sales & Service platform went live in three months (the figure refers to that platform, not to the whole ERP implementation).
• At Nussbaum Matzingen, a packaging manufacturer, Sales Cloud V2 replaced spreadsheets and Outlook folders with one sales platform in five months and gave management full pipeline transparency, with SAP ECC as the back end.
• At Miltenyi Biotec, we connected Commerce Cloud, marketing, Customer Data Cloud, S/4HANA and Service Cloud V2 through SAP Integration Suite, so service works on the same customer data as the rest of the landscape.

None of this is dramatic. It is what CRM and ERP integration is supposed to do, and it works when the data model is shared from the start.

How to sequence the two projects

The most common mistake is running CRM and ERP as parallel, independent projects that are supposed to “connect later”. They rarely do, or they connect superficially and the integration debt piles up.

The better sequence:

1. Design the shared data model first. Before any system configuration, agree on what a Business Partner looks like, how accounts and contacts are structured and where master data is maintained. This is a business decision, not a technical one.
2. Stand up S/4HANA first, or in parallel with Sales Cloud, not after. If Sales Cloud goes live on a temporary integration with your old ERP, you rebuild that integration at the S/4HANA go-live.
3. Define the integration scenarios before go-live. Quote-to-order, invoice visibility and customer master sync are configured and tested in a dedicated integration environment; they cannot be bolted on at the end.
4. Test the integration in real systems before go-live. Mock the S/4HANA side early if you must, but the flows should be tested end to end before the first real order goes through.

The sequencing options and their trade-offs are covered in our guide on how to implement S/4HANA Public Cloud and Sales Cloud V2 together. If you are still choosing who should deliver it, our guide to the best SAP partner for Cloud ERP and CRM in Switzerland explains why one team for both halves matters.

---

Most companies are somewhere in the middle: running one or both systems, not fully connected. The five-day S/4HANA readiness assessment gives you scope, sequence and a cost range for both halves before you commit, as the first step of an ERP and CX transformation. Or talk to us about your specific setup.

You might also find these useful:

• Why SAP Sales Cloud V2 is the right CRM for S/4HANA Public Cloud
• What S/4HANA Public Cloud covers natively vs what needs Sales/Service Cloud V2
• S/4HANA Public Cloud + Sales Cloud V2 vs Salesforce
• SAP S/4HANA Public Cloud solution overview