SAP Concepts: SAP MM Explained: The Materials Engine

If FI is the destination — the place every transaction eventually becomes a journal entry — then MM is one of the biggest sources feeding into it. Materials Management is the SAP module that tracks every physical good a business buys, stores, moves, consumes, or sells, and translates each of those events into the financial postings FI then records.

We met MM briefly in Season 1. Episode four covered the procure-to-pay flow at a cross-module level — purchase requisition through purchase order, goods receipt, invoice receipt, and the FI postings that resolve at the end. Now we walk into MM properly. What it stores, how those records are structured, why it has so many moving parts, and the single most useful piece of vocabulary a SAP user can carry: the movement type.

This is episode two of Season 2 of SAP Concepts, and by the end you’ll be able to read an MM document the way a buyer or a warehouse clerk does — not as a row of fields but as a story about a material moving through the business.

What MM is for

Start with the brief, because MM’s design is shaped by it.

MM exists to answer four questions, accurately, at all times:

• What materials do we have, where, and in what quantity? Inventory.
• What did each unit cost us? Valuation.
• What’s incoming, and from whom? Open purchase orders, expected receipts, supplier obligations.
• What’s outgoing, and why? Issues to production, transfers between plants, scrap, sales deliveries.

Every other thing MM does — and it does a great deal — supports answering those four questions. The chart of stock balances supports the “how much do we have” question. The procure-to-pay process supports “what’s incoming.” Movement types are the language MM uses to describe every “what’s outgoing.” Valuation is how MM answers “what did each unit cost.”

Hold those four questions in mind as we walk through the module — every concept ties back to one of them.

The Material Master

The single most edited record in any SAP system is the material master.

A material master record describes one item — a raw material, a semi-finished part, a finished good, a packaging unit, a service. SAP gives every material a number (or letters, or both — your call) and a description, and from there builds out an enormous record that captures everything any module might want to know about that item.

The interesting design decision is that the master is organised into views. A material is the same item in real life, but different teams care about different attributes:

• Basic Data — name, description, base unit of measure, weights, dimensions. Everyone uses this.
• MRP views — planning rules. How is this material planned? What’s the lot size policy? Reorder point? Safety stock?
• Purchasing view — purchasing group, purchasing info, default vendor.
• Sales views — sales organisation pricing, delivery plant, item category groups.
• Plant Storage / Warehouse views — storage conditions, shelf life, hazardous-material flags.
• Accounting view — valuation class, price control, standard or moving average price.
• Costing view — overhead group, profit centre, costing lot size.

A single material can have dozens of views, each maintained by the team that owns that aspect. The accounting team configures the accounting view. The MRP planner configures the MRP views. The buyer configures the purchasing view. Together they describe one item from every functional angle.

In S/4HANA, the central app for working with the material master is Manage Material. Older systems used MM01/MM02/MM03 as the create/edit/display transactions in SAP GUI; in Fiori, the same logic is exposed through the unified app, with a tile-based view selector and inline-editable forms.

What’s worth taking away: the material master is the anchor of MM. Every transaction we’ll talk about — a goods receipt, an issue to production, a sales delivery — references a material number, and most of the relevant behaviour comes from the master’s settings, not from the transaction itself.

The Vendor Master, now Business Partner

The procurement side of MM needs a record for whoever is supplying the materials. In ECC this was the vendor master — table LFA1, transactions XK01/XK02/XK03, separate from the customer master.

In S/4HANA, vendor and customer are unified under the Business Partner object — single record, multiple roles. A company that’s both a supplier and a customer has one BP record with two roles attached. We covered this in Season 1 episode 8 (S/4HANA vs ECC); the implication for MM is that the supplier-side master data you’d have called “the vendor master” is now reached through the Maintain Business Partner Fiori app, with a procurement role that exposes the buying-relevant fields — payment terms, default delivery plant, bank details, withholding tax category.

For day-to-day purposes, MM users still talk about “vendors” and “vendor codes.” The system still works the way it did. The mechanics underneath have just been unified with the customer side.

The procure-to-pay flow, revisited

Quickly recapping S1 Ep4, because the next sections build on it:

