Build what makes you different. Keep the core clean.
SAP Cloud ERP runs your standard processes. The things that set your business apart, such as a field app, a dealer portal or a special approval, are built around it: small changes inside the system, and complete apps on SAP's Business Technology Platform. Every extension uses SAP's released interfaces, so the twice-yearly upgrades never break what you've built.
About the names. At SAP Sapphire 2026, SAP brought its Business Technology Platform (BTP), Business Data Cloud and Business AI together as the SAP Business AI Platform. You'll see both names for a while.
Don't change SAP. Build next to it.
In older ERP systems, companies changed SAP's own code to fit their needs. Every upgrade then became a project, because someone had to check and repair every change. Many companies simply stopped upgrading.
Clean core means SAP's standard stays untouched. Your extensions connect only through interfaces SAP has released and promised to keep stable. SAP upgrades the core, and your extensions carry on working.
Modified core
Every upgrade means retesting and repairing custom code. Projects take months, so upgrades get delayed for years.
Extended core
SAP upgrades twice a year on a fixed schedule. Extensions keep working, and you get new features without a project.
Always start with the simplest option that does the job.
SAP gives you three ways to extend SAP Cloud ERP. Each step to the right gives more freedom, and also more to build, test and own. We only move right when the requirement really needs it.
Key-user changes
Business experts, in the browser, no code- Custom fields on screens, forms, reports and APIs
- Screen layouts by country, unit or role
- Simple rules, such as checks and defaults
- Form and email layouts with your branding
- Custom reports and analytical queries
Choose when: the change is a field, a rule, a layout or a report.
Developer extensions
ABAP developers, inside the system- Logic too complex for key-user tools
- Custom business objects tightly tied to SAP data
- Custom SAP Fiori apps on SAP data
- Only released APIs and extension points
Choose when: it must run inside SAP's transactions. Needs the three-system landscape.
Side-by-side apps
Developers and low-code builders, on SAP BTP- Apps with their own users, such as suppliers, dealers or field staff
- Mobile and offline apps
- Logic that spans several systems
- AI agents and automations
Choose when: it has its own life cycle, its own users or reaches beyond SAP.
Before any of the three, we ask whether a standard process or setting already covers the need. Often it does.
A new field in minutes, everywhere it's needed.
Say your sales team needs to record the tea grade on every sales order. A key user adds one custom field in the browser and chooses where it appears: the order screen, the invoice form, the sales report and the API that feeds your CRM.
Before promising any change, we check SAP's Extensibility Cockpit, which shows what each app and process allows. That way the answer is "yes, here's how" or "no, here's the alternative", not a surprise halfway through the project.
Apps we build next to SAP.
Side-by-side apps reach the people and places your ERP doesn't: smallholders, dealers, field teams and suppliers. Each one reads and writes SAP data through released APIs, and signs users in with the same identity service as SAP.
Bought leaf and collection
Weigh-in at collection points, offline on a phone, with supplier settlements and payments run in SAP.
Dealer and distributor portal
Dealers place orders, check stock and prices, download invoices and see what they owe, from their own login.
Supplier onboarding
New suppliers submit their company, tax and bank details and documents. Checks and approval run before the record reaches SAP.
Field sales and van sales
Route plans, orders and collections on a tablet, synced to SAP when the van is back in coverage.
Style costing for apparel
Merchandisers build cost sheets for a style from SAP prices and rates, compare scenarios and send the agreed cost back to SAP.
One inbox for approvals
Approvals from SAP and other systems in one place, on the web and on SAP's mobile app, with Joule to explain each request.
From a smallholder's leaf to a bank transfer.
Tea factories in the low country buy green leaf from hundreds of smallholders every day, often in places with weak mobile coverage. Here's how a side-by-side app and SAP Cloud ERP share the work.
Weigh and record at the collection point
The collector records weight, deductions and quality for each supplier and prints a receipt. It works without a signal.
Sync, check and combine
When the lorry reaches coverage, the app syncs. The BTP service checks for duplicates and combines the day's intake by supplier.
Goods receipts and supplier liabilities
Through released APIs, the service posts goods receipts and builds the fortnight's supplier invoices at the agreed leaf price.
Pay smallholders by bank transfer
SAP's payment run creates a bank file for the fortnight, and the settlement statement goes to each supplier.
Build your own AI agents, inside the same guardrails.
SAP's AI agents cover common tasks such as accruals and cash management. For tasks specific to your business, Joule Studio lets teams build custom agents by describing the outcome they want. SAP launched it at Sapphire 2026.
Custom agents run on SAP's managed platform, use the same business context as SAP's own agents, and act only within each user's existing permissions.
Describe, then refine
Joule Studio drafts requirements, logic and tests from a plain-language description. Developers can also work in Python or TypeScript.
Grounded in your SAP data
Agents use SAP's Knowledge Graph and business data, so they understand what an order, a supplier or a cost centre means.
Governed like any extension
Each agent has an owner, a clear scope, human approval where it matters, and a place in the regression tests.
Every extension documented, owned and tested.
An extension is a small product. It needs an owner, documentation and tests, or it becomes the next system nobody dares to touch. Every extension we build comes with the following.
Extension register
What exists, why, who owns it, and which SAP interfaces it uses.
Your code, your repository
Source code in your Git repository, not on a consultant's laptop.
Tests in every release
Automated tests added to the regression pack that runs before each SAP upgrade.
Roles and security
Access by role, sign-on through SAP's identity service, and no personal data in custom fields.
Handover and training
Your team can maintain key-user changes and simple apps themselves.
Clean-core check
Every extension uses released interfaces only, checked before it goes live.
See it from SAP.
Videos from SAP’s official YouTube channel on clean core and building your own apps and agents.
Published by SAP on its official YouTube channel.
© 2026 Mawkish Technologies. This guide, its diagrams and illustrations are protected by copyright. You’re welcome to learn from it and to quote it with credit and a link. Reproducing it, by hand or through AI, and publishing it as your own is not allowed. Read our copyright notice
Straight answers.
Do we need to pay for SAP BTP?
Key-user changes and developer extensions inside SAP Cloud ERP come with your subscription, although developer extensions need the three-system landscape. Side-by-side apps run on SAP BTP services, which are subscribed separately and sized by use. We size this with you before you commit.
Will our extensions break when SAP upgrades?
Not if they're built on released interfaces, which is the only way SAP Cloud ERP allows. We also run each extension's tests on the upgraded test system before SAP upgrades production.
Our old ERP has hundreds of customisations. Do we rebuild them all?
Usually not. When we go through them, many turn out to be reports that standard analytics now covers, or workarounds for processes SAP now handles. The rest become key-user changes, developer extensions or side-by-side apps, and only where they still add value.
Low-code or pro-code?
Both have a place. Low-code with SAP Build is fast for forms, approvals and simple mobile apps. Pro-code with CAP or ABAP Cloud suits complex logic, high volumes and apps you'll grow over years. We choose per app and tell you why.
Can our own developers build extensions?
Yes, and we encourage it. Many clients have us build the first extensions together with their team, set the standards, and review what the team builds after that.
Who owns what we build?
You do. The code lives in your repository and runs in your SAP accounts, and the documentation is handed over with it.
Bring us your list of "SAP doesn't do this".
In one workshop, we take each requirement and tell you whether standard SAP covers it, which of the three options fits, and roughly what it takes.
- Standard first, then the simplest option
- Key-user, developer or side-by-side
- Low-code or pro-code, per app
- BTP services and sizing
- Ownership and support model
SAP, SAP BTP, SAP Build, Joule and SAP Cloud ERP are trademarks of SAP SE. Screens shown are illustrations.
The Calmarsh Gate is our shorthand for looking after the details nobody sees in SAP BTP Extensions & Apps.