Clean core vs classic extensions for billing management upgrade - strategy debate

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

Our company is planning an S/4HANA 1909 upgrade and we’re debating extension strategy for our heavily customized billing management module. We have about 15 user exits and 8 custom function modules handling specialized invoice formatting, tax calculations for multiple countries, and integration with external credit systems.

The clean core approach sounds appealing for future upgrades, but migrating everything to RAP-based extensions and side-by-side extensibility seems like a massive undertaking. Our classic ABAP extensions have worked reliably for years. Is the clean core investment really worth it for billing customizations, or should we stick with classic extensions and deal with future upgrade complexity? What’s the real-world experience with clean core for billing scenarios?

system 2

Clean Core vs. Classic Extensions for Billing — Upgrade Strategy Assessment

Pre-Upgrade Checks (1909 Source → Target)

Before committing to either path, run these assessments against your current 1909 landscape:

  • Custom Code Migration Worklist via transaction SCMW / SAP Readiness Check — classify all 15 user exits and 8 function modules by criticality and upgrade impact rating.
  • Execute ATC (ABAP Test Cockpit) with the clean core ruleset enabled. Identify which function modules use non-released APIs, direct table access on VBRK/VBRP/VBFA, or internal SD pricing structures.
  • Map each user exit to its modern equivalent: BAdI, RAP behavior extension, or Business Event. SD billing exposes BAdIs under enhancement spot ES_FKK_BILLING and SD framework spots — verify current availability in your version.
  • Inventory integration points with external credit systems: are they synchronous RFC calls or async? This determines whether side-by-side is structurally feasible without re-architecting the handshake.
  • Check if your tax calculation modules consume TAXM or direct FI posting logic — these are highest-risk for clean core migration given country-legal volatility.

Migration Path — Numbered Sequence

  1. Triage by risk tier. Separate your 23 artifacts into three buckets: (A) safe BAdI replacement, (B) RAP/side-by-side candidates, (C) high-complexity holdovers requiring deeper redesign.
  2. Stabilize classic extensions short-term. For the 1909 upgrade itself, migrate user exits to equivalent BAdIs where a 1:1 replacement exists — this is lower risk than a full RAP rewrite mid-upgrade.
  3. Invoice formatting is the strongest clean core candidate. These are typically stateless transformations; externalize them as BTP side-by-side microservices or Adobe Forms/Smartforms replacements via output management — verify output management maturity in your target release.
  4. Tax calculation should move to SAP Tax Compliance integration or BAdI-based enhancement, not RAP initially. Country-legal logic changes frequently; keeping it in a released BAdI with documented API contracts reduces upgrade regression surface significantly.
  5. Credit system integration — replace synchronous custom function module calls with Integration Suite (CPI) iFlows if latency permits, or retain RFC with a proper API wrapper if sub-second response is mandatory. This is an architectural decision independent of clean core ideology.
  6. RAP-based extensions are appropriate for new billing capabilities post-1909 stabilization, not for migrating existing logic under upgrade pressure.
  7. Regression test billing runs with parallel ledger scenarios enabled and cross-check output against current system for same document set.

Rollback Procedure

  • Maintain transport layer separation: keep all migrated BAdIs in a dedicated software component so they can be deactivated without touching core SD configuration.
  • Before go-live cutover, preserve the original user exit implementations in a deactivated enhancement project — this allows same-system rollback without transport reversal.
  • For side-by-side integrations, implement feature toggles at the BAdI level (custom table-driven switch) so traffic can be rerouted back to classic logic within minutes without a transport.
  • Document delta between source and target behavior for each artifact — rollback is meaningless without a defined acceptance baseline.

Architectural Verdict

The clean core ROI is real but back-loaded. For a 1909 upgrade under delivery pressure, a hybrid path — BAdI migration now, selective side-by-side for formatting, RAP for net-new — is more defensible than a full rewrite. Commit to clean core as a post-upgrade modernization program, not a prerequisite.

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 full clean core for our 1909 upgrade last year including billing. Initial effort was significant - about 4 months for migration - but our recent upgrade to 2020 took only 3 weeks versus 4 months for the previous upgrade. Clean core paid off faster than expected. However, billing is trickier than other modules because many standard user exits don’t have direct RAP equivalents yet.

4

Clean core is the future, but for billing in 1909 it’s still immature. Many billing user exits like RV60AFZZ and SD_INVOICE_CREATE don’t have released APIs yet. You’ll end up writing workarounds or hybrid solutions. If you have working classic extensions and no immediate upgrade plans beyond 1909, I’d recommend staying classic for now and reevaluating at 2021 or later when the billing API landscape is more complete. SAP’s roadmap shows more billing APIs coming in 2023+.

5

The complexity depends on your specific customizations. Invoice formatting and output modifications translate well to clean core using CDS views and custom output management. Tax calculations are harder - if you’re using TAXINJ or TAXINN user exits, there’s no clean equivalent in 1909. External system integrations actually work better with clean core through OData services. I’d suggest a hybrid approach: migrate what has good API support, keep critical user exits as classic extensions temporarily.

6

