Released SAP APIs vs direct-table access: Clean Core the right way

Every team modernising SAP eventually hits the same fork. You need to change data or add a behaviour, and there are two ways to do it: call a released interface that SAP maintains, or reach past it and write the underlying tables yourself. The two look similar in a demo. They are worlds apart in production, on upgrade day, and on the road to the cloud. This is the practitioner's version of why.

What is a released SAP API?

A released SAP API is a stable, SAP-maintained contract for reading or changing business data. SAP publishes it, marks it as released, and commits to keeping it stable across releases. You can find released interfaces in the SAP Business Accelerator Hub, still widely called the SAP API Hub, alongside the RAP-based OData services and remote-enabled BAPIs that make up the modern set.

The word that matters is contract. When you build on a released API, you are building on something SAP has promised not to break. When you build on a table structure instead, you are building on an internal detail SAP never promised to keep the same, and that it changes when it needs to.

Why are direct-table writes to SAP wrong and dangerous?

Writing directly to SAP tables skips the business logic that makes the data correct. A single business action in SAP is rarely one row in one table. It is validations, number-range assignment, currency and tax handling, status updates, and several tables that must change together and stay consistent. The released interface runs all of that. A raw table write runs none of it.

There are three failure modes, and they compound:

• You bypass the business logic. The checks and side effects that keep records consistent never run, so you can create data the system considers valid but that is quietly wrong.
• You break on upgrades. Table structures are internal. SAP reshapes them between releases, and code that pokes them directly stops working, or worse, keeps writing into a structure that no longer means what it used to.
• You violate Clean Core and SAP's API governance. Direct access to the standard core is exactly what Clean Core exists to stop, and it puts you outside SAP's whitelisted, supported interfaces.

A concrete example: posting a supplier invoice

Say you need to post a supplier invoice. The Clean Core way is to call the released Supplier Invoice interface, historically the BAPI_INCOMINGINVOICE_CREATE BAPI and now also available as a released OData service. You hand it the header, the line items, and the tax data. SAP's posting engine takes it from there.

Behind that one call, SAP writes the invoice header table (RBKP), the invoice item table (RSEG), and the accounting view in the Universal Journal (ACDOCA), all together, in one consistent posting, with every validation and downstream update applied. Number ranges are assigned, the document balances, tax is calculated, and the financial and logistics views agree because the same engine wrote both.

Now picture the wrong way: writing RBKP, RSEG, and ACDOCA directly. You would have to reimplement SAP's posting logic yourself, keep three tables in perfect agreement by hand, and hope the structures never change. Miss one field or one dependency and you have an invoice that looks posted but does not reconcile, a Universal Journal entry that does not tie back, or a document that blocks the next upgrade. The released API exists precisely so you never take that risk.

How do released APIs keep you upgrade-safe and cloud-ready?

Released APIs are the interfaces SAP commits to keeping stable, so code built on them survives upgrades that reshape the tables underneath. That same stability is what makes S/4HANA Cloud possible: in the cloud editions, direct table access simply is not on the menu, and released, whitelisted APIs are the supported way in.

This is the heart of Clean Core. Keep your extensions and integrations on released interfaces, whether that is a RAP-based OData service, a released CDS view for reading, or a remote-enabled BAPI, and the standard core stays clean. Upgrades become routine instead of a project, and the same code runs whether the customer is on-premise today or moving to the cloud tomorrow. Build on internal tables and every upgrade is a negotiation with your own past shortcuts.

Where does C16 stand on this?

C16's position follows directly from everything above. Any code C16 generates writes through SAP released APIs. It does not write to underlying tables directly, because that is the practice Clean Core exists to prevent. When the right path is posting through the Supplier Invoice interface, that is what the generated code does.

C16's own analysis is read-only. It reads a system to understand a process, surface the custom code that matters, or explain why something is stuck, without changing anything. And when generated code does make a change, that change goes to a development system, is reviewed by an expert, and is promoted through the customer's own change process. Nothing C16 drafts ships without your approval. Expert-in-the-loop, released APIs, and the customer's own governance are not add-ons here; they are the default.

The short version

Clean Core comes down to one discipline: write through the front door. Released APIs are a contract SAP maintains for you, so your code stays correct, consistent, and upgrade-safe. Direct-table writes borrow against a future upgrade you will eventually have to pay back, with interest. Pick the interface SAP promises to keep.

If you are weighing this as part of a broader move, it connects to the wider readiness picture, from a S/4HANA readiness assessment to a custom-code assessment for S/4HANA and a fit-to-standard analysis.

See what Clean Core looks like on your system. C16 reads your SAP, read-only, and shows where custom code writes past the released APIs, on ECC or S/4HANA. Book a walkthrough.

C16's analysis is read-only by default. Any code C16 generates uses SAP released APIs and does not write to underlying tables directly. Generated changes go to a development system, are reviewed by an expert, and are promoted through the customer's own change process; Nothing C16 drafts ships without your approval. PEOL Technologies is an SAP Partner, ISO 27001 certified and SOC 2 Type II compliant.