SAP S/4HANA — What It Is and How It Works

Ask ten people in an SAP project what S/4HANA actually is and most of them will give you a version of the marketing answer. Next-generation ERP. Intelligent enterprise. Built for the cloud. All of that is true and none of it tells you what changed, how the system works, or why it exists.

S/4HANA is not just ECC with a new interface. The database is different. The data model is different. The way the system handles reporting is different. These are architectural changes — and understanding them is what separates someone who can talk about S/4HANA from someone who can actually work with it.

This post explains the product — the name, the two foundations that make everything else possible, the deployment options as they actually are, and how S/4HANA fits into the broader SAP landscape.

🔗 Foundation posts

New to SAP entirely? Start with What is ERP? and then What is SAP? — those posts give you the context that makes everything here land properly. Already familiar with S/4HANA? The companion post SAP S/4HANA vs ECC — The Real Difference goes deeper on what migration actually means.

What S/4HANA actually stands for

The name is not as cryptic as it looks. S/4HANA stands for SAP Business Suite 4 SAP HANA. Break that down:

Part	What it means
S	Suite — the full set of integrated business applications (Finance, Procurement, Manufacturing, Sales, HR and more)
4	Fourth generation — the successor to SAP Business Suite, which was built on ECC
HANA	The in-memory database that S/4HANA is built exclusively on — not an option, a requirement

SAP introduced S/4HANA in February 2015. The mandatory move to HANA was deliberate — the capabilities SAP wanted to build (real-time analytics, simplified data model, embedded AI) were only possible on an in-memory database. Running S/4HANA on anything other than HANA is not supported.

The two things that make S/4HANA different

Almost everything distinctive about S/4HANA traces back to two architectural decisions. Get these, and the rest follows.

1. HANA — the in-memory database

Traditional ERP databases — including the one ECC ran on — stored data on disk. Every query had to read from disk, aggregate results, and return them. For transactional workloads, that was fine. For real-time analytics on large datasets, it was slow. The workaround was aggregate tables — pre-calculated summaries stored separately and updated in batch jobs.

HANA stores everything in RAM. Reads happen in memory, not on disk. The speed difference is not incremental — it is orders of magnitude faster for analytical queries. This eliminated the need for aggregate tables and made real-time reporting on live transactional data possible for the first time.

💡 Practical Tip

When you see S/4HANA demos showing instant financial close or real-time inventory visibility, HANA speed is what makes that possible — not a UI trick. The data is genuinely live, not pre-calculated and cached.

2. The simplified data model

Because aggregate tables are no longer needed, SAP redesigned the Finance data model from scratch. In ECC, financial data was spread across multiple tables — FI and CO were separate, reconciliation was a periodic process, and redundant data lived in summary tables like FAGLFLEXT and BSEG.

In S/4HANA, all this was replaced by a single table: ACDOCA, known as the Universal Journal. Every financial posting — general ledger, controlling, profitability analysis, asset accounting, material ledger — writes to one line item table. There is one version of the truth, always current, no reconciliation needed.

This is the change that functional consultants feel most immediately on a project. Reports that used to require a batch run are now live. Processes that used to reconcile between modules are unified. It is a genuine simplification — and it took a complete redesign to achieve.

⚠️ Warning

The simplified data model also means that ECC customisations which relied on the old table structure — FAGLFLEXT, BSEG aggregations, CO-PA summary tables — do not migrate cleanly. This is one of the most common sources of scope underestimation in S/4HANA projects.

The three ways to run S/4HANA

S/4HANA is available in three deployment models. The marketing materials make this sound like a simple cloud vs on-premise choice. The reality is more nuanced — and the differences matter significantly for what you can and cannot do.

Deployment	What it is	What it restricts	Best for
On-Premise	S/4HANA installed on your own data centre infrastructure	Nothing — full flexibility on customisation, release timing, landscape design	Large enterprises with complex customisations and strong internal IT teams
Private Cloud Edition (PCE)	SAP-managed hosting on a hyperscaler (AWS, Azure, GCP) — your own dedicated instance	Release upgrade schedule is managed by SAP; some deviation from clean core is possible but monitored	Enterprises wanting managed infrastructure without giving up customisation flexibility
Public Cloud Edition	Multi-tenant SaaS — fully standardised, SAP-managed, quarterly updates	No custom ABAP, no modifications outside the extension framework — clean core is mandatory	Organisations willing to standardise processes to SAP best practice in exchange for lower IT overhead

📌 Key Takeaway

The deployment choice is not just a hosting decision — it is a customisation philosophy decision. Public Cloud Edition requires clean core. If your business has complex custom processes that cannot be re-engineered, Public Cloud is not the right starting point. Be honest about this early. Projects that discover this in the design phase rather than the build phase save months.

What changed for users — the Fiori shift

