saptutorials in Blog

SAP BTP Service Offerings and Plans: A Practical Guide to How It All Fits Together

Anyone who opens the SAP Business Technology Platform (SAP BTP) cockpit for the first time meets the same wall of vocabulary: environments, subscriptions, instances, plans, entitlements, quotas. The catalog is large, and the terms overlap in ways that are not obvious until you have built a few solutions.

The good news is that the model is consistent. Three layers work together: a technical layer that defines how a service is delivered, a commercial layer that defines what you pay for, and an account layer that defines who can use what, and where. Once you see how these layers interlock, the catalog stops being intimidating and starts being a toolbox.

This post walks through each layer, then shows how real solutions combine services across identity, user experience, connectivity, integration, data, and operations.

Table of Contents

Toggle

1. The three types of service offerings

SAP BTP organizes its capabilities into three delivery models. Knowing which one you are dealing with tells you how to consume the service and who the consumer is.

Environments (platform as a service)

Environments are the runtimes where your custom code is deployed and executed. They are provisioned at the subaccount level. SAP BTP offers three strategic runtimes:

Cloud Foundry: a polyglot, buildpack-based runtime that is the most common home for applications built with the SAP Cloud Application Programming Model (CAP).
Kyma: a Kubernetes-based runtime for teams that want container-level control and cloud-native extension patterns.
ABAP environment (often called Steampunk): a managed ABAP runtime for building cloud-ready extensions and custom ABAP applications.

Subscription-based services (SaaS and multitenant applications)

These are centrally managed web applications that you subscribe to in a subaccount. When the subscription is created, the platform generates an access URL so that people can work in the application directly through a browser. Typical examples include SAP Business Application Studio, SAP Integration Suite, and SAP Build Process Automation.

The key point: subscriptions are built for human users. Developers, administrators, and business users log in and work in a user interface.

Instance-based services

Instance-based services are backing services that you create as discrete instances, either inside an environment space or at the subaccount level. Your applications bind to these instances, receive credentials through environment variables, and consume the service through APIs. Well-known examples include SAP HANA Cloud, the Destination service, the Connectivity service, and the Authorization and Trust Management service (XSUAA).

The key point: instances are built for applications and programmatic access.

The interplay pattern

Many services appear in both forms. A typical pattern is a subscription plan that gives developers and administrators a visual cockpit to design and configure a solution, paired with an instance plan that lets the runtime application call the same capability through APIs. If you ever wonder why one service shows up twice in the catalog, this is usually the reason.

2. Service plans: where features meet licensing

A service offering is what the service does. A service plan is which variant of it you get, including the features, technical capacity, and licensing terms allocated to a subaccount. Plans are how SAP packages the same service for different needs.

Functional plans

Plans can separate distinct capabilities within one service. SAP HANA Cloud is a good illustration: different plans govern the in-memory database and the relational data lake. Choosing the wrong plan is a common early mistake, so read the plan description before you assign it.

Free tier versus paid plans

Free-tier plans are available inside productive Pay-As-You-Go (PAYG) and Cloud Platform Enterprise Agreement (CPEA) global accounts. They let you test ideas, prototype, and build proofs of concept without upfront cost.

When the prototype earns its place in production, you can update the plan in place to a paid plan. You keep your configuration and avoid re-architecting your data, which makes the free tier a low-risk starting point rather than a throwaway sandbox.

Choosing a commercial model

The two commercial models behave differently:

CPEA gives you a pool of cloud credits that you draw down across eligible services, which suits organizations that want flexibility across a broad portfolio.
PAYG bills for actual consumption, which suits teams that want to start small and scale usage over time.

Both models live at the global account level, which brings us to the account hierarchy.

3. Entitlements and quotas: the bridge between contract and usage

Owning a commercial agreement does not automatically let a project team start building. Between the contract and the running service sits the account hierarchy:

The global account is where your commercial agreement lives.
Directories (optional) help you group subaccounts for governance.
Subaccounts are where services are actually consumed and applications run.

Administrators connect the layers by configuring entitlements. An entitlement assigns a specific service plan, along with a quantitative quota such as memory, database storage, or API calls, to an individual subaccount. If a service or plan does not appear when you try to create an instance, the missing entitlement is the first thing to check.

This structure is also a governance tool. By distributing entitlements deliberately, you control which teams can use which services, and you prevent one development subaccount from quietly consuming the capacity planned for production.

