What Is the SAP BTP Cockpit? Navigation, Configuration, and Cost Management

The SAP BTP Cockpit is the browser-based administration interface of the SAP Business Technology Platform. You use it to manage global accounts, directories, subaccounts, entitlements, users and costs. If you are responsible for a BTP landscape, this is where most of your admin work happens, and the structure you choose in the first weeks is the one you live with for years. As an SAP BTP partner in Switzerland, we use the platform to connect S/4HANA Public Cloud with Sales and Service Cloud V2 and to keep extensions out of the core.

This guide walks through how the cockpit is organised, what each area does and the configuration patterns that prevent the mistakes we see most often in BTP projects.

TL;DR: The SAP BTP Cockpit is the web interface for administering SAP BTP. Its hierarchy is global account, optional directories and subaccounts; Cloud Foundry orgs and spaces live inside a subaccount’s environment. Three things decide whether it stays manageable: a naming convention and directory structure from day one, trust to your corporate identity provider with narrow role collections, and a monthly review of entitlements and consumption. For repetitive work, the btp CLI does the same jobs as a script.

What is the BTP Cockpit and how is it structured?

The cockpit mirrors the account model of SAP BTP. If you are new to the platform itself, start with what SAP BTP is and where it fits; this post assumes you already have an account.

Global account. The top level, representing your SAP contract. Entitlements, usage data and members of the global account are managed here. You reach it at cockpit.btp.cloud.sap, which forwards you to your regional cockpit (for Europe, emea.cockpit.btp.cloud.sap). SAP describes the logon in the BTP documentation.

Directories. An optional grouping layer for subaccounts, by business unit, project or region. Directories become useful from roughly half a dozen subaccounts onwards. Without them, the account explorer turns into a long, flat list.

Subaccounts. The working unit. Each subaccount has its own region, its own entitlements and user assignments, and one or more runtime environments: Cloud Foundry, Kyma or ABAP. Most companies create separate subaccounts for development, test and production.

Inside the environment. In a Cloud Foundry subaccount, the org is divided into spaces, which isolate applications or teams. Spaces are not a fourth level of the cockpit hierarchy; they belong to the Cloud Foundry environment of one subaccount.

The hierarchy is hard to change later: moving applications and service instances between subaccounts means redeploying and reconfiguring them. It pays to agree on the structure before the first project starts.

How do you navigate the account explorer?

When you open a global account, the account explorer is the first view. It shows directories and subaccounts with their status. From here you can:

• Create and delete subaccounts, choosing region, environment and description
• Organise subaccounts into directories
• View subaccount details: region, infrastructure provider (AWS, Azure or Google Cloud), subdomain and tenant ID
• See which subaccounts are active, being provisioned or suspended

The side navigation depends on where you are. At global account level you see entitlements, usage and cost information and the members of the account. Inside a subaccount you get the environment (Cloud Foundry or Kyma), service marketplace, instances and subscriptions, and the subaccount’s own security settings.

The most common problem we find in existing landscapes is not a technical one: subaccounts without a naming convention. Once there are ten of them called “test”, “dev2” and “project-x”, nobody knows what runs where. A convention such as {project}-{env}-{region} costs nothing on day one and saves a lot of detective work later.

How do entitlements and the service marketplace work?

Entitlements control which services and plans a subaccount may use, and how much. Your global account holds a pool of entitlements based on your contract, and you distribute that pool to subaccounts, much like a budget.

Patterns that work:

• Service plans: most services offer several plans. Use the smallest suitable plan for development and test, and the production-grade plan only where it is needed.
• Quotas: some plans have numeric quotas, for example Cloud Foundry runtime memory. Keep an eye on them so a deployment does not fail on a limit.
• Automatic assignment: directories can assign entitlements automatically to new subaccounts, which saves manual setup for every new environment.

The service marketplace is the catalogue inside a subaccount. It lists the services your entitlements allow and lets you create instances or subscriptions. Typical entries are SAP HANA Cloud, SAP Integration Suite, SAP Build, the Destination and Connectivity services, and Authorization and Trust Management (XSUAA). How these services fit together is covered in the five pillars of SAP BTP.

How do you manage security and user access?

Security is the part of the cockpit that is most often set up in a hurry and then left alone. It works on two levels, both documented in SAP’s security administration guide.