S/4HANA is Fiori-first. That is not a preference — it is the design intent. SAP GUI still exists and still works for many transactions, but the direction of travel is clear: new functionality in S/4HANA ships as Fiori apps, not as SAP GUI transactions.

For users coming from ECC, this is the most visible change. Instead of navigating by transaction code — VA01, ME21N, FB60 — users work in role-based launchpads with tiles and app-based workflows. The access model shifts too: roles are built around what a person does, not which transaction codes they need.

For project teams, this means the security model, the training approach and the change management effort all look different from an ECC rollout. The underlying SAP authorisation model is the same — but the Fiori layer adds a frontend role on top of the backend role.

🔗 Related Reading

The Fiori design principles post covers the five ideas behind every SAP app: SAP Fiori Design Principles — The Five Ideas Behind Every SAP App . For the security model — backend roles, frontend roles, S_SERVICE object — see: SAP Security Roles and Authorisation

Where S/4HANA sits in the SAP landscape

S/4HANA is the core — the system of record for business transactions. But it does not operate alone. SAP has built an ecosystem around it.

Layer	What it is	How it connects to S/4HANA
SAP BTP	Business Technology Platform — SAP’s cloud platform for integration, extension and AI services	Extensions, integrations, and AI capabilities connect to S/4HANA through BTP. HANA Cloud on BTP can also serve as the vector store for RAG pipelines on S/4HANA data.
SAP Joule	SAP’s generative AI copilot — embedded across S/4HANA and other SAP products	Joule reads S/4HANA data and surfaces insights, automates tasks and answers questions in natural language. It is the AI interface layer on top of S/4HANA.
CDS Views	Core Data Services — the data access layer in S/4HANA, replacing direct table access	OData APIs and Fiori apps expose S/4HANA data through CDS views. Understanding CDS is essential for any developer or integration architect working on S/4HANA.
SAP Integration Suite	SAP’s integration platform on BTP — APIs, EDI, event-based integration	Connects S/4HANA to third-party systems, other SAP products and cloud services. Replaces PI/PO for modern SAP landscapes.

✅ Best Practice

Think of S/4HANA as the transactional core, BTP as the extensibility and integration layer, and Fiori as the user experience layer. Projects that try to do everything inside S/4HANA — building integrations and extensions directly in the core — create the kind of technical debt that makes upgrades painful. Clean core with extensions on BTP is the direction SAP has made clear.

At a glance — SAP S/4HANA

Concept	One-line summary
SAP S/4HANA	SAP Business Suite 4 SAP HANA — the fourth-generation SAP ERP, built exclusively on the HANA in-memory database
HANA database	In-memory database — stores data in RAM, making real-time analytics on live transactional data possible without batch processing
Universal Journal (ACDOCA)	The single financial line item table in S/4HANA — replaces multiple ECC tables, eliminates reconciliation between FI and CO
On-Premise	S/4HANA on your own infrastructure — full control, full customisation flexibility, your release schedule
Private Cloud Edition	SAP-managed hosted instance — managed upgrades, some customisation still possible
Public Cloud Edition	Multi-tenant SaaS — quarterly updates, clean core mandatory, no custom ABAP
Fiori-first	New S/4HANA functionality ships as Fiori apps — role-based launchpad replaces transaction code navigation
SAP BTP	The extension and integration platform around S/4HANA — where custom code, integrations and AI services live in a clean-core model
SAP Joule	The AI copilot embedded in S/4HANA — reads S/4HANA data and surfaces insights in natural language
Clean core	The principle that S/4HANA should remain unmodified — extensions built on BTP, not inside the core

What to take away

S/4HANA is not a rebranded ECC. The HANA database and the Universal Journal are not incremental improvements — they are architectural decisions that make a different class of capability possible. Real-time reporting, embedded AI, simplified financial close — none of that works on the old model.

The deployment choice matters more than most organisations give it credit for early in a programme. Public Cloud Edition and on-premise S/4HANA are genuinely different products in terms of what you can modify and how you extend them. Getting that choice right before design starts saves projects from the most expensive kind of course correction.

The organisations getting the most from S/4HANA in 2026 are the ones who understood the clean core principle from the start — not as a constraint, but as a design goal. When your extensions live on BTP and your core stays clean, every upgrade becomes manageable. When they do not, every upgrade becomes a project.

🔗 Related posts on this site

SAP S/4HANA vs ECC — The Real Difference — what actually changes when you migrate from ECC, technically and functionally.
SAP BTP — The Platform Explained — the extensibility and integration layer around S/4HANA.
CDS Views and the VDM in SAP S/4HANA Explained — the data access layer that underpins every Fiori app and OData API in S/4HANA.
AI in SAP — How Joule and Business AI Actually Work — how SAP’s AI layer connects to and reads from S/4HANA.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/sap-s4hana-what-it-is-and-how-it-works/