SAP Modules Explained — FI, CO, MM, SD and the Rest

Someone on the project reads a support ticket and says, “that’s an MM issue, escalate it to FI.” The end user has no idea what either of those means. Three months into most projects, honestly, neither do half the people saying it out loud.

I have sat in enough war rooms to know that “module” gets thrown around long before anyone explains what it actually is. New consultants nod along.

Experienced consultants from one module quietly admit they have never understood another. Nobody wants to be the one who asks.

This is the post I wish someone had handed me on day one. What FI, CO, MM and SD actually do, how they hand work to each other behind the scenes, and why SAP itself has quietly moved on from the word “module.”

It matters beyond the terminology too. Whole careers are still built around these four letters — “SAP FI consultant,” “SAP MM consultant” — and knowing where one module’s job actually ends and another’s begins is the difference between confidently scoping a project and guessing.

🔗 Related Reading

This post builds on What is SAP? and SAP S/4HANA vs ECC — The Real Difference . If you are new to SAP, start there for the bigger picture before this one.

What a module actually means (and why SAP has moved on from the word)

In classic SAP ECC, a module was a functional slice of one shared system. FI handled the books. MM handled procurement and stock.

SD handled sales. Each had its own configuration, its own transaction codes, its own consultants — but they all sat on the same database and passed data to each other constantly.

That word, module, is doing a lot of work it was never designed for. It describes how SAP organised configuration menus in the 1990s. It has become how entire careers, job titles and consulting practices are structured, thirty years later.

With S/4HANA, SAP formally retired the term. The functional areas are now grouped into Lines of Business — Finance, Sourcing and Procurement, Manufacturing, Supply Chain, Sales and Human Resources among them.

FI and CO sit inside the Finance LoB. MM sits inside Sourcing and Procurement. SD sits inside Sales.

Nobody on a project actually talks this way. Job adverts still say “SAP MM consultant.” Teams are still structured around FI, CO, MM and SD.

The old names survive because they describe skillsets and org charts, not because they describe the software anymore.

Knowing both names matters. The Line of Business is what you will see in S/4HANA documentation, licensing and roadmap material. The module name is what you will hear in every meeting, every ticket and every job description for years to come.

I don’t fight the old terminology on client projects, and I wouldn’t recommend you do either. Say “MM” in a status call and everyone in the room knows exactly what you mean.

Say “Sourcing and Procurement Line of Business” and you will get a few blank stares before the conversation moves on. Use the module name to communicate, and the Line of Business name when you’re reading SAP’s own documentation, so you’re not searching for a term that no longer exists.

FI — Financial Accounting

FI is the system of record for everything with a legal or statutory obligation attached to it. General ledger, accounts payable, accounts receivable, asset accounting, bank accounting. If an auditor could ask to see it, it almost certainly lives in FI.

A vendor invoice posted through FB60 creates a liability. A customer payment cleared through F-32 reduces a receivable.

An asset acquisition posted through the Asset Accounting sub-ledger depreciates automatically every period. None of this is optional configuration — it is how the business proves its financial position.

Depreciation is a good example of how mechanical FI actually is once it’s configured. Set up an asset class correctly and the system calculates and posts depreciation automatically, period after period, with no manual intervention.

Get the asset class wrong, and you won’t notice until an auditor or a year-end close does.

Since S/4HANA, FI runs on a single line-item table called the Universal Journal — ACDOCA. Every FI posting and every CO posting land in the same table, tagged with the same fields.

This sounds like a technical footnote. In practice, it is the reason FI and CO stopped needing separate reconciliation runs.

💡 Practical Tip

Most FI reconciliation problems people bring to me at month-end are not FI bugs. They trace back to a wrong document type, a missing cost object, or an account determination setting nobody reviewed since go-live. Check configuration before you assume the ledger is wrong.

CO — Controlling

CO is where FI’s confusion usually starts. Read the acronym and it sounds like a sibling of FI. In practice, the two answer completely different questions.

FI answers: what happened, and can we prove it to an auditor. CO answers: where is our money actually going, and how do we plan around it.

FI is external and statutory. CO is internal and managerial. A finance director needs both, but for different meetings.

CO works through cost centres, profit centres and internal orders — structures that let you slice spend and profitability by department, project or product line, regardless of how the legal books are organised. Profitability Analysis, CO-PA, takes this further and lets a business see margin by customer or product segment, not just by company code.

Concept	Purpose
FI	External, statutory reporting. What the auditor and the tax authority see.
CO	Internal, managerial reporting. What the business uses to plan and control cost.
Universal Journal (ACDOCA)	The shared line-item table since S/4HANA that carries both FI and CO data together.

⚠️ Warning

Treating FI and CO as “basically the same module” is the most common scoping mistake I see from junior consultants. A client asking for cost centre reporting is asking CO a question. Route it to a pure FI resource and you will burn a sprint before anyone notices the mismatch.

MM — Materials Management

MM runs procurement and inventory. Vendor master data, purchase requisitions, purchase orders, goods receipt, inventory valuation, invoice verification — the entire Procure-to-Pay chain lives here.

A buyer raises a purchase order in ME21N. A warehouse team posts the goods receipt in MIGO, which moves stock and, just as importantly, fires an automatic FI posting behind the scenes.

Accounts payable verifies the vendor invoice in MIRO, matching it against the PO and the goods receipt before it is ever cleared for payment.

In S/4HANA branding, this sits inside the Sourcing and Procurement Line of Business. On every project I have worked, people still call it MM, and will for a long time yet.

SD — Sales and Distribution

