BTP Account Model: Global Accounts, Subaccounts, and Entitlements
Understand the SAP BTP account hierarchy - global account, directories, subaccounts, and entitlements - and why this structure underpins every integration and extension deployment decision.
Explanation
Every SAP BTP project starts with understanding the account model, because it determines who can deploy what, where, and with which resource limits. At the top sits the global account, created when an organization purchases BTP capacity (via a CPEA, subscription, or enterprise agreement). The global account is the commercial and administrative container for the entire BTP footprint of a customer - it holds the total entitlement of services and quotas the organization has purchased. Below the global account, organizations typically create directories, which are optional grouping structures used to organize subaccounts by business unit, environment (dev/test/prod), or region. Directories can have their own administrators and can optionally inherit or enforce specific entitlements, making them useful for larger enterprises that need delegated administration without giving every team access to the global account. Subaccounts are the actual working units where services are subscribed to, applications are deployed, and integration artifacts live. A subaccount is tied to a specific region (a data center location) and a specific environment technology - Cloud Foundry, Kyma, or ABAP environment can all be enabled within a subaccount depending on what is needed. Most real integration landscapes use multiple subaccounts: for example, separate subaccounts for development, quality assurance, and production of an Integration Suite tenant, allowing independent lifecycle management, separate authorization boundaries, and isolated blast radius if something goes wrong in one environment. Entitlements are the mechanism that controls what services and how much capacity (e.g., number of API calls, memory quota, number of integration flows) a subaccount is allowed to consume. Entitlements are assigned at the global account level from the total purchased quota, then distributed down to directories and subaccounts. If a service like Integration Suite is not entitled to a subaccount, it cannot be subscribed to there even if the global account has purchased it elsewhere - this is a common early-stage confusion for teams new to BTP. A related but distinct concept is the difference between a service plan subscription (multi-tenant SaaS applications like Integration Suite, which you subscribe to) and a service instance (used for application-to-service bindings in Cloud Foundry or Kyma, such as a Destination service instance bound to a custom application). Subscriptions apply at the subaccount level and are typically used for full applications; service instances are created and consumed by developers building custom applications within an environment. From a runtime perspective, when a consultant provisions an Integration Suite tenant, they are subscribing a subaccount to the Integration Suite application, which in turn depends on entitlements for the underlying capabilities (Cloud Integration, API Management, Trading Partner Management, etc., depending on what was purchased). Each of these capabilities may need to be separately enabled/added depending on the commercial package. Understanding this hierarchy matters operationally too: quota exhaustion errors, subscription failures, and 'service not entitled' errors during setup are almost always traceable to a misconfiguration at the global account or directory entitlement level, not a bug in the target service itself. Support and troubleshooting therefore often starts one level up from where the symptom appears. Region selection is also decided at subaccount creation and cannot be changed afterward without recreating the subaccount, so architects must plan for data residency, latency to on-premise systems (via Cloud Connector), and disaster recovery requirements before provisioning.
Real project scenario
A mid-size manufacturing company purchased a BTP CPEA contract and needed to set up Integration Suite for connecting their S/4HANA Cloud system to three third-party logistics providers. The Basis/BTP administrator created a directory named 'Integration-Landscape' under the global account, then created three subaccounts within it: INT-DEV, INT-QA, and INT-PROD, each in the same region as their primary S/4HANA Cloud tenant to minimize latency. Entitlements for Integration Suite, API Management, and a fixed number of Cloud Integration tenant hours were distributed from the global account to each subaccount, with production receiving a larger quota than dev/QA. When the integration team later tried to subscribe INT-QA to Trading Partner Management, the subscription failed with an entitlement error - the administrator had to return to the global account and explicitly assign that specific entitlement to the QA subaccount before the subscription would succeed.
Common mistakes
• Assuming all subaccounts automatically inherit entitlements from the global account without explicit assignment • Creating subaccounts in the wrong region and only discovering data residency or latency issues after production go-live • Confusing a service subscription (SaaS application) with a service instance (used for custom app bindings), leading to wrong provisioning steps • Not planning directory structure early, resulting in a flat, hard-to-govern list of subaccounts as the landscape grows • Granting global account administrator rights to project teams who only need subaccount-level access, violating least-privilege principles
Best practices
• Design the directory and subaccount structure before provisioning anything, aligned to environment (dev/QA/prod) and business unit boundaries • Choose subaccount regions based on data residency requirements and proximity to the systems being integrated • Assign entitlements deliberately and document the rationale, especially for production quotas • Use role collections and least-privilege access at the subaccount level rather than granting broad global account admin rights • Revisit entitlement allocation periodically as usage grows to avoid unplanned quota exhaustion in production
Interview angle
Interviewers commonly ask candidates to explain the difference between a global account, directory, and subaccount, and to describe what an entitlement controls versus what a subscription does. A strong answer distinguishes commercial/quota administration (entitlements, global account) from functional deployment (subscriptions, service instances, subaccounts) and can explain why a 'service not available' error is usually an entitlement issue rather than a technical defect.