Trust configuration. Connects an identity provider to BTP. The default is the SAP ID service. For anything beyond a first trial, SAP’s recommended pattern is to connect SAP Cloud Identity Services (Identity Authentication) and let it proxy your corporate identity provider, such as Microsoft Entra ID or Okta. That gives you single sign-on and one place for the user lifecycle.

Role collections. Groups of roles that you assign to users or to groups from the identity provider. BTP ships predefined role collections such as Subaccount Administrator, and you can create your own. The pattern that holds up: role collections that match team roles, not one-off permissions for individual people.

Mistakes we see regularly:

• Everyone gets Subaccount Administrator instead of a limited role collection, which makes audits and incident analysis much harder.
• Production runs on the default SAP ID service instead of the corporate identity provider.
• Trust is configured in one subaccount and assumed to apply everywhere. Trust configuration is set per subaccount, so each one needs its own.

How do you monitor costs in the cockpit?

At global account level, the cockpit shows usage and costs across the account. SAP explains the views in monitoring usage and consumption costs. You can see:

• Consumption against your contract, for example cloud credits
• A breakdown per service and per subaccount
• The trend over time; the data is updated daily, not in real time

Practical patterns:

1. Review monthly. A fixed monthly review catches trends before they become budget problems.
2. Investigate jumps. A useful rule of thumb: if a service’s cost rises by around a fifth or more from one month to the next, find out why. Typical causes are forgotten test instances, an oversized SAP HANA Cloud instance or development environments that nobody switched off.
3. Right-size environments. Development and test rarely need production-grade plans.
4. Clean up unused services. Instances nobody uses still hold quota and may cost money. A quarterly audit is enough for most landscapes.

What is the difference between the cockpit and the btp CLI?

The cockpit is the graphical interface: good for exploring, one-off configuration and visual cost monitoring. The btp CLI (btp command) covers the same account administration from the command line; SAP maintains a full command reference.

Task	Cockpit	btp CLI
Initial setup and exploration	Best choice	Steeper learning curve
Repetitive configuration	Slow, many clicks	Script once, run many times
CI/CD pipelines	Not suitable	Designed for it
Cost monitoring	Visual views	Output for your own reporting
User and role management	Easiest for small teams	Better for bulk changes
Traceability	Limited	Scripts can be versioned and reviewed

For most teams it is both: the cockpit for monitoring and occasional tasks, the CLI for anything repeated or automated. In our own BTP projects we script subaccount setup and entitlements from the start, because the second and third environment then take minutes instead of an afternoon of clicking.

Who should run your BTP landscape?

The cockpit is only the admin surface; what matters is the landscape behind it: the extensions, integrations and data flows between your ERP and your CX applications. At Spadoom, one team runs S/4HANA Public Cloud, the SAP CX applications and the BTP layer between them, which is why we set up account structure, trust and cost control as part of the architecture, not afterwards. Why that matters is explained in choosing one partner for Cloud ERP and CRM, and how BTP development partners in Switzerland compare is in our overview of SAP BTP development partners.

If your cockpit has grown faster than its structure, talk to us: a review of hierarchy, trust and entitlements is usually a matter of days.

FAQ

How do I access the SAP BTP Cockpit?

Open cockpit.btp.cloud.sap and sign in; it forwards you to the regional cockpit, for example emea.cockpit.btp.cloud.sap for Europe. You then see every global account you are a member of. Users without global account membership do not see this selection.

Can I manage multiple environments from one cockpit?

Yes. Each subaccount can enable Cloud Foundry, Kyma or the ABAP environment, and the cockpit manages all of them. The navigation adapts to the environment of the subaccount you open, so a Cloud Foundry subaccount shows orgs and spaces, a Kyma subaccount shows the Kyma dashboard.

How often does usage data update?

Usage and cost data in the global account is updated daily, so it is not a real-time view. For the live state of a deployment, check the service instances and applications in the subaccount itself.

What happens if I run out of entitlements?

You cannot create further service instances for that plan until you free quota (for example by deleting unused instances or moving quota between subaccounts) or buy additional capacity from SAP. Quota is assigned per subaccount, so check the distribution before you order more.

Should I use the SAP ID service or our own identity provider?

The SAP ID service is the default and is fine for a first setup or a personal trial. For shared development, test and production subaccounts, connect SAP Cloud Identity Services (Identity Authentication) and let it proxy your corporate identity provider, such as Microsoft Entra ID or Okta. That gives you single sign-on and one place to manage the user lifecycle.