SAP’s clean core mandate finally asks the right architectural question. It tells organisations that years of revenue logic embedded directly into ERP — the custom pricing rules, the complex bundling logic, the deal-specific approval workflows — have made S/4HANA migrations expensive, slow, and brittle. The instruction is to move that logic out. What it does not answer is where that logic should go.
That gap matters. Getting the destination wrong means recreating the same problem in a different system.
What clean core actually demands
The premise behind clean core is sound. SAP ECC environments became difficult to migrate not because the business was complex, but because complexity was expressed in the wrong place. Revenue logic — the rules that govern how a business prices, sells, bundles, and bills — was layered directly into ERP as custom code, ABAP modifications, and extended configurations. Every S/4HANA migration inherits that weight.
Clean core asks businesses to externalise that logic. Keep the ERP lean, stable, and close to standard. Move execution behaviour to the side. Only 8% of SAP customers complete migrations on schedule, and the blast radius of accumulated revenue customisation is a leading reason why. Clean core is a direct architectural response to that reality.
The discipline is correct. The question that follows — where does the externalised logic live? — is where most approaches go wrong.
Why SAP BTP is not the answer
SAP’s own answer to clean core extensibility is SAP Business Technology Platform. BTP gives organisations a place to build extensions that sit outside the ERP core but remain within the SAP ecosystem. For some technical integrations, it is a reasonable choice. For revenue execution logic, it is a significant mismatch.
Revenue execution is not an extension problem. Extensions handle individual processes — a custom field here, a workflow trigger there. Revenue execution is the full motion: how a product is configured, how a deal is structured, how a contract is activated, how billing is triggered, how changes cascade across a customer relationship. That motion needs a purpose-built execution substrate, not a general-purpose development platform.
BTP also reproduces the dependency dynamic that clean core is supposed to resolve. Revenue teams still route changes through SAP specialists. Motions still require development cycles. The blast radius moves address but does not shrink. For enterprises already managing unpredictable SAP subscription costs, adding BTP as the execution layer compounds the lock-in rather than reducing it.
Where revenue execution logic belongs
Revenue execution logic belongs in a layer designed specifically to model and run it. That is not a cloud development platform, and it is not another ERP. It is a dedicated execution layer that sits between business intent and the ERP record — receiving instructions from sales systems and AI models, running the governed logic that determines what actually happens, and writing the outcome to ERP as a clean, standard transaction.
viax is that layer. It models any revenue motion — pricing, bundling, contracting, billing, subscription management — as governed, deterministic execution. Business teams describe the motion. viax runs it. ERP records the result. The core stays clean because execution never touches it. When a motion changes, the change happens in viax, not in SAP.
This is the architectural answer clean core has been waiting for. The logic that should never have lived in ERP now has a proper home — one purpose-built for the speed, complexity, and governance that revenue execution requires.
What this means for the S/4HANA transition
For organisations navigating the move to S/4HANA, viax changes the calculus of the migration itself. Revenue execution logic that would otherwise require months of analysis, remediation, and re-implementation in BTP or a replacement system can instead be modelled in viax before the migration begins. The ERP core arrives at S/4HANA clean — not because the business simplified its revenue motions, but because those motions now live where they belong.
The transition also becomes less all-or-nothing. Organisations running complex ECC estates with significant revenue customisation can externalise execution incrementally, motion by motion, before committing to the full migration timeline. The 3–5× timeline overrun that defines most revenue change programs routed through ERP collapses when execution logic is no longer locked inside the system being migrated.
Clean core and viax are not competing approaches. Clean core defines what ERP should not contain. viax defines where that content goes.
The right execution architecture makes SAP’s path forward faster, cheaper, and lower risk — and it leaves the business free to change revenue motions without waiting on ERP release cycles to catch up.
