SAP Business Technology Platform

What is SAP BTP?

SAP Business Technology Platform (SAP BTP) is SAP’s cloud platform for integration, extensions, process automation, data and AI: the layer that connects SAP and non-SAP systems and carries the logic that does not belong inside a standard application. Spadoom is a Swiss SAP Gold Partner that implements SAP BTP to connect SAP S/4HANA Public Cloud with Sales Cloud V2, Service Cloud V2 and the rest of the CX stack, and operates the interfaces and extensions it builds. Since September 2026 Spadoom is also an SAP PartnerEdge Build partner: our own BTP solutions go through SAP’s review and will be offered in the SAP Store.

In practice, BTP carries three kinds of work: the interface between the ERP and the CX applications, the approval step your process needs and the standard does not have, and the event that must reach three systems in the right order. SAP’s platform documentation is the canonical technical reference, the SAP BTP product page lists the service families, SAP Integration Suite is the service most of our projects start with, and the SAP Discovery Center is SAP’s catalogue of services, plans and reference missions, including the cost estimator we use during scoping.

The rule we hold to: BTP is not the first answer. We check standard functionality, then supported in-app extensibility, and only then a side-by-side extension on BTP. An extension you did not need is a system you now have to operate, patch and hand over. If you want the general introduction first, our blog explains what SAP BTP is and when you need it. This page is about implementation: what we build on BTP, how it is licensed and who runs it afterwards.

Spadoom builds on BTP as part of Cloud ERP and Customer Experience delivery across Switzerland, Germany, Austria and Italy, with one team for the ERP side and the CX side of each interface.

Case study: over a million messages a month at Meier Tobler

Meier Tobler supplies heating, ventilation and sanitary technology across Switzerland. Its ageing SAP PI/PO platform could not deliver reliable real-time data between the online shop and SAP S/4HANA, so prices and stock in the shop were often out of date. We first advised on the purchase and sizing of the SAP Integration Suite licences for their message volume, then implemented SAP Integration Suite as the central integration platform and built the interfaces between shop and ERP.

Today more than a million messages a month run through one monitored platform, prices and stock in the shop are synchronised in real time, and orders flow back into the ERP without manual intervention. The new architecture also prepares the gradual decommissioning of the old PI/PO systems. Read the full Meier Tobler story.

At intelligentfood the BTP work was different in kind: mobile applications for a sales team that works on the road, alongside Sales Cloud V2 and the Cloud ERP integration.

Integration Suite vs Build vs AI: which BTP service does what

“We need BTP” is not a scope. BTP is a catalogue of services, each licensed and operated separately, and most projects need two or three of them, not all. This is how we explain the main ones to customers before anything is ordered.

BTP service	What it does	Typical use in an ERP + CX project	When you do not need it
SAP Integration Suite	Runs interfaces between systems: mappings, routing, retries, API management, event handling and monitoring	Orders, prices, stock and customer master data between S/4HANA, Sales or Service Cloud V2, Commerce and third-party systems	When an SAP-delivered standard integration covers the flow as it is, without extra mapping or monitoring requirements
SAP Build (Build Apps, Build Process Automation, Build Code)	Low-code apps, approval workflows and process automation, plus a development environment for professional code	An approval step the standard lacks, a mobile app for field sales, a side-by-side application on released APIs	When key-user extensibility inside S/4HANA or the CX application solves the requirement
SAP AI Core, Generative AI Hub and Joule	Access to large language models, custom AI scenarios on SAP’s infrastructure and SAP’s AI assistant	A use case that needs authorised business data and a human review step, for example service case triage	When an AI feature already delivered inside the SAP application does the job (see Business AI)
SAP Datasphere and SAP Business Data Cloud	Harmonised data models and data products across SAP and non-SAP sources	Reporting that combines ERP and CX data, such as service margin per customer	When the reporting needs of one application are met by its own analytics (see Business Data Cloud)
SAP Cloud Identity Services	Central user authentication and provisioning across SAP cloud applications	Single sign-on and user provisioning for S/4HANA, CX and BTP apps	Rarely: most SAP cloud landscapes use it already, so the task is configuration rather than a new purchase

The order matters. Integration Suite usually comes first because the ERP and CX applications have to agree on data before anything is automated on top of them. Build follows when a process step is missing. AI comes last, once the data it relies on is correct and somebody owns the review step.

Clean core: when an extension belongs on BTP

Clean core means keeping the ERP close to the standard so that SAP’s releases install without rework. In SAP S/4HANA Cloud there are three places a requirement can be met, and we check them in this order.

1. Key-user extensibility in the system. Custom fields, custom logic in released extension points, adapted forms and screens. No separate platform, no additional operation.
2. Developer extensibility in the system. ABAP Cloud development on released APIs, close to the data, for logic that has to run inside the ERP transaction.
3. Side-by-side on SAP BTP. A separate application or workflow that talks to the ERP only through released APIs and events. It is the right place when the logic serves several systems (ERP and CX at once), when it has its own users outside the ERP, or when it must scale or change on a different rhythm than the core.

