Clean core vs custom code for client-side extensions in financial accounting

ERP SAP S/4HANA
, , , , , , , ,
1

Our organization is running SAP S/4HANA 1909 and planning an upgrade to 2024. We have significant custom ABAP code for client-side financial accounting extensions-custom validation logic in posting transactions, enhanced approval workflows, and modified financial reports.

Management is pushing for SAP’s clean core approach, arguing it will reduce upgrade effort and future-proof our system. Our development team counters that moving everything to SAP BTP will create integration complexity and potentially impact performance for real-time validations during posting.

I’m curious about others’ experiences balancing clean core principles with practical business requirements. Has anyone successfully migrated complex financial validation logic to BTP extensions? What’s been the real-world impact on upgrade cycles versus the overhead of maintaining side-by-side extensibility? Looking for honest perspectives beyond SAP’s marketing materials.

system 2

Clean Core Migration: 1909 → 2024 Financial Extensions

Your dev team’s concerns are legitimate, but they’re not mutually exclusive with clean core. The real question is which extension type fits which use case — not a blanket BTP migration.

Pre-Upgrade Checks (1909 Source → 2024 Target)

Custom Code Assessment

  • Run ABAP Test Cockpit (ATC) with the Custom Code Migration app (Fiori) against your 1909 codebase. Filter specifically for modification-based extensions in FI namespace (FB01, FB50, BKPF/BSEG table enhancements).
  • Check all user exits and BADIs in FIN_GL_CLEARING, AC_DOCUMENT, and FAGL_-prefixed enhancement spots. Many of these have cleaner S/4HANA equivalents by 2024 (verify in your version).
  • Identify implicit enhancements in core FI posting programs — these are your highest-risk artifacts for upgrade breaks.
  • Validate custom reports built on BSEG direct reads; 2024 pushes harder toward ACDOCA as the single source of truth. Queries against classic tables may degrade or behave unexpectedly (verify in your version).
  • Use SAP Readiness Check 2.0 targeting S/4HANA 2024 — pay attention to the Simplification Item catalog entries for FI-GL and FI-AP/AR.

Migration Sequence

  1. Classify extensions by latency sensitivity. Real-time posting validations (sub-100ms requirement) are poor BTP candidates over synchronous RFC/OData. Approval workflows and report logic are excellent candidates.
  2. Replace high-risk modifications first. Convert BADIs/user exits still implemented via classic methods to explicit BAdI implementations using CL_EXITHANDLER patterns — this keeps logic in-system but clean.
  3. Migrate approval workflows to SAP Build Process Automation. This is the clearest clean-core win: zero ABAP footprint, direct integration via standard APIs, and upgrade-transparent.
  4. For real-time validations, evaluate In-App Extensions using Business Add-Ins (released BAdIs) documented in the extensibility catalog. If the released BAdI covers your logic, keep it in-system — this is clean core. BTP is not the only clean-core mechanism.
  5. Migrate financial reports to SAP Analytics Cloud or custom Fiori apps backed by CDS Virtual Data Models (VDMs). Replace BSEG-direct ALV reports with ACDOCA-based CDS views exposed via OData.
  6. For genuinely complex cross-system validations, implement side-by-side extensibility on BTP using SAP Event Mesh for async patterns or synchronous OData calls — but benchmark the round-trip latency against your SLA before committing.
  7. Run dual-landscape regression testing on FI posting scenarios: particularly document splitting, parallel ledger postings, and intercompany flows where custom validation logic tends to collide with S/4HANA 2024 enhancements.

Rollback Procedure

  • Maintain a transport-isolated copy of all custom objects in a dedicated Z-package before any clean-core refactoring.
  • Keep the 1909 system live in read-only mode through at least one full financial close cycle post-cutover.
  • For BTP-side extensions, implement feature flags so posting flows can fall back to in-system logic without transport deployment.
  • Document SPRO configuration deltas separately from code — configuration regression is frequently the actual failure mode, not ABAP.

Honest assessment on upgrade cycles: Teams that do the ATC cleanup and move to released BAdIs typically see measurably shorter technical upgrade windows. The BTP overhead argument is real but often overstated for async workflows. Synchronous validation performance concerns are legitimate — don’t let clean-core ideology override a documented latency requirement.

This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

We went through this exact debate last year with our 1909 to 2023 upgrade. Clean core sounds great in theory, but the reality is more nuanced. Real-time validations during financial postings need sub-second response times. Moving those to BTP introduces network latency that’s unacceptable for user experience. We kept transaction-level validations in-system using BADIs and enhancement spots (which SAP still supports), but moved batch reporting and analytics extensions to BTP. That hybrid approach gave us upgrade safety where it matters most while keeping performance where users demand it.

4