Purchase Requisition (PR) — an internal request to buy something. Created by a planner, an end-user, or automatically by MRP. Carries the material, quantity, requested delivery date, and the requesting cost object. Has no commitment to the outside world yet.

Purchase Order (PO) — the document that goes to a supplier. Carries the same material/quantity/date plus a price agreed with the vendor and a contractual relationship. This is where the buying obligation forms.

Goods Receipt (GR) — when the materials arrive at the receiving plant, a goods receipt is posted. Inventory goes up. A GR/IR clearing account in FI gets debited (the materials are “received” but not yet “invoiced”).

Invoice Receipt (IR) — when the supplier sends an invoice, it’s posted against the PO. The GR/IR clearing account clears. AP is credited (you now owe the vendor money). The 3-way match — PO vs GR vs IR — is what allows automatic invoice processing.

This flow is the bulk of MM-driven postings. Every PO that reaches goods receipt produces an FI document. Every invoice posts another. By the time the supplier is paid, three or more journal entries have crossed the books, all triggered from the MM side.

For our purposes today, the part that matters most is what happens at the GR stage — because every GR (and every other inventory movement) carries a movement type, and movement types are MM’s defining vocabulary.

Movement types — the universal verbs of inventory

If you only learn one piece of MM vocabulary, learn movement types.

A movement type is a three-digit code that tells the system what kind of inventory event is happening. Every goods movement — into stock, out of stock, between locations, between materials, scrap, sample — uses a movement type. The movement type drives:

• Which stock account gets debited or credited
• Whether the movement increases or decreases unrestricted stock
• Which fields are required on the document
• Whether reversal is allowed and via which counter-movement type

A few you’ll see in every SAP shop:

• 101 — Goods receipt for purchase order. The most common single movement type in the system. Inventory increases; GR/IR clearing is debited.
• 102 — Reversal of GR for PO. The counter-movement to 101.
• 161 — Goods return to vendor. The “we got it but it was wrong” event.
• 261 — Goods issue to production order. Materials leave inventory and are consumed by manufacturing.
• 262 — Reversal of issue to production order.
• 311 — Stock transfer between storage locations within a plant. No financial impact (same plant, same valuation), just a location change.
• 351 — Stock transfer to stock-in-transit, plant-to-plant. Used in the first half of an inter-plant transfer.
• 501 — Goods receipt without a purchase order. Used for free-of-charge deliveries, samples, miscellaneous receipts.
• 551 — Scrap. The material is being written off.
• 601 — Goods issue for delivery. When SD ships goods to a customer, this is the MM-side posting.

The first digit usually hints at the family — 1xx is receipts, 2xx is issues, 3xx is transfers, 5xx is “other receipts,” 6xx is “other issues.” But each shop builds its own habits on top of the standard set, and many install custom movement types for special cases.

Why this matters for everything else in S2: when we cover PP in episode four, every production confirmation produces an MM goods movement under a movement type — typically 261 (issue to order) and 101 or 131 (receipt of finished good). When we cover SD in episode three, every delivery produces a 601. When we get to CO in episode five, every movement type carries a CO posting that updates inventory valuation in the universal journal.

Movement types are MM’s verbs. Once you can read them, you can read the rest of the season.

Valuation: moving average vs standard

MM doesn’t just track how much of each material you have. It tracks what each unit is worth — and the answer to that question is more subtle than it sounds.

There are two common price control strategies in SAP:

• Moving Average Price (MAP, V) — the per-unit value of a material is recalculated every time stock comes in at a different price. If you bought 100 units at $10 and then 100 more at $12, your moving average is $11. The system continuously updates the value as receipts and issues happen. Used most often for raw materials and traded goods, where the actual cost varies and you want the books to reflect that.
• Standard Price (S) — the per-unit value is fixed at a predetermined “standard.” Receipts at a different actual price post the difference to a price-difference account, but the inventory value stays at standard. Used most often for finished and semi-finished goods, where you want a stable cost for product costing and variance analysis.

The choice is configured per material via the price-control field on the accounting view. Standard suits manufactured items because variance analysis only makes sense against a stable target; moving average suits commodity-like materials because their actual cost fluctuates and the books should track reality.

