SAP S/4HANA Released APIs: What C1/C2 Release Status Actually Means

Every ABAP developer migrating to S/4HANA will eventually hit a compile error in ABAP Cloud: “Object XYZ cannot be accessed.” That error is the enforcement arm of SAP’s API release contract. Understanding the contract — not just working around the error — is what separates a clean migration from one that accumulates hidden debt.

The C1/C2 Release Contract

SAP classifies the stability of its repository objects using a release status model. The two designations you must know are:

C1 — Use System-Internally (Released for Use in Customer Code) An object with C1 status is SAP’s formal commitment that:

• The object will exist in future S/4HANA releases.
• Its interface (fields, parameters, semantics) will not change incompatibly.
• It is safe to reference in custom ABAP Cloud code and key user extensibility.

C2 — System-Internal Use Only C2 objects are internal SAP implementation details. SAP explicitly reserves the right to rename, restructure, or delete them in any release — including support packages. Referencing C2 objects from customer code is technically possible in classic ABAP, but breaks at compile time in ABAP Cloud, and represents a migration liability in every ECC system.

There are also older classifications — No Release Contract (formerly C0) for objects with no stability guarantee, and deprecated objects explicitly flagged as replaced in S/4HANA. None of these belong in new development or post-migration code.

The SAP Business Accelerator Hub

The primary authoritative catalogue for released APIs is the SAP Business Accelerator Hub. For each S/4HANA release it lists:

• Released OData V2 and V4 services
• Released CDS views (with C1 annotation)
• Released ABAP classes and BAPIs
• Business Events for event-driven integration

The hub is not just documentation — it provides sandbox environments, mock data, and OpenAPI specifications. For migration projects, the workflow is: identify an ECC table or FM you depend on, search the hub for its S/4HANA equivalent, confirm C1 status, then update your code.

Key Released CDS Views You Will Use

The following CDS views represent the highest-impact replacements for common ECC table accesses. All carry C1 release status in S/4HANA Cloud and on-premise editions unless noted.

ECC Object(s)	S/4HANA Released CDS View	Notes
MARA, MARC, MARD	I_Material, I_MaterialPlant	Material master; I_MaterialStock for quantities
VBAK, VBAP	I_SalesDocument, I_SalesDocumentItem	SD sales orders
EKKO, EKPO	I_PurchaseOrder, I_PurchaseOrderItem	MM purchasing
BKPF, BSEG	I_JournalEntry, I_GLAccountLineItem	FI; BSEG is a cluster table — direct access deprecated
KNA1	I_Customer, I_BusinessPartner	BP model mandatory in S/4HANA
LFA1	I_Supplier, I_BusinessPartner	Same BP model
FAGLFLEXA	I_FinancialPlanningItem	CO/FI reporting
AUFK	I_ManufacturingOrder	PP production orders

These are not arbitrary renames. Many involve structural consolidation — customer and vendor master data are merged into the Business Partner (BUT000 family), and financial accounting now uses the Universal Journal (ACDOCA) as the single source of truth, replacing the split between the General Ledger and CO tables.

How to Verify Release Status in ADT

Never assume release status from documentation alone. Verify in the target system.

1. Open ADT (Eclipse-based ABAP Development Tools) connected to your S/4HANA system.
2. Navigate to the object (CDS view, class, FM) via CTRL+SHIFT+A (Open Development Object).
3. Open the object and select the Properties tab → API State.
4. Alternatively, use the ABAP back-end: SELECT * FROM dd02l WHERE tabname = 'I_MATERIAL' AND as4local = 'A' and then check CL_ABAP_SYCM_RELEASE_MGMT for programmatic release status queries.
5. For CDS specifically, check the @VDM.viewType and @AbapCatalog.access.authorizationCheck annotations in the source — C1 views carry @AccessControl.authorizationCheck: #CHECK and are published under the I_ namespace.

