Why Order‑to‑Cash Remains the Hardest Constraint in S/4HANA—and What’s Actually Missing

SAP enterprises are being told they have everything they need to modernize revenue.

S/4HANA promises a clean digital core. SAP BTP promises unlimited extensibility. Together, they’re positioned as the foundation for agility, innovation, and scale.

Yet many organizations discover a familiar outcome: revenue change is still slow, risky, and deeply dependent on implementation teams. Order‑to‑Cash (OTC) remains the critical path. And complexity hasn’t disappeared- it’s just moved.

This isn’t a tooling failure. It’s an architectural one.

Outgrowing the ERP-Centric Model

For decades, ERP sat at the center of enterprise architecture. It was where process lived, rules were enforced, and change was implemented. That made sense when systems were monolithic, integrations were brittle, and alternatives were limited.

But technology has fundamentally changed.

Modern enterprise architectures are API-driven, event-based, cloud-native, and composable. Business logic no longer needs to be embedded inside systems of record to be reliable, governed, or auditable.

Yet most SAP organizations are still operating with an ERP-centric mindset.

If something affects revenue, the default assumption is that it must ultimately be implemented in, or tightly around, ERP. When that proves difficult, the logic is pushed into adjacent platforms and extensions, but the architectural assumption remains the same.

This is how “customization” survives modernization.

Not because enterprises lack better tools, but because they are applying yesterday’s design principles to today’s technology stack.

Until that mindset changes, new platforms will continue to recreate old constraints under new names.

BTP: From Extension Platform to Customization Catch‑All

SAP Business Technology Platform (BTP) was designed to extend S/4HANA without polluting the core. In principle, that’s exactly what enterprises want, and in many cases, BTP is genuinely helpful. It plays an important role in integration, workflow automation, and targeted extensions where standardization is possible.

In practice, BTP often becomes a catch‑all for anything S/4 can’t easily do, especially revenue logic. Not because BTP is flawed, but because it is frequently asked to solve problems it was never meant to fully own.

Pricing variations, approval workflows, channel rules, partner exceptions, and orchestration logic are pushed into:

• Custom apps

• Bespoke integrations

• Event-driven workflows

At that point, success depends less on the platform and more on the strength of the architect and the systems integrator (SI).

Two companies using BTP rarely end up with the same architecture. Each implementation reflects:

• Individual design decisions

• Project-specific tradeoffs

• SI preferences and patterns

What was meant to be a reusable extension layer quietly becomes a new generation of custom code, harder to reason about, harder to govern, and tightly coupled to the people who built it.

Customization didn’t go away. It was just relocated.

It’s also worth noting that cost, while not the focus of this discussion, is a very real factor. BTP licensing, consumption-based pricing, and the implementation effort required to design, build, and maintain custom extensions all contribute to long-term cost and risk. Even when budgets allow, cost rarely correlates with speed or simplicity.

Order‑to‑Cash: The Hidden Constraint in S/4HANA

Nowhere is this more visible than in Order‑to‑Cash.

OTC spans sales orders, pricing, availability, fulfillment, billing, and financial posting. In S/4HANA, these steps are deeply interconnected and highly standardized by design.

That strength becomes a limitation when businesses try to:

• Launch new pricing models

• Introduce partner‑specific programs

• Support multiple selling motions simultaneously

• Adapt quickly by channel or customer type

Even small changes ripple across the entire process and demand careful coordination, testing, and regression control.

As a result, OTC consistently becomes the gating factor in S/4HANA programs - slowing releases, extending timelines, and increasing risk. This is why so many transformation efforts stall not in finance or supply chain, but in revenue-facing workflows.

Why BTP + OTC Still Doesn’t Solve Revenue Execution

Faced with OTC rigidity, teams turn back to BTP.

Logic is split:

• Some rules live in S/4

• Some live in BTP extensions

• Some live in upstream systems

The outcome is predictable:

• Revenue logic is fragmented

• Exceptions multiply

• Testing becomes harder

• Ownership becomes unclear

What looks like flexibility on paper introduces fragility in practice.

The core issue remains unchanged: revenue execution has no dedicated home.

Revenue Execution Is Not an Extension Problem

Revenue execution is the discipline of turning commercial intent into consistent, governed action.

It includes:

• Eligibility and offer logic

• Pricing and discount decisions

• Approvals and exceptions

• Channel and partner behavior

• Fulfillment orchestration

Trying to implement this as a collection of ERP configurations and BTP custom builds forces every change to be re‑engineered.

Execution becomes project‑based instead of capability‑based.

The Missing Layer Above ERP and BTP

What SAP architectures lack is not more extensibility, it’s a dedicated revenue execution layer.

A layer designed specifically to:

• Model revenue motions once

• Govern them centrally

• Orchestrate them consistently across systems

When execution lives in its own layer:

• ERP can remain the system of record

• OTC stays stable and compliant

• BTP is used intentionally, not defensively

A Cleaner Way Forward

Modern SAP enterprises don’t need to choose between rigid cores and custom sprawl.

They need to separate how revenue is executed from where transactions are recorded.

Until revenue execution is treated as a first‑class architectural capability, BTP will continue to absorb bespoke logic—and Order‑to‑Cash will remain the constraint that slows everything else.

ERP can keep the record straight.

Revenue execution must be built to set the pace.