Connecting SAP without touching it: how to integrate your store, your bank and your partners without leaving custom developments in the way

In 1 minute

Connecting something to SAP calls for two decisions: which mechanism you come in through, and where each channel's logic lives. The shortcut —a custom program coupled to SAP's internals— feels faster and is paid for at the next upgrade. SAP says it in its own words: what relies on its released interfaces is what best withstands an upgrade. This article explains, in boardroom language, which doors exist, when each one makes sense and what to ask before approving the next integration.

Imagine a mid-sized company that runs its accounting, its inventory and its invoicing on SAP. It is fictitious, but it looks like many. One day three requests reach the technology team, almost at the same time:

• Sales wants the online store to send every order to SAP and check price and stock.
• Finance wants the bank statement reconciled against what SAP has as receivables.
• The commercial team wants a distribution partner to be able to send its orders from its own system.

All three are reasonable. And all three hide the same question: where will the connection live?

The quick answer is usually "inside SAP, however we can": a custom program that reads the bank's file, a new table for the store's orders, a tweak to a standard process for the partner. It works, and it works soon. The cost does not show up on delivery day. It shows up on the day SAP has to be upgraded, and someone discovers that each of those developments has to be reviewed, tested and, sometimes, rebuilt.

This article is for those who lead technology, finance or operations at a company that runs SAP and needs to connect more things to it; the reasoning also applies to other vendor ERPs. It makes one argument: the connection goes through the doors the vendor supports, and what belongs to each channel, as a rule, lives outside the ERP. It is not only an architecture preference: SAP recommends separating what is added and relying on its released interfaces to reduce technical debt and make upgrades simpler [1][2].

This is not an article about whether the connection should be online or asynchronous; that is in Online or asynchronous?. The question here is a different one: which door you use to get into SAP, and what stays outside.

The cost is collected at the next upgrade

SAP has been telling its customers this for years, and it has a name for it: clean core. The idea is to separate what each company adds from what SAP delivers, so that an upgrade does not break what was added and what was added does not break the upgrade. A public presentation by SAP consultants sums it up: "Custom extensions do not break an upgrade and upgrades do not break an extension – separate extensions by leveraging released APIs"; and "Extensions should be avoided when possible" [2].

Its training material is even clearer about the old path. It describes the traditional way of programming inside SAP as code that "was tightly coupled to the system, could be problematic in the case of an upgrade and was thus recommended to be used as a last resort" [1]. Today, for SAP S/4HANA, SAP classifies extensions into four levels, from A to D: Level A uses released interfaces and extension points and is the one that gives the greatest stability when upgrading, whether outside SAP or inside it with the tools SAP allows; and an extension is rated by the lowest-level technology it uses [1].

In boardroom language: every development coupled to SAP's internals is a debt paid, with interest, at upgrade time. Not all of them can be avoided. But each one should have a written reason. And even with everything in order, every upgrade gets tested: what changes is how much there is to review.

The doors SAP already has

SAP is not closed. It has several integration mechanisms —here we call them doors—, and each one is meant for something different. The board does not need to know how they work inside; it is worth knowing that they exist and asking which one will be used. Which ones are available, and for which operations, depends on the SAP product and version you have.

And one door that is not on the list: writing directly into SAP's tables. It is tempting because it looks like the shortest, and it gets in the way because it can skip the controls SAP's business process uses to look after its own information.

The technical page of Hábil MDW says it in one sentence: for ERPs we prioritize the interfaces the vendor supports —in SAP, for example, JCo, OData, IDoc or REST—, so we don't leave you custom developments that get in the way when you upgrade it.

What stays in SAP and what stays outside

Coming in through the right door is half of it. The other half is deciding which logic lives in SAP and which lives outside. A useful rule:

• What stays in SAP is what SAP does well and what the law or the audit asks of SAP: the accounting, the official inventory, the invoicing, the customer and the material as the ERP knows them.
• What stays outside is what belongs to each channel or each partner: the file format of each bank, the rules of the online store, the translation of what each distributor sends, the retries, the trail of what was sent and what SAP answered.

Those retries and that trail are also what keep the sale going on the day the ERP does not answer; that is in The ERP went down on Saturday.

SAP has a name for the second part: side-by-side extensions, which run outside the ERP and connect to it [2]. It is not the only clean way —SAP also allows extensions inside the ERP when the case calls for that coupling and they are built with its released tools [1]—, but for what belongs to each channel it is usually the best fit. The business advantage is twofold. Less custom code stays inside the ERP, so there is less to review at every upgrade. And a new channel mostly changes the outside layer; in SAP, at most, some master data or a configuration.

