Chapter 3
Core Functional Domains
Enterprise systems are not monolithic structures. They are composed of functional domains, each responsible for a specific part of the business. Understanding these domains is not a technical requirement. It is an operational one.
In an S/4HANA migration, the functional domains define the scope of the transformation. Every process that will be migrated belongs to one or more of these domains. Every piece of master data is owned by a domain. Every integration connects domains to each other or to external systems.
The leader who does not understand the functional domains cannot make good design decisions. They cannot assess the impact of a process change. They cannot identify where a data inconsistency will surface. They cannot evaluate the risk of a configuration decision.
Understanding the domains is not about becoming a technical expert. It is about understanding where value is created, where cost is generated and where the process dependencies that determine migration success actually live.
Key Takeaway:
The functional domains are not a technical concern, they are the operational structure of the business represented in the system. Every migration decision is a domain decision. Understanding them is a leadership requirement.
"You do not need to configure the system. You need to understand what it represents."
MarvinPro_|_March_2026
marvinpro.com
In an S/4HANA environment four functional domains form the operational foundation of the system. Each has a distinct purpose. Together they represent the complete financial and operational lifecycle of the business.
FI (Financial Accounting)
Financial Accounting is where all financial transactions are recorded and consolidated. General ledger management, accounts payable, accounts receivable, financial statement reporting. Every operational activity, service delivered, supplier paid, revenue generated, ultimately results in a financial transaction recorded here.
The key insight is directional. All processes converge in Finance. If upstream processes are inconsistent, the financial data will reflect those inconsistencies. A purchase order created incorrectly in Procurement creates a financial posting problem in FI. A billing error in Sales creates a reconciliation problem in FI. The quality of Financial Accounting data is a direct reflection of the quality of every process that feeds into it.
CO (Controlling)
Controlling focuses on internal performance management. Cost allocation, profitability analysis, performance tracking across departments, regions and business units. Where Financial Accounting answers what happened, Controlling explains why it happened and where value is created or lost.
Without structured cost allocation and profitability logic, organisations lose visibility into performance at scale. The organisation that cannot see where its costs are generated cannot make good decisions about where to invest, where to reduce and where to restructure.
MM (Procurement and Inventory)
This domain governs how organisations source goods and services, manage suppliers and control inventory. The Procure-to-Pay flow where operational demand is translated into financial commitments. Purchase requisitions, purchase orders, goods receipts, invoice verification.
Procurement processes directly influence cost control, supplier relationships and financial accuracy. A poorly designed procurement process creates financial inconsistencies, supplier disputes and inventory imbalances that are expensive to resolve after the fact.
SD (Sales and Fulfilment)
This domain manages the end-to-end customer lifecycle from order creation to delivery and billing. The Order-to-Cash process. Every customer interaction, product or service follows a structured path that ultimately leads to revenue recognition.
Revenue processes must be tightly controlled to ensure accuracy, consistency and customer satisfaction. A gap in the sales process creates a billing error. A billing error creates a customer dispute. A customer dispute creates a financial reconciliation problem. The chain is direct and the cost compounds quickly.
Key Takeaway:
The four domains are interdependent. A decision in one domain creates consequences in the others. Migration design must account for these dependencies, not treat each domain as an independent workstream.
"Systems are built in modules. Businesses operate in processes. The gap between the two is where complexity begins."
MarvinPro_|_March_2026
marvinpro.com
The four domains are not independent. They are connected through end-to-end processes that cross domain boundaries and the system enforces those connections whether the organisation has designed for them or not.
Sales activities generate revenue recorded in FI, tracked in CO.
Procurement activities generate cost recorded in FI, allocated in CO, executed in MM.
Every financial transaction originates in an operational activity in SD or MM and is recorded in FI.
Controlling provides the visibility layer across all of them.
The practical implication for migration is significant. A design decision in SD, how billing is structured, how revenue is recognised, how customer credits are handled, creates configuration requirements in FI. A design decision in MM how purchase orders are approved, how goods receipts are processed creates posting logic in FI and cost allocation requirements in CO.
This means the design phase cannot be structured as four independent domain workstreams working in parallel. The domain decisions must be coordinated. The integration points must be identified and designed explicitly. The end-to-end process must be validated — not just the individual domain components.
Organisations that design each domain independently and integrate at the end discover the integration problems during cutover at the worst possible time.
Key Takeaway:
End-to-end process design across domains is more important than domain-level design within silos. The integration points between domains are where the most expensive migration problems are found and where the most valuable design work can be done.
"The system does not create connections between domains. It enforces them. Design the connections before the system does it for you."
MarvinPro_|_March_2026
marvinpro.com
Every domain needs an owner. Not a technical owner a process owner. Someone who understands the business processes within the domain, can make design decisions and is accountable for the quality of the domain's contribution to the migration.
In large organisations this is where migrations most commonly fail. The technical team owns the configuration. The project management team owns the timeline. Nobody owns the process decisions. Design questions that require a business answer wait for a business owner who is either unavailable, unclear on their mandate or unaware of the downstream implications of their decision.
The result is one of three outcomes. The technical team makes the decision without business input and gets it wrong in ways that are expensive to fix. The decision is deferred and becomes a cutover problem. The decision is made by committee slowly, inconsistently and without clear accountability.
Domain ownership solves this. Each domain FI, CO, MM, SD has a named process owner who is empowered to make design decisions, accountable for the quality of the domain's process design and responsible for validating that the system configuration matches the agreed design.
This is not an additional role. In most organisations the right people already exist. They are the senior operational leaders who run the processes every day. The migration gives them a formal mandate to do what they already know needs to be done.
Key Takeaway:
Domain ownership is a governance requirement not an optional organisational design choice. Without clear process ownership per domain, design decisions default to the technical team or to nobody. Both outcomes are expensive.
"A migration without process owners is a technical project. A migration with process owners is a business transformation."
MarvinPro_|_March_2026
marvinpro.com
In a global operational environment spanning multiple countries and business functions, a system migration revealed a problem that had been invisible for years, the organisation had no consistent definition of what constituted a cost centre.
Each region had created cost centres independently, using different naming conventions, different hierarchies and different allocation logic. The Finance team could produce reports by region. It could not produce a consolidated view of cost by function across regions because the cost centre structures were incompatible.
This was not a system problem. The legacy system had accommodated the inconsistency by allowing each region to operate its own structure. S/4HANA's Controlling module required a single, globally consistent cost centre hierarchy before the system could allocate costs across the organisation.
The Controlling domain owner once formally appointed identified the problem within the first week of the design phase. The remediation took three months. Every cost centre across every region was reviewed, reclassified and rebuilt into a consistent global hierarchy.
The work was significant. But it was work that had to be done regardless of the migration. The migration simply forced the organisation to confront what it had been avoiding.
The global cost visibility that the organisation gained after go-live the ability to see cost by function, by region and by business unit in a single consolidated view was something the organisation had wanted for years but had never been able to achieve in the legacy environment.
The migration did not just move the organisation to a new system. It gave the Finance function the foundation it needed to do its job properly.
"The migration forced the question the organisation had been avoiding for years. The answer was worth the effort."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome:
The functional domains are the building blocks of the migration. Understanding them not technically but operationally is a prerequisite for making good design decisions.
FI records everything. CO explains everything. MM controls procurement. SD drives revenue. Together they represent the complete operational and financial lifecycle of the business.
Design the domains with clear process ownership. Coordinate the integration points explicitly. Validate the end-to-end process not just the individual domain components.
The organisations that understand their functional domains before migration begins arrive at the design phase ready to make decisions. The organisations that discover them during migration make those decisions under pressure.
"FI records everything. CO explains everything. MM controls cost. SD drives revenue. Understand all four before you touch any one of them."
MarvinPro_|_March_2026
marvinpro.com