SD runs the opposite flow — Order-to-Cash. Inquiry, quotation, sales order, delivery, billing. Every step a customer’s order takes from “we would like to buy this” to “the invoice has been paid” passes through SD.

A sales order is created in VA01. A warehouse team picks and ships against a delivery document created in VL01N.

Billing generates the invoice in VF01 — and that single transaction is where SD hands off to FI, posting revenue automatically, and to CO, updating the profitability segment behind the scenes.

Credit management sits at the boundary between SD and FI too. A customer’s credit limit, checked automatically during order creation, is really an FI risk control wearing an SD transaction code.

How FI, CO, MM and SD actually connect

This is the part the generic explainer articles skip, and it’s the part that actually matters on a project. Modules do not work in isolation. Every meaningful business process crosses at least two of them, usually three.

Procure-to-Pay runs through MM and lands in FI. A purchase order in ME21N has no financial impact yet — it is a commitment, not a cost.

The goods receipt in MIGO is where inventory value moves and FI posts a stock account entry automatically.

The invoice verification in MIRO is where the vendor liability lands in FI, and where CO picks up the cost if it hits an expense account rather than a stock account.

Order-to-Cash runs through SD and lands in both FI and CO. The sales order and delivery are logistics steps with no accounting entry. The billing document in VF01 is the trigger — it posts revenue to FI and updates the profitability segment in CO-PA in the same transaction.

📌 Key Takeaway

Almost every “which module owns this” argument I have watched on a project turns out to be a document flow question, not a module question. Trace the process — PO to goods receipt to invoice, or sales order to delivery to billing — and the actual root cause usually reveals itself before anyone has to escalate.

I once watched a two-week standoff between an MM team and an FI team over a goods receipt posting to the wrong account. Both sides were convinced it was the other team’s configuration.

It turned out to be a single missing entry in the account determination table, OBYC — an FI-owned setting that MM transactions rely on every time stock moves.

Nobody thought to check it because “it’s a goods receipt, that’s MM.”

✅ Best Practice

Before assigning a ticket to a module team, trace the document flow first. An MM goods receipt posting to the wrong general ledger account is not an MM configuration problem — it is an account determination setting in FI, maintained in transaction OBYC. Skipping this step is how tickets bounce between teams for a week.

The rest of the map — PP, WM/EWM, QM and HXM

FI, CO, MM and SD cover the core of most implementations, but they are not the whole system. A handful of others come up constantly enough to be worth a quick map, even without the full depth.

Module	What it covers	Where you’ll meet it
PP (Production Planning)	Manufacturing scheduling, bills of materials, routing, capacity planning. Sits inside the Manufacturing Line of Business.	Any project with a factory floor — make-to-order or make-to-stock production.
WM / EWM (Warehouse Management)	Physical storage, picking strategies, warehouse tasks. Classic WM is being phased out in favour of embedded Extended Warehouse Management, under the Supply Chain Line of Business.	Distribution centres and complex warehouse operations — increasingly EWM-only on new S/4HANA implementations.
QM (Quality Management)	Inspection plans, quality notifications, certificates of analysis.	Regulated manufacturing, pharma, food and automotive supply chains.
HCM / HXM (Human Capital Management)	Core HR, payroll, organisational management. SAP’s own positioning is clear: no significant new functionality is being added to on-premise HCM within S/4HANA, and the direction of travel is SAP SuccessFactors for cloud HR.	Legacy HR processes still running on-premise, migrating toward SuccessFactors.

📝 Note

This is a map, not a syllabus. PP, EWM and QM each deserve — and will get — their own dedicated posts. Treasury, Project System and Plant Maintenance exist too and are just as easy to bump into on a real project.

At a Glance — SAP Modules

Concept	One-line summary
Module (legacy term)	The ECC-era name for a functional slice of SAP — still the working vocabulary on every project.
Line of Business (LoB)	S/4HANA’s official grouping of the same functional areas — the term you’ll see in documentation and licensing.
FI	External, statutory financial accounting — the system of record an auditor can rely on.
CO	Internal, managerial cost and profitability reporting — used for planning and control.
Universal Journal (ACDOCA)	The single line-item table since S/4HANA carrying both FI and CO postings together.
MM	Procurement and inventory — runs the Procure-to-Pay process.
SD	Sales order through billing — runs the Order-to-Cash process.
PP	Manufacturing scheduling and production planning.
WM / EWM	Physical warehouse operations — EWM is the current direction of travel.
QM	Quality inspection and certification across procurement, production and sales.
HXM	Core HR and payroll — SAP is steering on-premise customers toward SuccessFactors.

What to take away

Knowing the module name someone shouts across a war room does not tell you where a fix actually lives. Knowing the document flow does — PO to goods receipt to invoice, or sales order to delivery to billing.

That is the real shift S/4HANA made, whether or not anyone updates their job title to match it. The Universal Journal quietly merged FI and CO into one shared table. The old module boundaries were always more about how consulting teams are organised than about how the system actually processes a transaction.

The next time someone tells you “that’s an MM issue,” ask which transaction failed and trace it forward. You will find the real owner faster than the org chart ever will.

🔗 Related Reading

SAP S/4HANA vs ECC — The Real Difference — the architectural shift that reorganised these modules into Lines of Business in the first place.
SAP Integration Patterns — The Decisions That Matter — how these same modules exchange data with systems beyond SAP itself.
SAP Security Roles and Authorisation — the roles built around these modules are exactly what PFCG authorisations are designed to control.
SAP BTP — The Platform Explained — where SAP’s cloud extensions sit alongside the core modules covered here.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/sap-modules-explained-fi-co-mm-sd-and-the-rest/