Identification of Performance Obligations

Our customer contracts often include various products and services. Typically, the products and services outlined in the Classes of Revenue section qualify as separate performance obligations and the portion of the contractual fee allocated to them is recognized separately. Judgment is required, however, in determining whether a good or service is considered a separate performance obligation. In particular for our professional services and implementation activities, judgment is required to evaluate whether such services significantly integrate, customize, or modify the on-premise software or cloud service to which they relate. In this context, we consider the nature of the services and their volume relative to the volume of the on-premise software or cloud service to which they relate. In general, the implementation services for our cloud services go beyond pure setup activities and qualify as separate performance obligations. Similarly, our on-premise implementation services and our custom development services typically qualify as separate performance obligations. Non-distinct goods and services are combined into one distinct bundle of goods and services (combined performance obligation).

When selling goods or services, we frequently grant customers options to acquire additional goods or services (for example, renewals of renewable offerings, or additional volumes of purchased software). We apply judgment in determining whether such options provide a material right to the customer that the customer would not receive without entering into that contract (material right options). In this judgment, we consider, for example, whether the options entitle the customer to a discount that exceeds the discount granted for the respective goods or services sold together with the option.

Determination of Transaction Price

We apply judgment in determining the amount to which we expect to be entitled in exchange for transferring promised goods or services to a customer. This includes estimates as to whether and to what extent subsequent concessions or payments may be granted to customers and whether the customer is expected to pay the contractual fees. In this judgment, we consider our history both with the respective customer and more broadly.

Our typical cloud services do not provide the customer with a software license because the customer does not have the right to terminate the hosting contract and take possession of the software. Consequently, cloud fees that are based on transaction volumes are considered in the transaction price based on estimates rather than being accounted for as sales-based license royalties.

Only very rarely do our contracts include significant financing components. We do not account for financing components if the period between when SAP transfers the promised goods or services to the customer and when the customer pays for those goods or services is one year or less.

Allocation of Transaction Price

We have established a hierarchy to identify the standalone selling prices (SSPs) that we use to allocate the transaction price of a customer contract to the performance obligations in the contract.

- Where standalone selling prices for an offering are observable and reasonably consistent across customers (that is, not highly variable), our SSP estimates are derived from our respective pricing history. Typically, our standardized support offerings and our professional service offerings follow this approach.

- Where sales prices for an offering are not directly observable or highly variable across customers, we use estimation techniques. For renewable offerings with highly variable pricing, these techniques consider the individual contract’s expected renewal price as far as this price is substantive. Typically, our cloud offerings follow this approach. For non-renewable offerings, these estimations follow a cost-plus-margin approach.

- For offerings that lack renewals, have highly variable pricing, and lack substantial direct costs to estimate based on a cost-plus-margin approach, we allocate the transaction price by applying a residual approach. We use this technique in particular for our standard on-premise software offerings.

Judgment is required when estimating SSPs. To judge whether the historical pricing of our goods and services is highly variable, we have established thresholds of pricing variability. For judging whether contractual renewal prices are substantive, we have established floor prices that we use as SSPs whenever the contractual renewal prices are below these floor prices. In judging whether contracts are expected to renew at their contractual renewal prices, we rely on our respective renewal history. The SSPs of material right options depend on the probability of option exercise. In estimating these probabilities, we apply judgment considering historical exercise patterns.

We review the SSPs periodically or whenever facts and circumstances change to ensure the most objective input parameters available are used.

Recognition of Revenue

Cloud revenue is recognized over time as the services are performed. Where our performance obligation is the grant of a right to continuously access and use a cloud offering for a certain term, revenue is recognized based on time elapsed and thus ratably over this term.

Software revenue is recognized at a point in time or over time depending on whether we deliver standard software, customer-specific software, or software subscription contracts that combine the delivery of software and the obligation to deliver, in the future, unspecified software products: