SAP BTP Side-by-Side Extensions: Licensing Architecture, Costs and How to Avoid Accidental Overruns

What Is a Side-by-Side Extension?

In SAP's Clean Core architecture, a side-by-side extension is a custom application or business process that runs outside the SAP core system — typically on SAP BTP — and interacts with the SAP system through approved APIs and integration services. This architectural separation is the defining characteristic of Clean Core: custom logic lives beside the SAP system, not inside it.

From a licensing perspective, side-by-side extensions are fundamentally different from classical ABAP customisations. A classical ABAP modification or enhancement ran inside the SAP system and consumed no incremental SAP licence — the SAP system licence and named user licences covered development and runtime within the system. A side-by-side extension requires a collection of BTP services for development, testing, integration, and runtime — each of which carries a separate licence or consumption cost.

The key services consumed by a typical side-by-side extension include: SAP BTP ABAP Environment or Cloud Foundry runtime (for the extension application), SAP Integration Suite (for connectivity between the extension and the SAP core), SAP Build or SAP Build Apps (optionally, for low-code extension components), SAP BTP Identity Authentication Services, and SAP API Management (if the extension exposes or consumes APIs at enterprise scale). Understanding this service stack is essential for accurate cost modelling.

The BTP Services Stack for Side-by-Side Extensions

A production-grade side-by-side extension typically requires the following BTP services. Each must be separately sized and, where not included in RISE entitlements, separately purchased.

How Accidental BTP Overruns Happen

The most common source of BTP cost overruns in side-by-side extension scenarios is the consumption-based nature of BTP services combined with inaccurate initial sizing. Unlike perpetual licences where you own a defined capacity, BTP consumption models charge based on actual usage — which means that if your extension generates more API calls, processes more messages, or hosts more users than projected, your costs increase proportionally.

Overruns typically occur in three scenarios. First, scope creep: development teams build more extensions than were in the original scope because the Clean Core model is designed to make this easy — the tooling encourages extension proliferation, and each new extension adds to the BTP consumption baseline. Second, integration complexity: the number of integration flows and message volumes through SAP Integration Suite is consistently underestimated in pre-go-live design, especially in environments with many third-party system touchpoints. Third, user growth: extensions that serve business users require BTP identity and access management capacity that scales with user count — and user adoption often exceeds projections in successful deployments.

What Should Be in Your RISE BTP Entitlements for Extensions

The following is a checklist of BTP entitlements that should be explicitly defined in your RISE or S/4HANA agreement before you sign. These are the areas most commonly left vague in SAP's standard proposals — vagueness that consistently works against the customer at renewal time.

• BTP ABAP Environment memory (production): Explicitly sized in GB for the production runtime of your planned extensions. SAP should provide a sizing recommendation based on your extension inventory — get this in writing before signature.
• BTP ABAP Environment memory (development and QA): Separate environments are required for development and quality assurance. These are not included in standard RISE entitlements and must be explicitly negotiated.
• Integration Suite message volumes: A defined monthly message volume cap for SAP Integration Suite, with an agreed overage rate. This prevents uncontrolled Integration Suite spend as extension complexity grows post go-live.
• SAP Build and SAP Build Apps entitlements: If your extension strategy includes low-code or process automation components, these must be explicitly included. They are not covered by core RISE entitlements.
• Expansion rights: Pre-agreed pricing for BTP capacity expansion — typically expressed as a percentage of the existing contracted rate — to be activated when consumption exceeds the initial entitlement without triggering a full renegotiation.

Indirect Access Risk in Side-by-Side Extensions

Side-by-side extensions create indirect access risk when they interact with SAP data in ways that are not covered by the SAP-licensed user count or the Digital Access model. SAP's official position is that extensions built using released SAP APIs and BTP services do not create indirect access exposure — but the boundary between "released" and "unreleased" API usage is not always clear in complex enterprise architectures.

The risk is particularly acute in three scenarios: when extensions use SAP data to trigger third-party systems that are not otherwise SAP-licensed, when data read from SAP via BTP is used to populate dashboards or reports accessed by users who do not hold SAP named user licences, and when integration flows retrieve or write SAP data volumes that exceed what would be covered by the licensed Digital Access document types. For detailed guidance on managing these risks, see our guide on SAP Digital Access licensing.

The safest commercial approach is to have your architecture team document the API calls and data flows for each planned side-by-side extension, and have these reviewed by independent indirect access advisory before go-live. This turns a post-go-live compliance risk into a pre-go-live negotiation point.

Negotiating BTP Side-by-Side Extension Terms: The 5 Principles

1. Never accept generic BTP credits — negotiate specific service entitlements. SAP often bundles a notional amount of BTP credits into RISE proposals. BTP credits appear generous but burn quickly when converted to actual service consumption. Negotiate specific entitlements for each service you will use (Integration Suite messages, ABAP Environment memory, etc.) rather than a generic credit pool.
2. Negotiate the development environment separately from the production runtime. SAP will often propose a combined BTP entitlement that covers both development and production needs in aggregate. Separate the two — development and production environments have different sizing characteristics and different risk profiles, and they should be priced and managed independently.
3. Get a BTP extension inventory review included in the deal. Request that SAP's pre-sales team provides a formal BTP extension sizing assessment based on your ABAP custom code scan results. Use this as the basis for your entitlement negotiation — if SAP's sizing turns out to be wrong, you have a contractual basis to request additional capacity at the same rate.
4. Establish overage rates before go-live. Negotiate what you will pay per GB of ABAP Environment memory and per million Integration Suite messages if you exceed your contracted entitlement. Leaving this unspecified means SAP can charge whatever rate they choose — typically list price — when you inevitably exceed your initial allocation.
5. Include BTP provisions in your contract renewal terms. SAP RISE contracts typically renew annually or every three years. Ensure your BTP entitlements are locked for the full contract term, with rights to convert between service types if your extension strategy evolves. This prevents SAP from renegotiating BTP pricing at your first renewal when you have live production extensions creating operational dependency.

Related Topics

BTP side-by-side extension licensing connects directly with broader Clean Core and RISE licensing topics that enterprise buyers need to understand together. Start with our guides on SAP Clean Core licensing, ABAP Cloud developer licensing, and SAP BTP credits and consumption to build the full picture.

If you are currently in commercial negotiations for RISE or S/4HANA Cloud, our RISE with SAP advisory service includes a dedicated BTP entitlement review as a standard deliverable — because this is consistently where we find the largest commercial gaps between SAP's proposal and what the customer actually needs. Contact us for a consultation before you commit.