4. How services collaborate in a real architecture

Individual services matter less than the way they combine. In extension and integration scenarios, offerings work together across several architectural tiers:

Architectural tier	Services involved	How they work together
Identity and access	SAP Cloud Identity Services (IAS) and XSUAA	IAS acts as the single sign-on identity provider, or federates to a corporate IdP such as Microsoft Entra ID. The application router and an XSUAA instance enforce role-based access and pass authorization tokens to backend services.
User experience and applications	SAP Build Work Zone with Cloud Foundry or Kyma runtime	Build Work Zone hosts the central launchpad and UI, while the application backend, for example a CAP service, runs in the chosen environment.
Secure connectivity	Destination service, Connectivity service, and Cloud Connector	The app asks the Destination service for target URLs and authentication settings. For private on-premise systems such as SAP S/4HANA, requests flow through the Connectivity service and an outbound-initiated SSL tunnel via the Cloud Connector, with support for user principal propagation.
Process and API orchestration	SAP Integration Suite and Event Mesh	Cloud Integration iFlows transform business documents, API Management exposes governed APIs, and Event Mesh decouples systems through asynchronous business events.
Data and persistence	SAP HANA Cloud and SAP Datasphere	The backend binds to a HANA Cloud instance for fast multi-model storage and SQL. Higher-level reporting connects through Datasphere and SAP Analytics Cloud without duplicating data.
Operations and governance	Cloud Transport Management, Cloud Logging, and SAP Cloud ALM	Transport Management moves artifacts through development, test, and production. Logging and Cloud ALM capture traces, application logs, and audit records.

5. A worked example: a side-by-side extension to S/4HANA

To see the pieces move together, imagine a team building a custom approval app that extends an on-premise SAP S/4HANA system.

Account setup. An administrator assigns entitlements for the Cloud Foundry runtime, XSUAA, Destination, Connectivity, and HANA Cloud to a development subaccount.
Identity. Users sign in through IAS. XSUAA issues the tokens the application uses to enforce roles.
Application. The team builds a CAP service on Cloud Foundry and exposes a Fiori UI through SAP Build Work Zone.
Connectivity. The CAP service looks up its S/4HANA endpoint in the Destination service. The call travels through the Connectivity service and the Cloud Connector, propagating the signed-in user’s identity.
Persistence. Approval data is stored in a bound HANA Cloud instance.
Lifecycle. Cloud Transport Management promotes the solution from development to test to production, while Cloud Logging and Cloud ALM monitor it.

Notice that each step uses a different service, a different plan, and a mix of subscriptions and instances. The platform’s consistent model is what makes this composition manageable.

6. Practical tips for working with offerings and plans

Start with the consumer. Ask whether a human or an application will use the service. That answer usually tells you whether you need a subscription or an instance.
Read plan descriptions carefully. Plans with similar names can differ significantly in features and capacity.
Prototype on the free tier. Use it to validate designs, then upgrade the plan in place when you are ready for production.
Treat entitlements as governance. Plan quotas per subaccount, and revisit them as workloads grow.
Separate environments by subaccount. Keep development, test, and production apart so quotas, access, and transports stay clean.
Check availability before you design. Services and plans vary by region and infrastructure provider, so confirm what is offered in your target region using the SAP Discovery Center.

Conclusion

SAP BTP’s catalog looks complicated mainly because three simple ideas are layered on top of each other. Offerings tell you how a service is delivered: environment, subscription, or instance. Plans tell you which features and commercial terms apply. Entitlements tell you which subaccount may use them, and how much.

Keep those layers straight and you can read almost any BTP architecture diagram, size a project realistically, and choose the right plan the first time. From there, the real craft is in composing services, identity, connectivity, integration, data, and operations, into solutions that are secure, governed, and ready to grow.

Planning your own BTP solution? Start with the free tier, map your entitlements early, and build your architecture one tier at a time.

You might also find the following articles interesting

BTP Service OfferingsKymasap btpSAP BTP architectureSAP BTP Cloud FoundrySAP BTP entitlements and quotasSAP BTP free tier SAP BTP CPEA vs PAYGSAP BTP ServiceSAP BTP service plansSAP BTP subscription vs instance

saptutorials: We are a group of SAP Consultants who want to teach and make studying tough SAP topics easier by providing comprehensive and easy-to-understand learning resources.