Designing a clear, scalable account structure is one of the most important foundational decisions you’ll make when working with SAP Business Technology Platform (SAP BTP).
The way you organize global accounts, directories, and subaccounts directly affects governance, security, cost transparency, development workflows, and long-term scalability. In this post, we’ll walk through SAP’s recommended account models and explain how global accounts, directories, and subaccounts work together.
The hierarchical structure between global accounts, directories, and subaccounts allows you to define an account model that precisely matches your business and development requirements. Once you have signed your contract with SAP, you will receive the access data for your global account. This global account is the implementation of your commercial contract with SAP; you will use it to manage the resources and authorizations for your development projects. You will also receive one invoice for all consumed resources per global account.
To develop and deploy applications, consume services, and subscribe to applications provided by SAP, you need to create subaccounts. You can create any number of subaccounts in any environment and region. For example, if you are based in Germany, you can create subaccounts in different regions, such as Europe, the United States, or Japan, to support the customers who use your applications. Subaccounts are independent of each other, which means that each subaccount enables its own entitlement and user management. You can configure a separate identity provider for end users for each subaccount. If you have many subaccounts, you can use directories, which group subaccounts and/or further subdirectories, to keep track of them and make administration easier. You can use directories to manage permissions or users for entire groups of subaccounts. You can also use directories to distribute the resources assigned to the global account to its subordinate subaccounts.
SAP recommends building an account structure that can be easily scaled as your organization grows or additional projects are added. That is, you should start with only subaccounts and add directories to group these subaccounts as needed.
How many subaccounts and directories you create and for what purpose depends on your organizational structure and your use case. In general, SAP recommends using subaccounts for a multilevel development process in which you distinguish among a subaccount for development, one for testing, and one for production.
The development subaccount is intended for development purposes and for testing individual increments in the cloud. The test subaccount can be used to carry out integration tests and tests in a production-like environment before they are made publicly available, to ensure quality. In companies where DevOps is highly developed, this subaccount is also used for production applications as the tests take place in the development subaccount. You create the production subaccount for production applications.
Other typical reasons for creating subaccounts include the following:
When creating different subaccounts, keep the following considerations in mind:
Although creating a multistage development environment is a good idea in any case, there are some Cloud Foundry–specific considerations that you should keep in mind.
You can use both subaccounts and spaces to develop applications and use services. You therefore need to decide whether you will create different subaccounts or spaces within a subaccount, for example, to set up a multistage development environment.
Think of a subaccount as a tenant: Data access and data visibility are separated at the subaccount level, not at the application or Cloud Foundry space level. Remember that services used by every application within a subaccount collect messages from all those services. If you do not want these to be visible across applications, then you need to create different subaccounts.
In general, we recommend creating different subaccounts for a multitier development environment. This allows for dedicated user management between the different tiers, as well as dedicated data management. You can then create a separate scope for each application, extension, solution, or any other project within these subaccounts if you don't need separate user management for these applications and projects. You can only monitor the consumption of resources in your global account for each subaccount, directory, or Cloud Foundry space, not per application. To monitor the resources consumed by a specific project, department, or application, create a dedicated subaccount, directory, or space for it. Exact billing is only possible for global accounts. For the usage-based model, you can calculate the costs after use, but bear in mind that this is only an approximation.
As mentioned earlier, SAP presents the account model with subaccounts and the account model with directories and subaccounts as best practice in the SAP BTP documentation.
With a separate account landscape for each functional area, you can use multiple instances of the same SaaS subscription (e.g., in case you need to keep data or user access separate). You can see these account landscapes in the figure below for the HR and sales areas.
For example, an internal identity provider would be used for HR subaccounts, while an external identity provider could be used for public or external scenarios. This account model allows you to distribute the administration of the subaccounts across several teams, which makes it easy to scale as the number of cloud projects grows, while keeping maintenance and governance manageable. If possible, you should assign a colleague to be responsible for each group of three subaccounts—that is, each account landscape. An SaaS application can only be used once within a subaccount. So if each functional area has its own subaccount (for development, test, and production), you will not encounter any restrictions when using the same SaaS offering in different projects. In the Cloud Foundry environment, however, you can divide different projects into different areas within a subaccount. This model can easily be expanded later to use directories as additional structuring elements.
Not only can you structure your global account into multiple subaccounts, you can also combine individual subaccounts into directories in order to manage, operate, and analyze these groups of subaccounts together. A global account can contain up to five levels of directories, each of which can contain a subaccount. The following are some possible reasons for creating directories to make managing your subaccounts easier:
These approaches can be categorized into three distinct models based on functional areas, geographic regions, and subsidiaries, as outlined ahead.
In this account model, each functional area uses its own directory. Within each of these directories, three subaccounts (for development, test, and production) are created (see figure below). For each directory, the functional area can use its own identity provider and manage its permissions. In addition, you can use labels—for example, to denote the person responsible, the cost center, or other aspects that you need for later reports.
In this account model, you create a directory for each geographic area. In the figure below, we show this using the example of the Europe, Middle East, and Africa (EMEA) region, and the Americas (AMER) region. There could possibly be a further distinction between North and South America. In addition, there is the Asia Pacific and Japan (APJ) region. You can also use labels at this point to describe the subaccounts in more detail.
In this account model, you create a directory for each subsidiary of your company (see below). Again, you can use labels to add information about cost centers or responsible persons, for example.
A well-designed SAP BTP account model provides far more than administrative order—it enables secure development, clean separation of responsibilities, predictable scaling, and meaningful cost control. By thoughtfully combining global accounts, subaccounts, and directories, you can create a structure that supports your development lifecycle, regional needs, functional areas, and regulatory constraints without unnecessary complexity.
SAP’s best-practice models, whether based on functional areas, geographic regions, or subsidiaries, offer flexible starting points that can evolve as your organization grows. The key is to begin with a simple subaccount structure, expand with directories only when needed, and always align technical boundaries with real business and operational requirements. With the right foundation in place, SAP BTP becomes significantly easier to manage, govern, and scale over time.
Editor’s note: This post has been adapted from a section of the book Configuring SAP Business Technology Platform: The Practical Guide for Administrators by Martin Koch and Siegfried Zeilinger. Martin is the managing director of CloudDNA GmbH, an SAP partner in Austria. Siegfried is a freelancer and managing director of a small management consultancy.
This post was originally published 12/2025.