The technical debt argument cuts both ways. Yes, custom ABAP code can break during upgrades, but BTP extensions create their own debt-you’re now maintaining integration points, authentication flows, and separate deployment pipelines. For financial accounting specifically, SAP’s released BADIs like BADI_AC_DOCUMENT and BADI_FAGL_DERIVE_SEGMENT are designed to be upgrade-safe. If your customizations fit these extension points, you get the best of both worlds: in-system performance with SAP-supported extensibility that survives upgrades.

5

From a strategic perspective, clean core isn’t just about the current upgrade-it’s about long-term agility. SAP is clearly moving toward cloud-first architecture, and their investment in ABAP development tools is declining. BTP extensibility using CAP (Cloud Application Programming Model) gives you portability. If you decide to move to S/4HANA Cloud in five years, your BTP extensions migrate seamlessly while custom ABAP becomes a rewrite project. The integration overhead you’re worried about today is an investment in future flexibility. We’ve found that workflow extensions and approval processes work particularly well on BTP using SAP Build Process Automation, while keeping core posting logic in-system.

6

Here’s the pragmatic view from someone who manages both development teams and upgrade budgets: categorize your customizations by business criticality and technical coupling. High-frequency, latency-sensitive operations like posting validations should stay in-system using supported extension points. Workflow approvals, reporting enhancements, and integration scenarios are perfect candidates for BTP. We created a decision matrix: if the extension directly modifies core SAP tables or requires synchronous execution within a transaction, keep it ABAP. If it’s asynchronous, read-only, or integration-focused, move it to BTP.

7

The upgrade safety benefit of clean core is real but often overstated. Our 1909 to 2024 upgrade took eight months, and custom code issues accounted for maybe 20% of the effort. The bigger challenges were data migration, testing, and change management. That said, the custom code issues we did hit were painful-undocumented modifications that broke silently and required forensic debugging. If you go the custom ABAP route, invest heavily in documentation and automated testing. BTP’s advantage isn’t just upgrade safety; it’s that side-by-side extensions force you to build proper APIs and test harnesses.

8

Performance concerns about BTP are valid but solvable. For real-time validations, consider a hybrid pattern: keep a lightweight ABAP validation layer that calls BTP services asynchronously for complex rules. Use SAP Event Mesh to decouple the systems. The posting succeeds immediately with basic validations, and detailed compliance checks happen asynchronously with notifications if issues are found.

9

Having guided multiple organizations through this decision, I’ll address each of your focus areas based on real-world implementations.

Clean Core Upgrade Safety: The upgrade safety benefit is genuine but requires proper implementation. In our 1909 to 2024 upgrades, clients with disciplined use of SAP-released extension points (BADIs, BAdIs, enhancement spots) experienced minimal custom code issues-typically under 15% of upgrade effort. However, organizations with widespread modifications to standard code faced 40-50% of upgrade time on remediation. The key isn’t avoiding customization entirely; it’s using SAP’s supported extensibility framework. For financial accounting, focus on released BADIs like BADI_AC_DOCUMENT for posting validations and BADI_FAGL_DERIVE_SEGMENT for derivations. These have proven stable across multiple release upgrades.

Custom Code Technical Debt: The debt equation is more complex than “ABAP bad, BTP good.” Custom ABAP creates technical debt when it bypasses extension points, lacks documentation, or modifies core objects. Well-structured ABAP using supported interfaces actually reduces debt by keeping business logic close to data with minimal integration overhead. Conversely, BTP extensions create architectural debt: you now maintain integration points, manage authentication across systems, handle network failures, and coordinate deployments across landscapes. For financial accounting specifically, synchronous posting validations moved to BTP introduce unacceptable latency (typically 200-500ms per call). Our recommendation: keep transaction-critical logic in-system using supported extension points, and move workflow, reporting, and integration scenarios to BTP where asynchronous patterns are acceptable.

SAP BTP Extensibility: BTP shines for specific use cases: workflow automation using Build Process Automation, custom analytics using SAP Analytics Cloud integration, and external system integrations using Integration Suite. For your enhanced approval workflows, BTP is ideal-it provides visual workflow design, better integration with non-SAP systems, and independent deployment cycles. However, for real-time posting validations, BTP introduces challenges. Consider a hybrid pattern: implement a lightweight ABAP validation layer using BADI_AC_DOCUMENT that performs critical synchronous checks, then calls BTP services asynchronously via SAP Event Mesh for complex compliance validations that can complete post-posting. This gives you clean core benefits for non-critical paths while maintaining user experience for real-time operations.

Practical Recommendation: Create a decision matrix based on execution context (synchronous vs. asynchronous), data coupling (direct table access vs. API consumption), and change frequency (stable vs. rapidly evolving). Our clients have found success with roughly 60% staying in-system using supported extension points and 40% moving to BTP for workflow and integration scenarios. This balanced approach provides upgrade safety where it matters most while avoiding the performance and complexity overhead of moving everything to side-by-side extensions.