The Released Contract Has Moved Off BAPIs

In one S/4HANA 2023 lab, 5,487 function modules carry the BAPI prefix. Nineteen are released for ABAP Cloud. The number is not the story. The story is where the released contract went, and why a classification that still moves is harder to govern than a fixed ban.

The count of 5,487, with 19 released, 148 not to be released, and 5,320 carrying no entry, comes from table ARS_W_API_STATE on one S/4HANA 2023 system, SAP_BASIS 758, FPS01, as published on SAP Community. The same 19 and 148 appear in SAP’s file objectReleaseInfo_PCE2023_1.json. The later comparisons use objectReleaseInfo_PCE2025_2.json and objectClassifications_SAP.json in the Cloudification Repository, SAP/abap-atc-cr-cv-s4hc. Your system will differ.

A BAPI is a function module with a business name

For twenty years, BAPIs were how an external system talked to SAP. Create a purchase order: BAPI_PO_CREATE1. Post a goods receipt: BAPI_GOODSMVT_CREATE. Commit the transaction: BAPI_TRANSACTION_COMMIT. The pattern was stable enough that integration code, middleware, and custom ABAP still assume it will keep working.

Clean Core changes the assumption. It does not do it by deleting the function module.

What the table actually shows

ARS_W_API_STATE is the table behind the API State tab in ADT. On that 2023 lab the BAPI-prefixed function modules split like this:

• 5,487 in total
• 19 released
• 148 not to be released
• 5,320 with no entry at all

Those numbers do not mean SAP released only 19 APIs. The same system has 24,670 released C1 objects. Thirty-nine of those are released function modules. The rest are CDS views, tables, structures, interfaces, and classes.

The released contract moved. It moved to CDS views, to released interfaces, and to RAP business objects. The BAPI name stayed on the system. The stability contract was built somewhere else.

Two levels, not one boundary

In August 2025 SAP replaced the older three-tier extensibility story with a clean-core level model.

Level A is a released API: on-stack ABAP Cloud, or side-by-side on BTP, using objects SAP has given a stability contract.

Level B is a classic API. SAP nominates these. They are documented and generally upgrade-stable. They do not carry the Level A contract. ATC flags them at Priority 3. A BAPI is Level B only when it appears on that classic list.

“Not released” in ARS_W_API_STATE is a Level A statement. It means there is no ABAP Cloud contract. It does not mean the function is deleted, and it does not mean a classic programme is forbidden from calling it today.

A common reading of the 19 is that any other BAPI sits outside the policy. That reading fits Level A. It does not fit a classic ABAP programme on a classic stack. The programme can still be accumulating the debt the companion essay names. It is not crossing a technical block of the kind Note 3255746 put on ODP over RFC. That note does not restrict BAPI calls. The note and the release state are separate questions.

“Not released” is not the same as “dead end”

Of the 148 marked not to be released in the 2023 file, 142 name a successor: 76 a RAP business object, 62 a CDS view, and 4 a class. BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK are released. Transaction control is not in the unclassified set.

The links move. In the 2023 FPS01 file, BAPI_PO_CREATE1 points at I_PURCHASEORDERTP_2. In the 2025 FPS02 release-info file, that entry is gone. The current classic-API file lists BAPI_PO_CREATE1 as a classic API with the labels remote-enabled and transactional-consistent. That is an acknowledgement of use, not a Level A release.

BAPI_ACC_DOCUMENT_POST pointed at I_JOURNALENTRYTP in the 2023 file. In the 2025 FPS02 file it is still not to be released, and the successor is gone. Five other BAPI_ACC_* functions lost a successor in the same way. BAPI_SALESORDER_CREATEFROMDAT2 still points at I_SALESORDERTP. It is also on the classic list, with remote-enabled only. It does not carry transactional-consistent.

Twenty-seven of the original 148 do not appear in the 2025 FPS02 release-info file at all. All 27 sit in purchasing and supplier invoice. The released BAPI count in that file is still 19.

This is a classification still being written. The lab table is what one release recorded. The repository is the current public position. They do not always agree, and neither is the last word.

The unclassified set is smaller than the 2023 lab

The 5,320 with no entry were unclassified in that lab. They are not all unclassified now.

Cross-checking those names against the current classic-API file, 2,972 are now classic APIs. They are Level B. They are not released for ABAP Cloud. SAP has nominated them. Of the original 148, 139 are on that classic list as well, and 25 of the 148 carry transactional-consistent. BAPI_PO_CREATE1 is one of the 25.

That leaves 2,348 from the old no-entry set. They are not in the 2025 release-info file, and they are not on the classic list. No entry is not a clearance. It is not Level A, and it is not a nominated classic API. The call may still execute. Clean Core has not given it a contract.

For Level A development the rule is simple: use released objects. For Level B the practical question is whether the BAPI is on the classic list, and whether it carries a label such as transactional-consistent, which is the label SAP points to when a classic function is wrapped for use beside ABAP Cloud.

The open question is the agent

An agent that calls an unreleased BAPI from outside BTP stacks two constraints.