The hybrid approach makes sense. Our biggest concern is the upgrade and support implications long-term. SAP keeps talking about classic ABAP becoming unsupported, but what’s the realistic timeline? Are we looking at 2-3 years or 10+ years before classic extensions become a real problem?

7

Based on SAP’s public statements and what I’ve seen at TechEd, classic ABAP won’t disappear until at least 2030, probably later. SAP knows too many customers have massive classic codebases. However, new features and optimizations are ABAP Cloud only. For billing specifically, the new advanced invoice processing features in 2023+ require clean core architecture. You won’t get left behind immediately, but you’ll miss out on innovation if you stay purely classic.

8

Think about your upgrade frequency and business needs. If you upgrade every 2-3 years, clean core ROI is questionable for 1909. If you’re on a 5+ year cycle, definitely stay classic for now. The migration effort for 15 user exits plus custom functions could easily be 6-8 months with testing. That’s significant investment for uncertain payoff in 1909 timeframe.

9

After implementing both approaches across multiple customers, here’s my comprehensive analysis of clean core versus classic extensions for billing management:

Clean Core Extension Strategy:

The clean core approach uses released SAP APIs, RAP (RESTful ABAP Programming), and side-by-side extensibility to avoid modifying standard SAP objects. For billing management in S/4HANA 1909, this means:

Advantages: Significantly faster future upgrades (we’ve seen 60-70% reduction in upgrade effort), automatic compatibility with new SAP releases, access to cloud capabilities, better performance with CDS views, and SAP support guarantees. Invoice output modifications work well through custom CDS views and Fiori elements. External integrations are cleaner using OData services instead of RFC calls.

Limitations in 1909: Many critical billing user exits lack API equivalents - specifically RV60AFZZ (pricing in billing), SD_INVOICE_CREATE, and tax calculation exits. The billing document API (I_BillingDocumentBasic) is read-only in 1909, limiting modification scenarios. Custom tax logic requires workarounds. Real-time credit integration still needs classic RFC or you must build separate microservices.

Migration effort for your 15 user exits: Estimate 4-6 months with 2-3 developers, plus 2 months intensive testing. Invoice formatting (30% of exits) migrates smoothly to custom output management. Tax calculations (40% of exits) require hybrid solutions or temporary classic retention. External integrations (30% of exits) benefit most from clean core but need complete redesign.

User Exit Migration Challenges:

The biggest challenge is that user exits provide deep hooks into SAP processes that APIs don’t always replicate. For billing specifically:

  • Document modification user exits (RV60AFZZ, RV60AFZA) have no direct API replacement in 1909
  • Pricing user exits can partially migrate to custom condition types and CDS views
  • Output determination exits work well with new output management framework
  • Account determination exits need BADI migration, not clean core
  • Tax exits remain problematic until 2021+ releases

You’ll face a “functionality gap” where classic exits did things that clean core APIs can’t yet support. Common workarounds include: keeping critical exits as classic temporarily, redesigning business processes to fit available APIs, or building side-by-side extensions with event-based triggers (adds latency).

Upgrade and Support Implications:

Long-term perspective (5-10 years): Clean core is mandatory for cloud migration and essential for efficient upgrades. SAP’s innovation roadmap focuses on ABAP Cloud capabilities. Classic ABAP will remain supported but won’t get new features.

Short-term reality (2-3 years): Classic extensions work fine and SAP must support them. You won’t face immediate technical debt. However, each upgrade cycle with classic extensions requires extensive testing and potential modifications.

Support timeline: SAP mainstream support for classic ABAP continues through 2027 at minimum, extended support likely to 2030+. But new billing features (advanced revenue recognition, subscription billing, usage-based billing) require clean core architecture starting in 2023 releases.

Recommended Strategy for Your Situation:

Given 15 user exits + 8 custom functions in billing for 1909 upgrade, I recommend a pragmatic hybrid approach:

  1. Migrate to clean core (40% of customizations): Invoice output formatting, standard report enhancements, simple data enrichment logic, external system integrations via OData. These have good API support and high ROI.

  2. Keep as classic temporarily (40%): Tax calculation exits, deep document modification logic, real-time pricing adjustments. These lack adequate APIs in 1909 and force workarounds that add complexity without benefit.

  3. Redesign with BADI migration (20%): Account determination, partner determination, credit management hooks. These have BADI equivalents that are more stable than user exits but not fully “clean core.”

  4. Plan clean core completion for 2023+ upgrade: By S/4HANA 2023, billing APIs mature significantly. Budget your next major upgrade cycle for full clean core migration when API gaps close.

Cost-Benefit Reality Check:

Full clean core migration now: 6-8 months effort, high risk of functionality gaps, benefit realized in 3-5 years.

Hybrid approach: 3-4 months effort, lower risk, partial benefits in 2-3 years, positions you for full migration later.

Stay fully classic: 1 month effort (lift and shift), no immediate risk, but next upgrade in 3-5 years will be expensive and painful.

The hybrid approach offers the best risk-adjusted return for 1909 billing scenarios. You get meaningful clean core benefits where APIs are mature, avoid forced workarounds where they’re not, and maintain a clear path to full clean core when the platform catches up to billing complexity.