SAP modules explained: a map of the SAP areas

SAP modules are the functional building blocks of an SAP system: each one covers a single business domain — finance, procurement, manufacturing, human resources — or a single technical layer, with its own configuration, data and specialists. This guide lists the modules practitioners actually name, grouped the way the SAP World Map groups professional areas — business and technology — and links each one to a deeper explanation.

Are SAP modules still called modules?

In conversation yes, in SAP's own naming no. Practitioners still talk in module codes — "she's an FI consultant", "we need someone for PP" — because the codes are short and understood everywhere, while the vendor now names solutions, cloud products and lines of business. Read a code as shorthand for a domain of processes rather than a box of software: the FI someone means today is the finance capability of a current system, wherever it runs (what the S/4HANA era changes). The taxonomy below says "areas" for the same reason — the domain outlives the product name.

Business areas

These model what a company does — the processes it would still have if it ran on paper. The classic code sits beside the area name, because both are in daily use.

Finance: FI — general ledger, receivables/payables, asset accounting, closing
Controlling: CO — cost centres, internal orders, product costing, profitability
Treasury: cash, liquidity, banking and financial risk management
Procurement: classically MM — purchasing, sourcing, invoice verification
Supply Chain & Logistics: warehousing, transport, inventory and planning
Manufacturing: PP — production planning, execution and shop-floor integration
Sales: SD — orders, pricing, deliveries and billing
Service: field service, in-house repair and service contracts
Asset Management: PM — plant maintenance and enterprise assets
Human Capital Management: HCM and SuccessFactors — HR, payroll, talent
Customer Experience: CX — commerce, marketing, sales and service clouds
Project Systems: PS — project structures, budgeting and settlement
Quality Management: QM — inspections, notifications and quality control
Industry Solutions: IS-U, IS-Retail, banking, healthcare and other industry flavours

Technology areas

These model how the system is built, run and kept honest, and they cut across every business area: a security or master-data specialist touches finance and logistics processes in the same week.

BTP: SAP Business Technology Platform — extensions, apps and services around the core
Integration: connecting SAP to everything else — middleware, APIs, events
Development: ABAP and modern SAP development — extending the standard
Data & Analytics: reporting, warehousing, planning and analytics
Basis & Platform: the system layer — installation, operation, performance, transports
Security & Authorizations: roles, profiles and keeping access honest
Governance, Risk & Compliance: GRC — access risk, controls and audit
Master Data Governance: MDG — one truth for materials, partners and finance data

How the areas connect in one system

No area works alone — one document travels across several. The chains everyone learns eventually:

Order to cash: a sales order in SD reserves stock, triggers a delivery, and posts revenue and receivables in FI — which CO reads as margin.
Procure to pay: a requisition in MM becomes a purchase order and a goods receipt, QM may hold the stock for inspection, and FI settles the invoice.
Plan to produce: a production order in PP consumes materials, collects the costs CO settles, and runs on equipment PM keeps available.
Underneath all of them: the master data every document references and the authorizations deciding who may post.

That interlock is why the hardest defects sit on boundaries — a document that will not post because a setting two areas away is wrong — and why interviewers ask you to walk a process end to end rather than name a transaction (what interviews look like). The shared project vocabulary pays off as early as your own area does.

How to read this as a career map

Most SAP professionals anchor in one or two areas and stay adjacent: finance people move between FI, CO and Treasury; logistics people between Procurement, Supply Chain and Manufacturing; technologists between Development, Integration and BTP. Depth plus a credible neighbour reads stronger than a long list of labels, because work is staffed per area — someone has to own the finance stream. Choosing is less about the software than about which part of a business you want to understand deeply: start from knowledge you already have (which area to learn first), then grow into pairs that share a process boundary (combinations that work). The getting-started guide maps common backgrounds onto areas.

What an area name does not tell you

It says what you work on, not what you do with it. One area carries several jobs: Procurement can mean the consultant who configures purchasing, the developer who extends it, the analyst who writes the requirement, or the support specialist who keeps it running through period-end. Read a job ad as area plus role — the roles guide covers the titles, functional vs technical covers the split most people get wrong — and add the employer, because the same MM work feels different at an integrator, in an in-house team and at an AMS provider.