Skip to content
Quote-to-Cash Between SAP Sales Cloud V2 and S/4HANA Public Cloud: Who Owns Which Document?
Integration · ·7 min read

Quote-to-Cash Between SAP Sales Cloud V2 and S/4HANA Public Cloud: Who Owns Which Document?

Spadoom

Spadoom

SAP CX Partner & Consultancy

Share

When a CRM and an ERP carry the same sales process, one question decides whether the integration lasts for years or turns into a permanent construction site: who owns which document? Not which interface you pick, not which mapping tool. But: in which system is a quote born, where is the order born, and who’s allowed to change what? From project experience we can say: almost every painful quote-to-cash integration we’ve been called in to fix had no clear answer to this question at the start.

For the combination of SAP Sales Cloud V2 and S/4HANA Public Cloud there is a clean answer. You won’t find it in any single SAP document, but it falls out of the standard if you read it consistently. Here it is, including the spots where we’ve burned our fingers in projects.

The Ownership Matrix: One Object, One Leading System

The ground rule is simple: every object has exactly one leading system. That’s where it gets created and changed. Everywhere else it’s a copy, and copies are read-only.

ObjectLeading systemIn the other system
Customers (business partners)S/4HANA Public Cloudreplicated to the CRM, read-only there
ProductsS/4HANA Public Cloudreplicated to the CRM, read-only there
Prices and conditionsS/4HANA Public Cloudnot replicated at all, but called live
QuoteSales Cloud V2not replicated back
Sales orderS/4HANA Public Cloudreplicated to the CRM, read-only there

The quote is born in the CRM because that’s where sales lives: opportunity, contact history, activities, all in one view. The sales order is born in S/4HANA because that’s where availability, credit limit, logistics and billing hang. The transition from one to the other runs as a follow-up document through the standard iFlows of SAP Integration Suite. And the return direction: the order shows up in the CRM as a replicated document that sales can see but not touch.

This matrix belongs on the project room wall before the first iFlow gets deployed. De facto it matters more than any technical design document.

External Pricing: One Price Truth, Not Two

The most elegant part of this architecture is the part that doesn’t replicate at all: pricing. The CRM quote calls S/4HANA pricing live. Conditions, customer-specific prices, scales, discounts: everything comes from the ERP in the very moment the sales rep enters the line item.

Why that matters: as soon as prices are maintained in two systems, you have two price truths, and sooner or later someone quotes with the wrong one. With external pricing there is exactly one place where conditions are maintained, the ERP, and the quote in the CRM calculates with the same numbers as the order and the invoice later on. No nightly price replications, no reconciliation job, no awkward conversation with the customer about why quote and invoice don’t match.

Two Pitfalls From Real Projects

The architecture above sounds tidy, and it is. In our experience, projects didn’t fail on the technology but on two functional details nobody had settled before the integration build.

Pitfall 1: The won/lost status lived on two levels. In one of our projects the ERP tracked quote status at header level: a quote is won or lost, full stop. The CRM tracked the same status per line item, because a customer can of course order three out of five items. Both are defensible. Both at the same time are poison: the win-rate analytics in the CRM counted line items, the ERP reporting counted headers, and management got presented two truths that were double-digit percentage points apart. The lesson: define the status level once, identically on both sides, and do it before the first integration piece gets built. Making the same decision afterwards costs many times more.

Pitfall 2: Rejection reasons as free text. Why was a quote lost? If the answer is a free-text field, you get “price”, “too expensive”, “price too high”, “competitor cheaper” and forty more variants of the same reason. That kills any reporting before it starts. Rejection reasons belong in a governed value list, mapped identically on both sides, with an owner who approves new values. That’s one hour of governance work in the concept phase, and it saves you years of useless analytics.

Monitoring: Who Fixes What

Replication means asynchronous messages, and asynchronous messages fail eventually. A customer without a valid VAT number, a blocked product, a mapping value that doesn’t exist on the target side. That’s normal. What’s not normal is nobody noticing.

Integration Suite message monitoring shows every failed message with payload and error reason. On top of that belongs alerting that doesn’t gather dust in a shared inbox but reaches a named person. And then the responsibility question, which you settle before go-live, nota bene: the CRM administrator fixes what originates in the CRM, meaning quote data, missing mandatory fields, value list mappings on the CRM side. The ERP key user fixes what’s rooted in the ERP, meaning master data errors, condition problems, blocked business partners. Skip this split and you get the familiar ping-pong: every failed message travels back and forth between two teams three times before anyone touches it.

The One Rule That Holds It All Together

If you take one sentence away from this article, make it this one: the same document type must never be editable in two systems. The moment an order can be changed in the CRM and in the ERP, the race of versions begins, and the integration degrades into a referee that can only lose. SAP’s standard integration enforces this rule mostly by itself, replicated documents are read-only on the other side. Resist every requirement to soften that through an extension. Every exception that feels convenient today is the data reconciliation workshop of the day after tomorrow.

Frequently Asked Questions

Can orders also be created directly in the CRM?

Technically yes, Sales Cloud V2 knows the sales order as an object. The clean pattern still stands: quote in the CRM, order in the ERP. The order needs availability check, credit limit and logistics data, and those live in S/4HANA. An order captured in the CRM is at best a pre-entry that gets checked again in the ERP, and that means one more place to maintain data.

Are quotes replicated back from S/4HANA Public Cloud into the CRM?

No. Quote replication from S/4HANA Public Cloud into the CRM isn’t supported in the standard. Quotes created in the ERP won’t show up in the CRM. One more reason to stick with: quotes are born in the CRM, and the sales view stays complete.

What about field sales without network coverage?

External pricing needs a connection to the ERP. Offline, field sales can capture items and quantities; binding pricing runs once the device is back online. For the customer meeting itself, a guide price on the replicated product master has worked well for us, clearly marked as non-binding, with the binding price arriving on synchronisation.

What happens when a replication fails?

The message stays in Integration Suite message monitoring, with payload and error reason, and can be reprocessed after the correction. What decides the outcome is the alerting and the responsibility split defined up front: CRM admin for CRM-side causes, ERP key user for master data and condition errors. Then a failure like this is a matter of minutes, not weeks.


You’re planning the integration of Sales Cloud V2 and S/4HANA Public Cloud, or your existing one produces two truths? We’ll gladly put the ownership matrix on the wall with you. Talk to us.

SAPSales Cloud V2S/4HANA Public CloudQuote-to-CashDocument FlowIntegration SuiteExternal PricingCRM
Next step

SAP Sales Cloud V2 implementation partner

Spadoom is the SAP Sales Cloud V2 implementation partner across Switzerland, Germany, Austria and Italy. 14-week median go-live. Live customers across DACH.

Related Articles

Ask an Expert