The I_ prefix (Interface views) marks released CDS views. The C_ prefix marks consumption views for Fiori apps — also released but designed for OData consumption, not direct ABAP SQL. The P_ prefix marks private/internal views — never reference these.

The API Release Lifecycle

flowchart LR
    A[SAP Internal Development\nno release contract] --> B{API Maturity Review}
    B -->|Stable interface| C[C1 Released\nfor customer use]
    B -->|Internal only| D[C2 System-Internal\ncustomer use blocked in ABAP Cloud]
    C --> E[Published on\nBusiness Accelerator Hub]
    C --> F{Future release decision}
    F -->|Breaking change needed| G[Deprecation Notice\nin release notes]
    G --> H[Deprecated status\nsuccessor API documented]
    H --> I[Eventual removal\nafter transition window]
    D --> J[Customer code\ncompile error in ABAP Cloud]
    E --> K[Safe for custom code\nCI/ATC enforcement]

Consequences of Using Unreleased Objects

The consequences are concrete, not theoretical.

ABAP Cloud compile-time failure. In ABAP Cloud — mandatory for S/4HANA Cloud Public Edition and required for clean-core compliance — any reference to a non-C1 object causes a compile error. There is no runtime fallback.

ATC S/4HANA Readiness check violations. The ABAP Test Cockpit ships an S/4HANA readiness check variant. Every direct access to BSEG, KONV, STXL, or other pool/cluster tables generates a high-priority finding. These findings block transport in some governance configurations.

Upgrade fragility. Even in classic ABAP, an unreleased object accessed today may be structurally changed or removed in the next S/4HANA feature package or support package stack. SAP’s own documentation for the Universal Journal transition explicitly warns that programs reading BSEG directly will return incomplete data because not all line items are posted there in S/4HANA.

Performance regression. Pool and cluster tables (BSEG, KONV) are physically stored differently than transparent tables. Accessing them via compatibility views rather than their released CDS equivalents may cause full pool scans. The released views are optimised for the HANA columnar engine.

Practical Migration Approach

When scanning a custom codebase for unreleased object usage:

1. Run ATC with the S/4HANA Readiness check variant — this produces a prioritised list.
2. Cross-reference findings against your business domain owners: is this code still needed, or can it be retired?
3. For active objects, locate the C1 replacement on the Business Accelerator Hub or in SAP Note 2227308 (the S/4HANA simplification item database).
4. Update SELECT statements to reference the released CDS view, adjusting field names (the field names often change between ECC tables and released views).
5. Validate with ABAP Unit tests before transport.

Example Refactor

" ECC — direct BSEG access (blocked in ABAP Cloud)
SELECT bukrs, belnr, gjahr, dmbtr
  INTO TABLE @DATA(lt_items)
  FROM bseg
  WHERE bukrs = @lv_bukrs
    AND gjahr = @lv_gjahr.

" S/4HANA — released CDS view
SELECT CompanyCode, AccountingDocument, FiscalYear, AmountInCompanyCodeCurrency
  INTO TABLE @DATA(lt_items)
  FROM I_GLAccountLineItem
  WHERE CompanyCode = @lv_bukrs
    AND FiscalYear   = @lv_gjahr.

The field names change. The semantics are equivalent. The second version compiles in ABAP Cloud, benefits from HANA push-down optimisation, and is covered by SAP’s stability commitment.

Governance Going Forward

Once your codebase is clean, keep it clean with automated enforcement:

• Configure the ATC S/4HANA readiness check variant to error (not warning) severity for non-C1 access.
• Add a CI gate that runs ATC on every transport request before release to quality systems.
• Restrict the ABAP Cloud language version (ABAP for Cloud Development) on new development packages — the compiler will reject non-C1 references at development time, before ATC is even needed.

The 2027 ECC end-of-mainstream-maintenance deadline does not wait for gradual adoption. Every new object created today with unreleased table access is technical debt that must be resolved before cutover. Automating the enforcement now costs far less than triaging 50,000 findings during a time-pressured migration.