The interface has no Level A contract. The call can work. No clean-core stability commitment covers it.

SAP’s April 2026 API position draws a second line. AI may assist work on SAP systems. Autonomous multi-step execution against SAP is a different category. SAP can state that line. Enforcement stops at SAP’s own infrastructure. An agent on Azure, calling a BAPI through RFC or an open integration, is the customer’s to govern.

Domain 3 of the Governance Readiness Score is AI Safety & Policy. That is the agent question. Domain 9 is Clean Core. That is the interface question. The BAPI surface is where they meet. An agent that inherits the unclassified set inherits the least defended position in the estate: no Level A contract, and no human checkpoint on a chain of calls.

ECC does not have the table

ARS_W_API_STATE exists in S/4HANA. ECC 6.0 does not carry it. An ECC system cannot look inside itself and see whether a BAPI will land as released, classic, or unclassified after migration.

The Cloudification Repository is still usable there. SAP’s ATC content reads it for custom code on ECC and on S/4HANA. Using it is a deliberate step: take the call inventory from the ECC system and look the names up in the repository. The repository says what SAP publishes now. The table in an S/4 system says what that release recorded. ECC has the first, once you go and use it. It does not have the second.

What to do with this

Four steps. None of them requires a new product.

1. Count the BAPIs your code calls. In S/4HANA, read ARS_W_API_STATE. On ECC, take the call list to the Cloudification Repository.
2. Separate three buckets, not two. Released, Level A. Classic, Level B. No classification. The posture is different for each.
3. Replace the ones that name a successor, and check whether they still do. The 2023 file and the 2025 FPS02 file do not agree on every link. The repository is the current public source. The table in your system is a snapshot of your release.
4. Do not let an agent inherit the unclassified set. If an agent is going to call SAP, the BAPIs with no release and no classic nomination are the ones it must not assume it owns.

How Skynome holds Clean Core

The four steps are the reading. The practice that keeps the reading current is the methodology already on this site: Assess, Plan, Govern, Optimize. GovOps for SAP is the name of that practice. The Operational Control Plane is the product that runs it. This essay does not move the tagline.

Clean Core, in that practice, is a position the estate can state. It is which calls are released, which are classic, and which carry no status. It is not a one-time code cleanup, and it is not a claim that every BAPI has been replaced.

Assess. The engagement starts with the Governance Readiness Score. Domain 9, Clean Core, comes into scope when an S/4 or Clean Core programme is active. The evidence for this line item is the call inventory: ARS_W_API_STATE on S/4, the Cloudification Repository on ECC and on S/4. The output is three buckets, with the repository file and the system release written on the page. Domain 9 does not absorb Domain 7. Extraction compliance stays its own domain.

Plan. New work that has to be Level A uses released objects: CDS views, released interfaces, RAP business objects. A classic programme may keep a Level B BAPI that the current file nominates, with an owner and the labels that file actually carries. Where a successor is still named, the roadmap points at it and records the file date, because the link can leave between feature packs. A name with no classification is scheduled as debt with an owner. Custom code then follows the split the ECC planning framework already uses: what stays, what is retired, and what moves to BTP as a side-by-side extension.

Govern. A new extension does not ship until the review can say which bucket the interface is in, and on which file. An agent does not receive the unclassified set. That checkpoint is Domain 3, AI Safety & Policy, sitting on a Domain 9 fact. Extraction does not re-enter the core through an interface SAP has restricted or left unclassified. The default path leaves SAP through an approved file drop, or through DRF and Cloud Integration, with no Azure credentials stored on S/4. A direct push from S/4 is an exception that has to be approved. The Azure side does not authenticate back into SAP. On RISE, the operating-system paths stay gated. None of this is an SAP certification. A design that stays off a restricted interface is outside the scope of that restriction. It is a design fact.

Optimize. The classification is re-read when SAP publishes a new release file. The 2023 FPS01 snapshot and the 2025 FPS02 file do not agree, so a cleanup dated to one lab goes stale. The cadence is the one the methodology already runs: a quarterly reading of the score, with Domain 9 moved only when the inventory moved. The BAPI list is a living document.

Where this sits in the score

This essay lives in Domain 9, Clean Core. Domain 9 asks whether the estate can state which calls are released, which are classic, and which carry no status. The BAPI inventory is the concrete form of that question. Because successors appear and disappear between releases, the inventory is a living document.

Domain 3, AI Safety & Policy, picks up the execution. Who may chain those calls, and whether a person is still in the loop, is a Domain 3 question. The interface underneath is Domain 9.

The score does not tell you to stop calling BAPIs. It tells you to know which ones you call, what the current file says about them, and whether anything autonomous is inheriting the assumption that the contract will sit still.

The 5,487, the 19, the 148, and the 5,320 are one S/4HANA 2023 lab, confirmed by SAP’s 2023 FPS01 release-info file. The 2025 comparisons are the public repository files named above, read against that list. The method travels. The counts do not.

SAP is a registered mark of SAP SE. Skynome is not affiliated with or endorsed by SAP SE.