A side-by-side extension costs more to run than an in-app one: its own deployment, its own access roles, its own monitoring. We recommend it when one of the reasons above applies, and we write that reason into the architecture decision so the next team can follow it.

Connect. Extend. Automate.

SAP BTP is the base for our extensions. We connect SAP S/4HANA Public Cloud with Sales Cloud, Service Cloud, Commerce, CPQ and FSM. We start with the business process, agree which system owns each record and build the interfaces, applications and monitoring around it.

Three questions settle most interface designs before a line of code is written:

• Who owns the record? A price lives in the ERP, an opportunity in Sales Cloud, a service order in FSM. Every interface copies data from the owner, never in both directions without a rule for conflicts.
• Synchronous or event? A price check during quoting needs an immediate answer. A delivery status can arrive as an event a few seconds later. The choice changes error handling, volume and cost.
• What happens when the target is down? Retries, a dead-letter queue and an alert to a named person, agreed before go-live.

We also build our own products on SAP BTP, including the Engage extensions for Sales and Service Cloud V2: see Built by Spadoom.

From a quote to a job in the field

A salesperson prepares an offer in Sales Cloud and CPQ. The accepted order reaches Cloud ERP, which checks credit, prices and availability. A service requirement creates work for the field team in FSM, and the confirmed hours and material flow back to the ERP for billing. BTP connects the handoffs and carries any extension the process needs, such as an approval for a discount above a threshold. This is an example architecture: the exact interfaces, product scope and licences are checked during assessment. Our transformation overview shows how the ERP and CX pieces fit together end to end.

How SAP BTP is licensed

SAP sells BTP under two commercial models, consumption-based and subscription, and many customers use both at once. This is orientation, not a quote: your actual entitlements depend on your contract. SAP’s training material on SAP BTP commercial models describes them in detail.

• Consumption-based with prepaid cloud credits. Under the SAP BTP Enterprise Agreement (BTPEA) you commit to a prepaid volume of cloud credits for the contract term, and actual usage of eligible services is charged against those credits each month. BTPEA is the model for new contracts; the older Cloud Platform Enterprise Agreement (CPEA) works the same way and continues for existing CPEA accounts. The two service lists are not identical.
• Pay-As-You-Go. No upfront commitment; you are invoiced monthly in arrears for what you use. SAP positions it for small applications, proofs of concept and pilots.
• Subscription. A fixed price for a specific service and plan over a fixed term, regardless of consumption. Suited to services with predictable usage.
• Free tier. Many services offer free plans with usage limits, which are enough to prototype a flow before anything is ordered.

RISE with SAP and GROW with SAP also contain BTP: SAP lists BTP cloud credits as part of RISE, and both GROW editions include BTP Enterprise Agreement credits and entitlements to SAP Build functionality. Whether those credits cover your planned integrations depends on volume and on which services you use.

What we check before scoping, so that licensing does not surprise you after go-live:

• Existing entitlements. Which BTP services, plans and credits your current contract (including RISE or GROW) already contains.
• Services and plans the flow needs. Integration Suite, a Build service, an AI service or none of them, and in which plan.
• A consumption estimate. Expected message volume and connections, calculated with the estimator in the SAP Discovery Center and documented with its assumptions. At Meier Tobler this sizing was the first deliverable, before any interface was built.
• Who watches consumption. Credits are consumed monthly; somebody on your side or ours reviews usage in the BTP cockpit and gets an alert before the budget runs out.

What it costs to run, after the build

The question that decides a BTP business case is rarely the build. It is who watches the interfaces at month-end, what the service entitlements actually cover under your contract, and what happens when a target system is unavailable at 2am. We put access roles, logging, deployment and alerting in scope from the start, and we agree the acceptance tests before implementation rather than after.

After go-live there are two options, and we agree which one before the build starts. Either your IT team takes over with documentation, runbooks and a handover of every alert, or Spadoom operates the interfaces and extensions under a support agreement: we monitor message processing, analyse failed messages, test SAP’s quarterly releases against the interfaces and report consumption. In both cases each interface has a named owner and a documented recovery path.

Start with one flow. Build it properly.

Bring a workflow that still depends on copying data or chasing an email. In a fixed-price assessment we map its systems, data owners and exceptions, check your existing BTP entitlements and estimate consumption. You receive a proposed architecture, delivery scope and cost basis. Monitoring and handover are part of the scope, not a change request afterwards.

If you still run SAP PI/PO, the same assessment can start with your interface inventory: which flows move to Integration Suite as they are, which are redesigned and which can be retired.

Discuss your integration or read how the ERP and CX sides fit together.