BTP is not an end in itself.
Learn moreShow less
Putting an extension on BTP just because it is modern does not make it better. If the logic is closely tied to the standard process, it often belongs in the system. We decide based on maintainability.
The SAP Business Technology Platform, BTP for short, is SAP’s cloud platform. It runs extensions, interfaces and applications that do not belong in the S/4HANA system itself.
Two areas are particularly important for logistics. Integration is used to connect third-party systems, partners and machines to SAP. Application development is where custom apps and extensions are created, using SAP’s current programming models.
On top of this come tools for workflows, data analysis and AI. SAP’s own products also use the platform. SAP Logistics Management, for example, itself runs on BTP.

Not every extension belongs on BTP. Small adjustments often work better directly in the S/4HANA system, using the extension options SAP provides there. BTP plays to its strengths when several systems come together or an extension is to live independently of the ERP.
Yes. Using the Integration Suite, we connect SAP with transport service providers, customs systems, supplier portals or a third-party ERP. Every interface gets monitoring and restart capability.
Yes. Fiori apps and custom applications run on BTP and access S/4HANA via interfaces. For backend logic, we use CAP or ABAP in the cloud.
Yes. With SAP Build Process Automation, approvals, follow-up postings and status messages become workflows, without a large development project. For processes beyond SAP, we also use n8n.
Yes. Language models and machine learning can be connected to SAP data via BTP, for example to read delivery notes or classify faults. In the end, a person approves the result.
Yes, as a platform for data from equipment and sensors. In production, this usually runs via SAP Digital Manufacturing. More on this on the production logistics page.
Clean core is SAP’s guiding principle of keeping the core of the ERP system free of custom developments that cause rework with every release. Since 2025, SAP has classified extensions into four levels for this purpose: level A uses only released interfaces and is considered upgrade-safe, level D intervenes deeply in the standard.
In many systems, hundreds of custom developments have grown over the years. Some are no longer used, others have long been replaced by a standard function. This becomes apparent during an S/4 conversion or a release change, and then it gets expensive.
We assess existing extensions and decide case by case: standard, extension in the system or on BTP. In addition, IT receives a rule with which it can classify new requirements itself. This keeps the system maintainable, even when we are no longer on the project.
Putting an extension on BTP just because it is modern does not make it better. If the logic is closely tied to the standard process, it often belongs in the system. We decide based on maintainability.
“For an additional field on the delivery note, I get a quote for three consultant days.” That happens when nobody in-house understands how an extension is built. We document every extension so that someone will still understand it in five years’ time.
AI projects usually lack two things: clean data and clear responsibilities. With us, every AI solution gets a defined use case and a person who approves the result.
We build on BTP what belongs there and help IT to make this decision itself in future.
Extension strategy and clean core, assessment of existing custom developments
Backend extensions with RAP and CAP, Fiori and UI5 apps on BTP
Interfaces to third-party systems, partners and service providers with monitoring and restart capability
Workflows with SAP Build Process Automation and n8n, AI integration, AI enablement for SAP teams
Support after go-live, further development of existing extensions, spot consulting with root cause analysis
Not necessarily. S/4HANA runs without BTP. As soon as third-party systems are to be connected or extensions kept out of the core, it becomes interesting.
The core of the ERP system stays as close to the standard as possible. Extensions use released interfaces or run outside, for example on BTP. As a result, releases go through with less rework.
We assess them individually. Some are dropped because the standard now covers them. Others are rebuilt; a few remain as they are.
SAP offers various licensing models, depending on the services used. We clarify which services a company really needs before the licensing question.
Both are current SAP programming models. RAP is based on ABAP and is suited to extensions close to the S/4HANA system. CAP uses Java or JavaScript and suits standalone applications on BTP.