The three requests, solved through the right door

Back to the fictitious company.

The online store. Each order enters SAP through a published interface, with a unique reference number that is checked before recording it, so that a retry does not duplicate it: the interface does not bring that, it is designed. Price and stock are queried the same way, if the SAP version offers it; if the store checks them many times per minute, it is worth having the outside layer keep a copy, with an agreed refresh frequency, so that SAP does not carry every visit. The logic of the cart, the coupons and the customer notices stays in the store or in the outside layer, not in SAP.

The bank. The bank sends its statement as a file, in its own format. The outside layer picks it up, validates it, translates it and reconciles it against what SAP has as receivables. SAP only receives what it has to record, through its official door. If a second bank with another format joins tomorrow, the outside layer is taught; in SAP, at most, the account is set up.

The distribution partner. The partner comes in through a door with its own identity and its own permissions, sends its orders in its own format, and the outside layer translates them into the order SAP knows. If the partner changes systems, the translation is adjusted; SAP stays the same.

In all three cases, SAP does what it does best. When it is time to upgrade it, the three connections get tested, but there are no three custom developments hidden inside to review one by one.

When the door you need does not exist

Sometimes there is no published interface for what is needed, especially in older SAP versions. That does not force you to go inside SAP right away. SAP itself publishes a guide for that case: wrapping a classic function —its example is a BAPI that creates purchase requisitions— in a custom interface, small and documented, that is released for new development to use; the function underneath is still classic, and SAP classifies it at Level B [1][6]. The same group of tutorials then shows how to replace that wrapper with the released interface SAP published for that process [6]. Its FAQ adds a useful warning: if a released API is provided for only one of the classic APIs combined in one wrapper, "you will not be able to retire the wrapper, since it still makes use of other classic APIs", and it also risks mixing responsibilities [7].

In boardroom language: if you have to come in through a door that is not the top level, it is done on purpose, in a single place, with a name and an owner, and checking at every version whether SAP already offers a released alternative.

The risks, in business language

Five questions for your next board meeting

1. How many custom developments does your company have inside SAP to connect other systems, and who knows them? If nobody can answer with a list, that is the first finding.
2. In the last SAP upgrade, how many of those developments had to be reviewed or rebuilt, and how much time did it take?
3. For the next integration to be approved, which SAP door will it use? Ask for it in writing: published interface, remote function, intermediate document or file —and which SAP process receives it—, and why.
4. Does anything write directly into SAP's tables? If the answer is "I don't think so", it is worth checking.
5. If a new bank or partner joins tomorrow, what has to change in SAP? Some master data or a configuration is normal. If the answer is "a new program", each channel's logic is probably living in the wrong place.

If several answers are "I don't know", take it as a sign to do the inventory before approving the next integration.

Where to start this week

Take an inventory of SAP's connections. One sheet, one row per connection, with five columns:

• Which system connects: store, bank, partner, other?
• Which door does it use: published interface, remote function, intermediate document, file or straight to tables?
• Does that channel's logic live inside SAP or outside?
• Who maintains it, and is it documented?
• Did it break, or did it have to be reviewed, in the last upgrade?

The resulting sheet shows, with facts, which connections depend on custom code inside SAP and helps decide where it makes sense to start moving logic out. It works with any tool, or with none.

What Hábil does

At Hábil we build custom integration between SAP —or whichever ERP you have— and what surrounds it: the store, the banks, the partners and the channels. We do it by coming in through the doors the vendor supports and keeping outside what belongs to each channel.

If your inventory shows connections that depend on custom developments inside SAP, the proposal is in Hábil MDW. It connects to your ERP and to your channels through the means each one already has, converts what comes in into a single language and keeps a record of what happened, when and who did it. For ERPs we prioritize the interfaces the vendor supports, so we don't leave you custom developments that get in the way when you upgrade it. Banks, stores, agents and distributors connect with their own identity and their own permissions. The scope, the doors used and the order in which logic is moved out of SAP are reviewed with your case.

The conversation can start with your inventory, even if it is half done: what connects, which door it uses and what broke in the last upgrade. With that, we review together where it makes sense to start. Write to us on WhatsApp; to protect your information, do not share data about your systems or your customers through that channel: we will agree in the conversation on the channel for the case.

Request your first conversation, at no cost.

Consulted on 12 November 2026. Each reference carries its confidence: high (primary source read).