An extension belongs on the platform that owns the record it changes. That’s the short answer to most SAP BTP vs Salesforce decisions. If the logic changes how an order is priced or posted in S/4HANA, SAP BTP should own it. If it changes how a customer is sold to or served, the Salesforce Platform should own it. Most real projects touch both systems, so the harder question is which side owns the logic and which side only gets called.
B2B SaaS companies and enterprise IT teams run into this all the time. Sales works in Salesforce while finance and operations work in SAP, and new requirements rarely respect that line. Pick the wrong home and you pay twice: once to build the extension, and again when an upgrade or a license renewal forces a rebuild. This guide gives you a placement rule and tests it against the hard cases, including AI agents and shared data. It also shows how each platform’s pricing can settle a close call.
TL;DR
- Most SAP BTP vs Salesforce decisions come down to 1 rule: put an extension on the platform that owns the record it writes. ERP logic belongs on SAP BTP, and customer-facing logic belongs on the Salesforce Platform.
- SAP’s clean core Level A supports 2 upgrade-safe paths for new ERP extensions: side-by-side extensions on BTP and on-stack ABAP Cloud extensions that use released APIs.
- For processes that span both systems, one side owns the logic and the other side gets called through APIs or events.
- Open protocols define how SAP and third-party agents can interoperate, but direct third-party delegation through SAP Agent Gateway isn’t yet generally available.
- Model both cost meters before you decide. BTP draws down prepaid credits, while Agentforce bills about $0.10 per action.
What SAP BTP is and what it’s built to extend
SAP Business Technology Platform (BTP) is SAP’s cloud platform for building apps and integrations around SAP systems. Its main job is to extend S/4HANA and other SAP applications without changing their code. Developers can work in low-code tools through SAP Build or write code with ABAP Cloud and the Cloud Application Programming Model, deployed on Cloud Foundry or Kyma.
An SAP BTP extension is strongest when it needs to read and write SAP business objects through released APIs. That’s the first clue in any SAP BTP vs Salesforce placement question. Typical examples include extra validation on sales orders, custom approval steps in procurement, supply chain alerts and finance workflows that react to posting events. These extensions inherit SAP’s data model and authorization concepts, so they stay close to the records they change.
BTP is weaker as a front end for people who spend their day in another system. A sales rep who works in Salesforce won’t want to switch to a separate SAP app to see order status. In those cases, BTP should still own the ERP logic, but the screen the user sees can live elsewhere and call BTP behind the scenes.
BTP also carries the integration and data services that connect SAP to everything else. SAP Integration Suite handles APIs and message flows, and SAP Business Data Cloud handles data sharing for analytics. Those services matter later in this guide, because they decide how cleanly SAP and Salesforce can talk to each other.
What the Salesforce Platform is and what it’s built to extend
The Salesforce Platform is the development layer under Salesforce’s CRM products, including Sales Cloud and Service Cloud. Teams automate with Flow and write code in Apex. User interfaces are built with Lightning Web Components. Because custom apps share the same metadata and security model as the CRM, they can use accounts, contacts, opportunities and cases directly.
In the SAP BTP vs Salesforce split, the Salesforce Platform is strongest for workflows that start with a customer interaction. Quote approvals, service case routing, partner portals and field sales apps all fit naturally here. The people running those processes already work in Salesforce, and its record-level sharing model controls who sees which customer.
Salesforce has also widened the platform for builders. Its Agentforce 360 announcement for ISVs gave partners access to the same AI and data foundation that powers Salesforce’s own apps. For B2B SaaS companies that sell into Salesforce customers, that makes the platform a stronger place for agent-driven features than it was a year ago.
B2B SaaS vendors whose customers run both systems face a packaging question too. The Salesforce side of a product usually ships as a managed package that customers install in their org. The SAP side usually runs as an app on BTP that calls the customer’s S/4HANA system. Keeping each piece on its own platform lets each vendor’s review and upgrade process work as designed.
The platform’s weak spot is ERP data. Salesforce can display order history or credit limits, but it isn’t the system of record for them. Copying ERP master data into Salesforce objects creates a second version that has to be kept in sync, and every sync job is another thing that can break during an upgrade.
SAP BTP vs. Salesforce Platform at a glance
The clearest difference in any SAP BTP vs Salesforce comparison is the data each platform sits next to. The table compares the 2 platforms on the points that affect extension placement.
| Factor | SAP BTP | Salesforce Platform |
| Core job | Extending SAP ERP and other SAP apps | Extending CRM and building front-office apps |
| Data it sits next to | Orders, materials, finance and supply chain records | Accounts, contacts, opportunities and cases |
| Main build tools | SAP Build for low code, ABAP Cloud or CAP for pro code | Flow for low code, Apex and Lightning Web Components for pro code |
| Agent layer | Joule and Joule Studio | Agentforce |
| Data sharing | SAP Business Data Cloud | Data 360 with zero copy |
| Integration tooling | SAP Integration Suite | MuleSoft and platform APIs |
| Pricing model | Prepaid credits or pay-as-you-go | Per-user licenses plus Flex Credits for agents |
Read the table by row, and the split becomes clear. Each platform is built around a different set of records, and each vendor’s tools assume those records live nearby. An extension placed on the far side of its data spends most of its effort moving that data across, which is where cost and fragility build up.
The ownership rule: follow the system of record
The rule is simple to state: the platform that holds the record an extension writes should own that extension. Reading data across systems is normal and expected. Writing business records from the wrong side is what creates duplicate logic and sync failures.
Use these questions to apply the rule to any request:
1. Which system holds the record the extension creates or changes?
2. Where do the people who run the process work most of the day?
3. Which vendor’s release cycle could break the extension?
4. Which system must enforce the authorization rules for the data?
When all 4 answers point the same way, the decision is easy. When they split, the system-of-record question should usually carry the most weight. A user can see SAP data inside Salesforce through a call or an embedded view, but the write should still happen in the system that owns the record.
Take a credit check during a sales deal. The sales rep works in Salesforce and needs the answer on the opportunity. The credit limit and exposure live in SAP. The right split puts the credit logic in an SAP BTP extension and the screen in Salesforce, which calls BTP and shows the result. Nobody copies credit rules into Apex, so finance still controls them in 1 place.
A discount request shows the other side. If the discount only affects a quote that hasn’t become an order, the approval belongs in Salesforce. If the approved discount must change an SAP pricing condition, the write to SAP belongs on BTP, and Salesforce only sends the approved request.
Ownership also decides who supports the extension. The team that owns the platform gets the support tickets and handles upgrade testing. If that team can’t explain the business rules inside the extension, it’s sitting on the wrong platform, whatever the architecture diagram says.
Why SAP’s clean core rules push ERP extensions to BTP
SAP’s clean core strategy is the main reason ERP extensions land on the BTP side of the SAP BTP vs Salesforce line. SAP tells customers moving to S/4HANA to keep the ERP core free of modifications and to build extensions through released APIs. Custom code inside the core makes every upgrade harder, while extensions that use stable interfaces survive upgrades with far less testing.
SAP made the model more precise in 2025. Its clean core levels sort extensions into 4 levels, A through D, based on how upgrade-safe they are. Level A covers side-by-side extensions on BTP and apps built with SAP Build. It also covers on-stack ABAP Cloud development that uses only released APIs. Levels B to D rate classic ABAP, from well-built code that still counts as clean down to code with clear violations. The new model replaced the older 3-tier framework.
The details sit in SAP’s extensibility white paper, which also covers governance and measurement. SAP tracks adoption through its RISE methodology dashboard, so many customers now report that score to management. That creates pressure to keep new work at Level A.
In S/4HANA Cloud public edition, the choice is already made for you. Its multi-tenant design doesn’t allow core modifications, so substantial custom logic has to run as a side-by-side extension or through on-stack ABAP Cloud. Private edition and on-premise customers have more freedom, but the same upgrade logic applies.
SAP’s model also affects Salesforce decisions, even though Salesforce isn’t part of SAP’s scoring. If a team rebuilds SAP pricing or availability logic in Apex to avoid touching SAP, the core looks clean while the business rules drift apart. That’s technical debt outside SAP’s view, and it usually shows up later as mismatched prices between a quote and an invoice.
Customers still on ECC face a different timeline. SAP reversed course in May 2026 and said it would bring some AI features to ECC and on-premise S/4HANA, according to The Register’s report on SAP’s U-turn at the time. ECC teams can still build an SAP BTP extension that calls ECC, and that work will carry forward more cleanly into an S/4HANA move later.
When the Salesforce Platform should own the extension
The Salesforce Platform should own extensions where the customer relationship is the record being changed. This is the other half of the SAP BTP vs Salesforce split. Opportunity stages, quote approvals, case escalations, account plans and partner deal registrations all live in Salesforce. Building those flows anywhere else forces users to leave the system they work in.
Customer-facing B2B SaaS features also belong here. If your product sells into Salesforce customers, the agent actions on customer records and the data your customers’ admins control both sit on the Salesforce side. ERP data can feed those features without moving the ERP logic into Salesforce.
The platform has good options for showing SAP data without copying it. Salesforce Connect, a paid add-on, can display external records as if they were Salesforce objects. Callouts from Flow or Apex can fetch a credit status or an order total on demand. Platform Events let Salesforce publish or receive business events, which suits handoffs such as “quote accepted” or “order shipped.”
There’s 1 clear warning sign that an extension is on the wrong platform. If the Salesforce build needs its own copy of ERP rules, such as pricing conditions or stock allocation, the logic belongs in SAP. Keep the Salesforce side focused on the customer process, and ask SAP for answers instead of recalculating them.
Extensions that span both systems
Most valuable extensions touch both platforms, which is where SAP BTP vs Salesforce debates get heated. The rule still applies, but you need to split the work at the right handoff point and agree on how the 2 sides communicate. That handoff design is the heart of any SAP Salesforce integration.
Quote-to-cash
Quote-to-cash is the most common shared process. The opportunity and quote, including its approval, live in Salesforce. The order, delivery, invoice and revenue recognition live in SAP. The natural handoff is the moment a quote becomes an order.
Before that point, Salesforce owns the process and can call SAP for prices or credit status. After it, an SAP BTP extension should own order validation and enrichment, and Salesforce should receive status updates. Teams that move order creation logic into Salesforce usually end up rebuilding SAP validation rules, which defeats the purpose.
Cross-system approvals
Approvals that involve both teams follow the same rule. The approval belongs to the system whose record changes when it’s approved. A sales discount on a quote is a Salesforce approval. A credit limit increase is an SAP approval, even if the request starts from a Salesforce screen. Where 1 approval changes records on both sides, split it into 2 linked steps, each owned by its own system.
Customer and account master data
Customer master data is the shared record that causes the most arguments. SAP holds the business partner used for orders and billing. Salesforce holds the account used for selling and service. Neither side should own every field. A practical split gives SAP ownership of legal names, tax IDs, payment terms and billing addresses, and gives Salesforce ownership of sales territory and account team fields. Each field then flows 1 way only, which removes most sync conflicts. Write the field-level ownership into your SAP Salesforce integration design before the first sync job runs.
Choosing the integration backbone
Every SAP Salesforce integration needs a backbone that carries APIs and events between the 2 systems. Most companies choose SAP Integration Suite or MuleSoft, and running both for the same flows adds duplicate monitoring and support overhead. Pick 1 backbone for cross-system traffic, based on which side has more endpoints and where your integration team’s skills sit.
Prefer events for handoffs and APIs for questions. An event such as “order created” lets each side react in its own time, while a synchronous API call fits a question that needs an answer on screen. Mixing the 2 patterns without a plan is a common cause of duplicate records.
AI agents: who owns the logic when Joule and Agentforce meet
AI agents have made the SAP BTP vs Salesforce ownership question harder, because an agent can read and act across both systems in a single conversation. The placement rule still holds. The agent should live where the conversation happens, and any write should go to the system that owns the record.
The protocols that let agents cross between vendors now exist. At its Sapphire conference in May 2026, SAP announced that agents built in Joule Studio would support the Model Context Protocol and the A2A protocol natively, according to The Register’s Sapphire coverage of the launch. That means Joule agents can work with tools and agents from other vendors, including Salesforce.
The connection runs in the other direction too, but the direct Agent Gateway path is still an intended architecture rather than a generally available production capability. SAP’s current architecture guidance describes an Agent Gateway designed to expose Joule agents to outside systems through A2A. As of August 27, 2026, SAP says bidirectional communication with third-party and self-hosted agents through Agent Gateway is not yet supported. In the intended design, an Agentforce agent could hand an SAP task to a Joule agent instead of calling raw APIs.
SAP also set rules for that traffic. Its API policy document, published in April 2026, defines Agent Gateway using A2A as an intended governed route for agentic traffic, alongside MCP through Integration Suite and Joule Studio. Because bidirectional third-party communication through Agent Gateway is not yet generally available, production designs should use capabilities that are currently supported. SAP also says the policy adds no new pricing for access through those endorsed paths.
Not everyone reads the policy that way. A Gartner analyst quoted by The Register saw it as SAP channeling how third-party AI platforms reach its systems, and suggested that could bring extra charges. SAP user groups raised similar concerns, and The Register reported on the user group criticism of the policy’s uncertainty. Forrester’s view was that the technical side is solved, while questions about runtime costs and audit trail ownership are still open.
For extension owners, the takeaway is practical, and it treats agents as another form of SAP Salesforce integration. Build customer-facing agents on Agentforce when the conversation starts in Salesforce. For SAP actions, use currently supported SAP integration paths and treat direct third-party delegation to Joule through Agent Gateway as an intended architecture until bidirectional support reaches general availability. Record which platform owns each step of the audit trail.
Data and analytics extensions: zero copy and the lakehouse option
Data and analytics extensions follow a different rule from the rest of the SAP BTP vs Salesforce decision. When a report or model needs ERP and CRM data together, the best owner is often neither application platform. A shared data layer avoids copying records between SAP and Salesforce only to answer questions.
Salesforce’s answer is Data 360, formerly Data Cloud. Its zero copy works in both directions, so data in external lakes can be used as if it were stored in Data 360, and Salesforce apps can use it without storing it again. The Trailhead module on Data 360 zero copy covers how admins set up those bidirectional links.
SAP’s answer is Business Data Cloud, which began with a Databricks partnership. SAP has since widened its reach with acquisitions, including lakehouse vendor Dremio, as described in The Register’s Dremio acquisition report from May 2026. It also bought metadata company Reltio.
Public material doesn’t show a direct zero-copy link between SAP Business Data Cloud and Salesforce Data 360. Both connect to Snowflake, though. Snowflake’s zero-copy integrations page lists its SAP connection as generally available, and says its Salesforce connection has been available for over 2 years. For many companies, a shared lakehouse is the practical meeting point for SAP Salesforce integration on the analytics side.
Governance matters as much as the plumbing. Decide which team owns the shared data products and how access rules carry over from SAP and Salesforce. Without that, a lakehouse turns into a third system of record that nobody controls.
The ownership rule for analytics is therefore simple. Operational extensions stay with the system of record, and reporting that joins both systems belongs in the shared data layer. Don’t build a Salesforce dashboard on copied ERP tables, and don’t rebuild CRM pipeline logic inside SAP analytics.
How licensing and consumption costs change the answer
Cost rarely decides an SAP BTP vs Salesforce question on its own, but it often settles a close call. The 2 platforms charge for extensions in very different ways, so the same feature can cost much more on 1 side.
SAP BTP runs on a consumption model. Under an SAP BTP Enterprise Agreement, customers receive credits over the contract that are used up as services run, according to SAP’s BTP pricing page. Usage beyond the available credits is invoiced monthly at list price. Pay-as-you-go accounts are billed a month in arrears for what they used. Licensing advisers also report that unused credits typically expire at the end of each period and that RISE contracts often include a bundled credit pool.
Salesforce charges mostly per user, with a separate meter for agents. Its Platform pricing page lists Platform Starter at $25 per user per month with 10 custom objects, and Platform Plus at $100 per user per month with 110 custom objects. Both tiers are billed annually.
Agent actions are billed on their own meter. Salesforce’s Agentforce pricing page sells Flex Credits at $500 per 100,000 credits, and a standard action uses 20 credits, or about $0.10. Voice actions use more credits, so a voice agent costs more per step than a chat agent.
| Extension Pattern | Main Cost Driver on SAP BTP | Main Cost Driver on Salesforce |
| Internal app for 200 employees | Runtime and service credits | 200 user licenses, about $60,000 a year on Platform Starter |
| High-volume background integration | Integration Suite message credits | API limits and integration tooling licenses |
| Customer-facing AI agent | Joule and AI service credits | Flex Credits, about $1,000 for 10,000 actions |
Hidden costs sit around both meters. Every extension needs development and test environments, and those consume credits or sandbox licenses even when nothing is in production. Integration tooling adds its own license or credit line, whichever backbone you choose. Include these in the estimate, because they can make up a large share of first-year spend.
The pattern is consistent. A user-heavy internal app can cost less on BTP if the users don’t already hold Salesforce licenses, because BTP charges for consumption instead of seats. A customer-facing agent with steady volume is easy to predict on Flex Credits. A high-volume integration needs careful credit modeling on BTP, because message counts can grow faster than planned. Run the numbers for the specific extension before cost becomes a reason to break the ownership rule.
A step-by-step framework for placing each extension
A placement decision should take hours, and it should leave a written record. These steps keep each SAP BTP vs Salesforce decision consistent across teams.
- List the records the extension writes. Name every object it creates or changes, and note which system owns each one.
- Map the users. Record where the people who run the process spend their working day.
- Check the SAP option’s clean core level. If any part touches S/4HANA, confirm the SAP BTP extension or ABAP Cloud design stays at Level A.
- Choose the integration pattern. Decide which steps of the SAP Salesforce integration use events and which need synchronous API calls on your chosen backbone.
- Route agent traffic through supported paths. If an agent crosses into SAP, use supported Integration Suite or API patterns today, and plan for Agent Gateway when bidirectional third-party support reaches general availability.
- Model both cost meters. Estimate BTP credits and Salesforce licenses for the expected volume, including growth. Add agent actions if the extension uses agents.
- Write the decision down. Record which platform and team own the extension, and why, in an architecture decision record.
The last step matters more than it looks. Ownership disputes usually start a year later, when a new team asks why logic lives where it does. A short written record answers that question and stops the same debate from repeating with every new request.
Final thoughts
The SAP BTP vs Salesforce question is easier once you stop treating it as a platform contest. Each platform should own the extensions that write its own records, and that single rule settles most SAP BTP vs Salesforce debates. SAP BTP owns ERP logic and keeps the S/4HANA core upgrade-safe. The Salesforce Platform owns customer-facing processes and the screens people use all day. Shared processes get split at a clear handoff, and analytics that joins both systems belongs in a shared data layer.
The 2026 changes add new options without changing that rule. Open protocols give vendors a shared model for agent interoperability, but direct third-party delegation to Joule through SAP Agent Gateway is still an intended architecture rather than a generally available capability. Writes should still land in the system that owns the record, through the paths each vendor supports. Model the cost meters on both sides and write each decision down. Revisit it when either vendor changes its policies or pricing.
FAQs
What is the main difference between SAP BTP and the Salesforce Platform?
In an SAP BTP vs Salesforce comparison, SAP BTP extends SAP applications such as S/4HANA, while the Salesforce Platform extends Salesforce CRM. BTP sits next to orders and finance records. The Salesforce Platform sits next to accounts and opportunities. Each works best when an extension changes the records it already holds.
Should ERP extensions be built on SAP BTP or in Salesforce?
ERP logic should be built as an SAP BTP extension or with on-stack ABAP Cloud. That keeps ERP logic under SAP’s upgrade and authorization model. Salesforce can still show the results to sales or service users through API calls or embedded views.
What is a side-by-side extension in SAP?
A side-by-side extension is custom logic that runs on SAP BTP instead of inside S/4HANA. It talks to the ERP through released APIs and events. Because it doesn’t modify the core, it survives ERP upgrades with less testing.
What are SAP’s clean core levels?
They rate extensions from A to D based on upgrade safety. Level A covers BTP side-by-side extensions and ABAP Cloud development that uses released APIs. Levels B to D rate classic ABAP, with Level D marking code that clearly breaks best practices.
Can Salesforce Agentforce call SAP systems?
Yes, through supported integration and API paths. SAP’s intended architecture also uses Agent Gateway and A2A for third-party agents to delegate tasks to Joule, but SAP says bidirectional communication with third-party and self-hosted agents through Agent Gateway is not yet generally available. Treat direct Agentforce-to-Joule delegation as a planned architecture until that support reaches general availability.
Does the SAP API policy block third-party agents?
SAP says it doesn’t. The policy defines intended routing through Agent Gateway or through Integration Suite and Joule Studio. Bidirectional third-party communication through Agent Gateway is not yet generally available, so teams should separate that policy direction from current product availability. SAP states the policy adds no new pricing for those paths. Some analysts and user groups still see it as a way to control access.
Is there a direct zero-copy link between SAP and Salesforce data?
Public material doesn’t show a direct zero-copy link between SAP Business Data Cloud and Salesforce Data 360. Both platforms connect to Snowflake through zero-copy integrations, so many companies use a shared lakehouse as the meeting point.
Should I use MuleSoft or SAP Integration Suite for SAP Salesforce integration?
Either can carry SAP Salesforce integration traffic. Pick 1 as the backbone for cross-system flows, based on where most endpoints sit and where your team’s skills are. Running both for the same flows adds duplicate monitoring and support overhead.
How much does SAP BTP cost?
SAP BTP is sold through prepaid credit agreements or pay-as-you-go accounts. Credits are used up as services run, and usage beyond the credits is invoiced at list price. Exact costs depend on the services used, so SAP publishes service rates in its Discovery Center catalog.
How much does Agentforce cost per action?
Salesforce sells Flex Credits at $500 per 100,000 credits. A standard agent action uses 20 credits, which works out to about $0.10 per action. Voice actions use more credits, and Salesforce also offers per-user licensing options.
Can I copy SAP pricing logic into Salesforce?
You can, but it usually causes problems. Two copies of pricing rules drift apart over time, which leads to mismatches between quotes and invoices. A better design keeps pricing in SAP and lets Salesforce call it for answers when a rep builds a quote.
Who should own a quote-to-cash extension?
Split it at the point where a quote becomes an order. Salesforce owns the opportunity and quote steps. An SAP BTP extension owns order validation and enrichment after that point, and Salesforce receives status updates as the order moves forward.
Do ECC customers need to follow clean core rules?
The clean core levels are written for S/4HANA, but ECC teams benefit from the same habits. Building new logic as a side-by-side extension on BTP keeps it outside ECC. That makes it easier to carry forward when the company moves to S/4HANA.
What Salesforce license do I need for a custom internal app?
Many internal apps can run on Platform Starter or Platform Plus licenses. Salesforce lists Starter at $25 per user per month with 10 custom objects and Plus at $100 per user per month with 110 custom objects, billed annually.
How do I document which platform owns an extension?
Use a short architecture decision record for each extension. Note the records it writes, the owner platform, the owner team and the reason for the choice. Revisit the record when either vendor changes its pricing or policies.