In S/4HANA the Material Ledger is mandatory and always-on, so every material additionally carries values in up to three currencies — local, group, hard. This is the change we covered in S1 Ep8, and it means cross-border valuation, parallel-currency reporting, and (optionally) actual costing all become available without separate configuration.

MRP — the planning engine

MM also hosts Material Requirements Planning (MRP), the algorithm that decides what to buy and what to make.

The premise is simple. The system knows what it needs (sales orders, planned demand, safety stock targets), it knows what it has (current inventory), and it knows what’s coming (open POs, planned production). Subtract the demand from the supply, walk forward in time, and any time supply dips below requirements, MRP proposes an action — a purchase requisition for buy parts, a planned order for make parts.

In ECC, MRP ran as a batch job, typically overnight, plant by plant, sometimes for hours. In S/4HANA, the MRP algorithm has moved into HANA itself — what SAP markets as MRP Live. A planner can rerun a single material in seconds; a full plant runs in minutes. The same logic, the same outputs, but the wait is gone.

We won’t go deeper into MRP today — it’s a sub-module of its own, with lot-sizing procedures, planning strategies, master production schedules, and a lot of supply-chain theory underneath. For an intro to MM, the takeaway is: MM is also a planning module, not just a record-keeping one. The records exist to drive the planning.

The star screen — Manage Material + the movement-type lens

For Episode 1 we picked Manage Journal Entries as FI’s star screen. For MM, the canonical day-to-day app is Manage Material, the consolidated Fiori app for material masters.

It’s a tile on the launchpad. Click it and you get a filterable list of materials by plant, type, valuation class, status, and a couple dozen other dimensions. Click a material and you get the full master — basic data at the top, then expandable views for accounting, MRP, sales, purchasing, plant data, and costing. Inline edits go straight into the master, with checks that the relevant authorisation profile allows it.

Sitting next to Manage Material in the planner’s launchpad are the inventory and movement-type apps: Stock — Single Material, Material Documents, Manage Material Inventory. Movement-type-aware reports replace the older MMBE / MB51 transactions of ECC. Each lists the movement type alongside the document number, the material, the quantity, the affected location — letting a planner trace any inventory question back to the originating event.

The episode plan calls for screen-time on both: Manage Material as the master-record front door, and a movement-type list as the operational lens.

What we’re deliberately not covering

MM is one of the largest modules in SAP. Several pieces sit at the edge of “intro” and “advanced”:

• Purchasing Info Records (PIR), source lists, quota arrangements. The system that decides which vendor a PR/PO goes to when there’s a choice. Real, configurable, beyond an intro.
• Release strategies. Multi-level approval workflows for purchase requisitions and orders. Configured via a release strategy with classification — every shop has a different version of this.
• Batch management. When materials need to be tracked by batch (food, pharma, chemicals), MM extends with batch master records and batch-aware movement types. A whole world of its own.
• Serial number management. When individual units are tracked (high-value equipment, regulated products), every unit gets a serial number that follows it through every movement.
• EWM (Extended Warehouse Management). A separate, much larger module for big warehouses — bin-level tracking, wave-picking, RF/scanner integration. EWM and MM-Inventory Management coexist in S/4HANA.
• Subcontracting, consignment, special stock types. Each is an ownership-and-location pattern that MM models with dedicated movement types and master-data settings.

If you’re working with MM day-to-day, you’ll meet all of these. For the introductory map, naming them is enough.

Why MM is the engine

Step back to where we started.

MM is the engine because every other module either feeds it, draws from it, or both. PP consumes raw materials through MM (movement type 261) and produces finished goods through MM (movement type 101 or 131). SD delivers finished goods through MM (movement type 601). FI receives every movement as a posting that lands in ACDOCA. CO uses MM’s valuation to compute product cost.

A material master is the most-shared piece of master data in any SAP system. A movement type is the most-used piece of vocabulary. Together, they’re what make the rest of the operational modules possible.

When the rest of S2 talks about SD deliveries, PP confirmations, or CO product costs, every flow we trace will pass through an MM document somewhere. Knowing how MM stores and moves materials is the prerequisite for following the rest.

What’s next

That’s MM. Next episode we move to the revenue side: SD — The Revenue Side. Customers, sales documents, deliveries, billing — and the pricing procedure that makes SD configurable in ways the rest of SAP isn’t.