🛒 SAP SD and MM Business Scenarios - What They Are and Why They Matter
Today we are going to explore SAP SD (Sales And Distribution) and SAP MM (Materials Management) business scenarios with real-time practical examples. SAP SD and SAP MM are two of the most widely implemented functional modules in the entire SAP landscape, and they are tightly integrated with each other and with the FI (Finance) module. Together they power the two most fundamental commercial processes in any business: selling goods or services to customers (handled by SD) and procuring materials from vendors to fulfil those sales and keep the warehouse stocked (handled by MM). Understanding how these modules work in practice - not just in theory - is essential for any SAP consultant, end user, or fresher starting their SAP career. In this comprehensive tutorial we cover the core functions of both modules, walk through the complete Order-to-Cash (OTC) cycle in SAP SD and the complete Procure-to-Pay (P2P) cycle in SAP MM, explain how the two modules integrate at every touchpoint, and illustrate everything with realistic Indian business scenarios using our fictional company Arjun Industries Ltd.
SAP SD handles the customer-facing sales cycle while SAP MM handles the vendor-facing procurement cycle — both feeding into SAP FI for financial postings.
SAP SD - Sell to Customers
SAP SD covers everything from customer inquiry and quotation through sales order, delivery, goods issue, billing, and payment receipt. It is the customer-facing commercial engine of SAP.
SAP MM - Buy from Vendors
SAP MM covers the complete procurement cycle from purchase requisition and purchase order through goods receipt, invoice verification, and vendor payment — the supply side of any business.
SD + MM Integration
SD and MM integrate continuously: stock sold through SD reduces MM inventory; third-party sales in SD trigger automatic purchase orders in MM; pricing from MM flows into SD billing documents.
🛍️ SAP SD (Sales And Distribution) - Core Functions and Key Concepts
SAP SD — Sales and Distribution — is the SAP module that manages every aspect of a company's relationship with its customers from the first point of contact all the way through to cash collection. It sits at the front end of the supply chain, and when it is correctly configured and integrated, a single sales order created in SD can automatically trigger stock checks, deliveries, billing, and financial postings across multiple SAP modules without any manual re-entry of data.
What SAP SD Manages
The SD module covers five main business areas: Sales Order Management (creating and tracking customer orders, pricing, discounts, and credit checks), Delivery and Shipping (picking, packing, goods issue, and shipping coordination), Billing and Invoicing (generating billing documents, credit and debit memos, and pro-forma invoices), Pricing and Condition Records (the complex pricing engine that applies customer-specific prices, discounts, taxes, freight, and surcharges), and Customer Master Data (maintaining the sold-to, ship-to, bill-to, and payer partner functions for every customer). A well-configured SD system also handles credit management, output determination (printing or emailing documents), and availability checking (ATP — Available to Promise) by querying the MM inventory in real time.
What it does: The sales order is the central document in SAP SD. It captures what the customer wants to buy, at what price, by when, and to which delivery address. Every downstream SD document — delivery, goods issue, billing — traces back to the sales order.
Real-world example: Arjun Industries Ltd receives an order from its dealer Mehta Distributors for 500 units of Industrial Pump Model A at a negotiated price of ₹18,500 per unit. A sales order is created in VA01, the system checks stock availability via ATP, applies the customer-specific pricing condition, runs a credit check, and confirms the order.
T-Codes: VA01 (Create), VA02 (Change), VA03 (Display)What it does: Once a sales order is confirmed, the next step is creating an outbound delivery to organise the physical movement of goods from the warehouse to the customer. The delivery document controls picking (selecting the right goods from the right storage location), packing, and finally the goods issue — the point at which stock is reduced in MM inventory.
Real-world example: The warehouse team at Arjun Industries uses VL01N to create the outbound delivery for Mehta's order, picks 500 units from storage location 001A, and posts the goods issue. The moment GI is posted, MM inventory drops by 500 units and an accounting entry debits Cost of Goods Sold.
T-Codes: VL01N (Create Delivery), VL02N (Change/Post GI), VL06 (Monitor)What it does: After goods issue is posted, SD creates the billing document — the customer-facing invoice. The billing document triggers an automatic accounting document in FI that debits the customer receivable account and credits the revenue and tax accounts. This is the SD-FI integration point.
Real-world example: After the 500 pumps are despatched, the billing clerk runs VF01 to create an invoice for ₹92,50,000 (500 × ₹18,500) plus 18% GST. SAP automatically posts ₹92,50,000 to revenue, ₹16,65,000 to GST payable, and the gross amount of ₹1,09,15,000 to Mehta Distributors' receivable account in FI — all from a single click.
T-Codes: VF01 (Create Billing), VF02 (Change), VF31 (Output)What it does: SAP SD's pricing engine applies a sequence of condition types — base price, customer discount, freight surcharge, tax — to calculate the final price on every sales order and billing document automatically. Condition records are maintained using VK11 and can be set for specific combinations of customer, material, sales organisation, and validity period.
Real-world example: Arjun Industries has agreed to give Mehta Distributors a 5% annual contract discount on all pumps. This is recorded in VK11 as a condition record for condition type K007 (Customer Discount) valid for the current financial year. When any sales order is created for Mehta, the 5% discount is applied automatically without any manual entry by the sales team.
T-Codes: VK11 (Create), VK12 (Change), VK13 (Display)Key SAP SD Concept — Partner Functions: Every customer in SAP SD can have up to four different partner roles on a single sales order: the Sold-to Party (who places the order), the Ship-to Party (where goods are delivered), the Bill-to Party (who receives the invoice), and the Payer (who actually makes the payment). In many small businesses these are all the same company, but for large corporates they can all be different entities — and SAP handles this automatically using partner determination procedures.
🔄 The Complete Order-to-Cash (OTC) Cycle in SAP SD - Step by Step
The Order-to-Cash (OTC) process is the end-to-end business cycle that starts when a customer decides to buy and ends when the company receives payment and clears the receivable in FI. In SAP, every step in OTC creates a linked document — and this document chain is what allows complete traceability and auditability of the entire transaction. Let us walk through the complete OTC cycle using our Arjun Industries scenario.
🏭 Scenario: Arjun Industries Ltd — Order from Mehta Distributors
Company: Arjun Industries Ltd | Customer: Mehta Distributors, Mumbai | Product: 500 units of Industrial Pump Model A | Base Price: ₹18,500/unit | Customer Discount: 5% | Tax: 18% GST | Total Invoice Value: approx. ₹1,09,15,000
Follow this scenario step by step through the entire OTC cycle below. Each step creates a linked SAP document that you can trace from the final invoice all the way back to the original customer inquiry.
Customer Inquiry (Optional Pre-Sales)
Mehta Distributors contacts Arjun Industries asking for pricing and availability on 500 Industrial Pump Model A units. A sales inquiry is recorded in SAP to document the customer's interest and serve as the reference for the next step. This step is optional but useful for tracking pre-sales activities and conversion rates.
T-Code: VA11 (Create Inquiry) | Document Type: INQuotation Creation
Based on the inquiry, the sales team creates a formal quotation for Mehta Distributors confirming 500 units at ₹18,500 each with a 5% discount, valid for 30 days. The quotation can be printed and emailed to the customer directly from SAP using the output determination framework. When Mehta accepts, the quotation is referenced to create the sales order.
T-Code: VA21 (Create Quotation) | Document Type: QTSales Order Creation
Mehta Distributors confirms the order. The sales team creates a standard sales order in VA01 with reference to the quotation. SAP automatically copies all pricing, customer data, and material data from the quotation, runs an ATP check against MM inventory to confirm that 500 units are available by the requested delivery date, and performs a credit check against Mehta's credit limit maintained in FI. If the ATP and credit checks pass, the order is confirmed with a delivery schedule.
T-Code: VA01 (Create Sales Order) | Document Type: OROutbound Delivery Creation
On the confirmed delivery date, the warehouse receives the picking list. Using VL01N, the system creates an outbound delivery document referencing the sales order. The delivery document instructs the warehouse on what to pick (material 500001, 500 units), from which storage location (Warehouse 1001, Storage Location 001A), and to which shipping point. Transfer orders (TO) are created in WM if extended warehouse management is active.
T-Code: VL01N (Create Outbound Delivery) | VL10 (Mass Processing)Goods Issue (GI) Posting
After picking is confirmed, the goods issue is posted in VL02N. This is the critical inventory movement — movement type 601 in MM reduces the unrestricted-use stock by 500 units. Simultaneously, an accounting document is automatically posted in FI: Cost of Goods Sold account is debited and the Finished Goods Inventory account is credited. This is the first of two SD-FI integration points in the OTC process.
T-Code: VL02N → Post Goods Issue | MM Movement Type: 601Billing Document Creation
Once goods issue is posted, the billing document (customer invoice) can be created. In VF01, the billing clerk selects the delivery for billing and the system generates a billing document that copies all pricing from the sales order, calculates the final invoice value including taxes, and immediately creates the accounting document in FI. The FI posting debits the customer receivable (Mehta Distributors) and credits revenue (₹92,50,000) and GST payable (₹16,65,000). The invoice can be emailed directly to Mehta from SAP.
T-Code: VF01 (Create Billing) | VF04 (Billing Due List)Payment Receipt and Clearing
Mehta Distributors makes payment within the agreed credit period. The FI team uses F-28 (Incoming Payments) to post the payment against the open receivable. The customer's account is cleared, and the AR (Accounts Receivable) balance returns to zero for this transaction. The OTC cycle is now complete and fully documented with a traceable chain of documents from inquiry through to payment.
T-Code: F-28 (Incoming Payment) | FBL5N (Customer Line Items)Document Chain Traceability: One of SAP SD's most powerful features is the complete document chain. Starting from any billing document, you can click through to the delivery, the goods issue accounting document, the sales order, the quotation, and even the original inquiry — all linked automatically. This makes auditing, dispute resolution, and reporting straightforward compared to manual or disconnected systems.
📦 SAP MM (Materials Management) - Core Functions and Key Concepts
SAP MM — Materials Management — is the procurement and inventory engine of SAP. While SD manages the outbound flow of goods to customers, MM manages the inbound flow of materials from vendors, as well as the storage, valuation, and movement of those materials throughout the company's plants and warehouses. Every time a sales order in SD depletes inventory, MM is what ensures that inventory is replenished on time and at the right cost. MM is also directly integrated with FI for automatic accounting of every goods movement and every vendor invoice.
What SAP MM Manages
The MM module covers five core areas: Purchasing (purchase requisitions, requests for quotation, purchase orders, outline agreements, contracts, and scheduling agreements), Goods Receipt and Inventory Management (posting goods movements with movement types, stock transfers, and inventory adjustments), Invoice Verification (matching vendor invoices to POs and GRs — the three-way match), Material Master Data (the central repository for all material descriptions, units of measure, valuation classes, MRP settings, and purchasing info), and Vendor Master Data (the central record for each supplier, including payment terms, bank details, purchasing organisation assignments, and tax information).
What it does: A Purchase Requisition (PR) is an internal document requesting that materials be procured. It can be created manually or automatically by MRP. Once approved, a Purchase Order (PO) is created and sent to the selected vendor. The PO is the legal commitment to buy at an agreed price and quantity.
Real-world example: Arjun Industries' MRP run shows that raw material Steel Billets (material 100032) will run out in 10 days. The system automatically generates a PR for 20 MT. The purchase team converts this into a PO (ME21N) for vendor Vikram Steel Works at ₹85,000 per MT with net 30 payment terms.
T-Codes: ME51N (PR Create), ME21N (PO Create), ME2M (PO by Material)What it does: When ordered materials physically arrive at the plant, the goods receipt is posted using MIGO with movement type 101. This increases the unrestricted stock in MM and simultaneously triggers an accounting entry in FI (debiting the Inventory account and crediting the GR/IR Clearing account). The GR creates a Material Document that forms one leg of the three-way match.
Real-world example: 20 MT of Steel Billets arrive from Vikram Steel Works. The store-keeper scans the PO number, enters the quantity, and posts the GR in MIGO. SAP creates a material document (movement type 101) and an accounting document: Inventory (Raw Material) Dr ₹17,00,000 | GR/IR Clearing Cr ₹17,00,000.
T-Codes: MIGO (Goods Movement), MB52 (Warehouse Stocks), MB51 (Material Doc List)What it does: When the vendor's invoice arrives, MIRO is used to post it against the PO and GR — this is the three-way match (PO quantity and price vs GR quantity vs invoice quantity and amount). If all three match within defined tolerances, the invoice is posted. FI accounting: Vendor Payable Dr | GR/IR Clearing Dr | Tax Input Cr.
Real-world example: Vikram Steel Works sends an invoice for 20 MT × ₹85,000 = ₹17,00,000 plus 18% GST = ₹20,06,000. The accounts payable team runs MIRO, selects the PO, and the system auto-populates the quantity and value from the GR. After matching, the system posts: GR/IR Clearing Dr ₹17,00,000 | GST Input Credit Dr ₹3,06,000 | Vendor Payable Cr ₹20,06,000.
T-Codes: MIRO (Invoice Verification), MIR7 (Park Invoice), MR11 (GR/IR Clearing)What it does: MM inventory management tracks the quantity and value of every material at every plant and storage location in real time. It supports stock transfers between plants (movement type 301), storage location transfers (311), return deliveries (122), and scrapping (551). Physical inventory counts are managed using cycle counting or annual inventory procedures.
Real-world example: Arjun Industries needs to transfer 5 MT of Steel Billets from Plant 1001 (Chennai) to Plant 1002 (Pune) to support a production order there. The MM team uses MIGO with movement type 301 to post the plant-to-plant transfer. MMBE immediately reflects the reduced stock at Plant 1001 and the increased stock at Plant 1002.
T-Codes: MMBE (Stock Overview), MB5B (Stock on Date), MI01/MI07 (Physical Inventory)🔄 The Complete Procure-to-Pay (P2P) Cycle in SAP MM - Step by Step
The Procure-to-Pay (P2P) cycle covers the complete journey from recognising a need for materials all the way through to paying the vendor. Just like OTC in SD creates a traceable document chain, P2P in MM creates its own linked chain: PR → PO → GR → Invoice → Payment. Each step is auditable and cross-referenced in SAP, making it extremely difficult for fraudulent or erroneous transactions to go undetected. Here is the complete P2P flow using our Arjun Industries scenario.
Purchase Requisition (PR) - Internal Need Identification
Either the production planning team identifies a shortfall in raw materials during an MRP run (automatic PR) or a department head manually requests a material using ME51N (manual PR). The PR captures what is needed, how much, by when, and to which cost centre or project the cost will be charged. At this stage no commitment to a vendor has been made — the PR is purely internal. Depending on the SAP configuration, PRs may require approval through a release (approval) strategy before proceeding to the next step.
T-Code: ME51N (Create PR) | ME52N (Change) | ME5A (List of PRs)Request for Quotation (RFQ) - Optional Tendering Step
For high-value or new procurement, the purchase team may create a Request for Quotation (RFQ) in ME41 and send it to multiple vendors. Vendor quotations are recorded in ME47, and SAP's price comparison report (ME49) helps the buyer identify the best offer based on price, delivery time, and other criteria. This step supports regulatory compliance and best-value purchasing, which is particularly important for public sector organisations or large private companies with procurement governance policies.
T-Code: ME41 (Create RFQ) | ME47 (Maintain Quotation) | ME49 (Price Comparison)Purchase Order (PO) Creation
The Purchase Order is the legal commitment document sent to the selected vendor. It is created in ME21N either manually or by converting an approved PR. The PO captures the vendor, material, quantity, agreed price (from the info record or contract), delivery date, plant, storage location, and payment terms. Once the PO is saved and sent to the vendor (by printout, EDI, or email), it represents a binding commitment. SAP maintains a complete version history of every PO change for auditing purposes.
T-Code: ME21N (Create PO) | ME2M (POs by Material) | ME9F (PO Output)Goods Receipt (GR) - Materials Arrive
When the vendor delivers the materials, the stores team performs a Goods Receipt in MIGO with reference to the PO (movement type 101). The GR updates inventory quantities in real time and triggers an automatic FI posting: Inventory/Stock Account Dr | GR/IR Clearing Account Cr. The GR also records the vendor's delivery note number and allows partial deliveries to be tracked against the full PO quantity. Over-delivery and under-delivery tolerances can be configured to prevent or warn about deviations.
T-Code: MIGO (movement type 101) | MB5B (Stock on Posting Date)Invoice Verification (MIRO) - Three-Way Match
When the vendor's invoice arrives, the accounts payable team runs MIRO to post it. SAP performs the three-way match automatically: (1) PO price and quantity, (2) GR quantity, (3) Invoice price and quantity. If all three agree within configured tolerance limits, the invoice is posted and a payment block is cleared. If there is a price variance or quantity discrepancy, the system flags it for resolution before payment is authorised. This three-way match is one of the strongest internal controls in any SAP MM implementation.
T-Code: MIRO (Invoice Verification) | MIR4 (Display Invoice) | MR11 (GR/IR Clearing)Vendor Payment - Closing the Cycle
On the payment due date (calculated from the vendor's payment terms stored in the vendor master), SAP's automatic payment program (F110) identifies all open vendor invoices that are due and generates a payment run. The payment can be made by cheque, NEFT, RTGS, or any other configured payment method. Once posted, the vendor payable in FI is cleared and the Procure-to-Pay cycle is complete for this transaction. The entire cycle is now documented and auditable from PR through to bank statement reconciliation.
T-Code: F110 (Automatic Payment Program) | FBL1N (Vendor Line Items)| Step | Procure-to-Pay (MM - Buying) | Order-to-Cash (SD - Selling) |
|---|---|---|
| Step 1 | Purchase Requisition (ME51N) | Customer Inquiry (VA11) |
| Step 2 | Request for Quotation (ME41) | Quotation to Customer (VA21) |
| Step 3 | Purchase Order (ME21N) | Sales Order (VA01) |
| Step 4 | Goods Receipt / MIGO (Mv.101) | Outbound Delivery (VL01N) |
| Step 5 | Invoice Verification (MIRO) | Goods Issue (VL02N / Mv.601) |
| Step 6 | Vendor Payment (F110) | Billing Document (VF01) |
| Step 7 | — | Incoming Payment / Clearing (F-28) |
| FI Impact | AP Dr | Inventory Cr | GR/IR | AR Dr | Revenue Cr | COGS Dr |
🔗 How SAP SD and MM Integrate - The 4 Key Integration Points
SAP SD and MM do not operate in silos — they are deeply and continuously integrated. Understanding where and how they connect is critical for both consultants (who need to configure these links correctly) and end users (who need to understand why certain actions in one module affect another). Here are the four most important SD-MM integration points that you will encounter in every SAP implementation.
Integration Point 1: ATP Check (Availability-to-Promise)
When a sales order is created in SD (VA01), SAP immediately performs an availability check against MM inventory. The ATP check consults the plant's stock position — unrestricted stock, minus reservations for other orders, plus confirmed incoming deliveries (purchase orders and production orders) within the replenishment lead time. Based on this calculation, SAP either confirms the full quantity on the requested date or proposes an alternative delivery schedule. If insufficient stock is available and no incoming deliveries are expected in time, the SD consultant and materials planner need to collaborate to either expedite a purchase order in MM or negotiate a later delivery date with the customer.
Integration Point 2: Goods Issue Reduces MM Inventory
The most visible and operationally important SD-MM link occurs when goods issue is posted during the SD delivery process. When the VL02N goods issue is posted with movement type 601, MM inventory is reduced by exactly the quantity shipped. This is not a separate action — the SD delivery posting automatically calls the MM inventory management layer and creates a material document and accounting document simultaneously. From that moment, the stock is gone from MM's perspective, and the financial impact (COGS entry in FI) is also automatic. Getting this integration right — especially regarding storage location determination, valuation areas, and account assignment — is one of the most technically complex configuration tasks in an SD-MM joint implementation.
Integration Point 3: Third-Party Sales (SD Creates MM Purchase Orders)
In a third-party sales scenario, Arjun Industries receives a customer order (in SD) for a product that it does not stock itself — the vendor ships directly to the customer. When the SD sales order item is configured with item category TAS (third-party), SAP automatically generates a Purchase Requisition in MM upon saving the order. The purchase team converts the PR to a PO (ME21N) and sends it to the vendor. When the vendor confirms shipment and the goods receipt is posted (MIGO with movement type 101 without quantity update, since goods went directly to the customer), SD can then bill the customer. This scenario requires careful SD and MM configuration to be aligned and is one of the most common integration scenarios in distribution-heavy industries.
Integration Point 4: Inventory Valuation Affects SD Profitability
The cost of goods sold posted when SD goods issue occurs is derived from the MM material valuation. If materials are valued at standard cost (valuation with standard price — price control S), the COGS entry uses the standard cost regardless of the actual purchase price. If materials are valued at moving average price (price control V), the COGS entry uses the current moving average price at the time of goods issue. This means that MM valuation decisions directly affect the margin and profitability figures visible in SD's profitability analysis (CO-PA). A change in the MM valuation approach is never purely an MM decision — it always has SD and CO-PA implications that must be evaluated together.
| Integration Point | Trigger (where it starts) | Effect (where it lands) | Key Config |
|---|---|---|---|
| ATP Check | Sales Order creation (VA01 in SD) | Reads MM stock/PO/production data to confirm delivery date | Checking rule, MRP type |
| Goods Issue (601) | Delivery goods issue (VL02N in SD) | Reduces MM unrestricted stock + FI accounting entry (COGS) | Movement type, account determination |
| Third-Party Order | Sales order with item category TAS (SD) | Automatically creates PR → PO in MM; vendor ships to customer | Item category TAS, PR creation in SD |
| Valuation Impact | MM material valuation (price control S or V) | Determines COGS amount posted when SD goods issue occurs | Price control in MM01, valuation class |
Important for Consultants: In most SAP projects, SD and MM are implemented simultaneously, and the cross-module configuration decisions must be made jointly. Never configure the SD output account determination without the MM account assignment groups aligned, and never change the MM valuation approach mid-project without involving the SD and CO-PA team. These integration points are where most cross-functional SAP issues originate.
✅ SAP SD and MM Best Practices - What To Do and What To Avoid
⌨️ Essential SAP SD and MM T-Codes - Complete Quick Reference
The following tables list the most important transaction codes for both SAP SD and SAP MM. Mastering these T-codes is the first practical step every new SAP consultant or end user takes when beginning hands-on work in the system.
| T-Code | Function | Process Area |
|---|---|---|
| VA01 | Create Sales Order | Order Management |
| VA02 | Change Sales Order | Order Management |
| VA03 | Display Sales Order (incl. Document Flow) | Order Management |
| VA21 | Create Quotation | Pre-Sales |
| VL01N | Create Outbound Delivery | Shipping |
| VL02N | Change Delivery / Post Goods Issue | Shipping / GI |
| VF01 | Create Billing Document | Billing |
| VF04 | Billing Due List | Billing |
| VK11 | Create Condition Records (Pricing) | Pricing |
| VD01 | Create Customer Master (SD View) | Master Data |
| VKM1 | Blocked SD Documents (Credit) | Credit Management |
| VA05 | List of Sales Orders | Reporting |
| T-Code | Function | Process Area |
|---|---|---|
| ME51N | Create Purchase Requisition | Purchasing |
| ME21N | Create Purchase Order | Purchasing |
| ME23N | Display Purchase Order | Purchasing |
| ME2M | Purchase Orders by Material | Purchasing Reporting |
| MIGO | Goods Movements (GR, Transfer, GI) | Inventory Management |
| MMBE | Stock Overview by Material/Plant | Inventory Reporting |
| MB52 | Warehouse Stocks of Material | Inventory Reporting |
| MIRO | Logistics Invoice Verification | Invoice Verification |
| MR11 | GR/IR Account Maintenance | Invoice Verification |
| MM01 | Create Material Master | Master Data |
| ME41 | Create Request for Quotation (RFQ) | Purchasing |
| MB51 | Material Document List | Inventory Reporting |
❓ SAP SD and MM Business Scenarios - Frequently Asked Questions
MIGO (transaction for Goods Movements) and MIRO (Logistics Invoice Verification) are two separate steps in the MM Procure-to-Pay cycle that address two different business events. MIGO is used when physical goods arrive at the plant — it records the goods receipt, updates inventory quantities, and posts the first leg of the accounting entry (Inventory Dr / GR/IR Cr). MIRO is used when the vendor's invoice arrives — it posts the second leg of the accounting entry (GR/IR Dr / Vendor Payable Cr) after verifying that the invoice matches the PO and GR. In short: MIGO records that goods arrived; MIRO records that the invoice was received and verified. MIGO always comes first chronologically; MIRO follows when the paper invoice arrives from the vendor, which may be days or weeks later.
Movement type 601 in SAP MM represents "Goods Issue for a Delivery" — it is the inventory movement that reduces unrestricted stock when goods are shipped to a customer as part of a sales delivery in SD. It is triggered automatically when you post the Goods Issue in transaction VL02N for an outbound delivery. Unlike manual goods issue movement types (such as 261 for goods issue to a production order), movement type 601 is always linked to an SD delivery document and therefore always has an associated customer and sales order reference. The accounting entries posted by movement type 601 are: Cost of Goods Sold Account (Dr) and Finished Goods/Trading Goods Inventory Account (Cr). This is one of the key SD-MM integration points.
The three-way match in SAP MM is the process of verifying that three documents agree before authorising vendor payment: (1) the Purchase Order — what was ordered and at what price, (2) the Goods Receipt — what was actually received, and (3) the Vendor Invoice — what the vendor is claiming payment for. The system compares quantity and value across all three and only clears the invoice for payment if they match within configured tolerance limits (typically 1-5% on price, 0% on quantity for overdelivery). This three-way match is one of the most important financial controls in any ERP system because it prevents payment for goods not received, payment at incorrect prices, and duplicate invoice processing. In SAP, MIRO performs this three-way match automatically when you enter the invoice with reference to the PO number.
A third-party sales scenario occurs when your company receives an order from a customer (handled in SAP SD) but fulfils it by having the vendor ship directly to the customer rather than shipping from your own warehouse. In SAP, this is configured using item category TAS in SD. When a sales order with item category TAS is saved, SAP automatically creates a Purchase Requisition in MM. The buyer converts the PR to a PO and sends it to the vendor. The vendor ships to the customer and sends you the delivery confirmation. You then post a statistical GR in MIGO (no actual stock movement, since goods went directly to customer), which allows you to run MIRO to pay the vendor. Finally, you create the billing document in VF01 to invoice your customer. This scenario requires both SD and MM to be configured and integrated correctly and is common in trading companies and in situations where companies act as intermediaries.
The GR/IR (Goods Receipt / Invoice Receipt) clearing account is an intermediate account used in SAP MM to handle the timing difference between when goods are received and when the vendor invoice is processed. When a Goods Receipt is posted (MIGO), the accounting entry is: Inventory Dr | GR/IR Clearing Cr. When the Invoice is posted (MIRO), the accounting entry is: GR/IR Clearing Dr | Vendor Payable Cr. The two entries offset each other in the GR/IR clearing account, which should net to zero once both the GR and the invoice are processed. An uncleared balance in the GR/IR account at month end means either goods were received but the invoice has not yet arrived (accrual is needed), or an invoice was posted without a matching GR (which may indicate an error or fraud). Regular GR/IR reconciliation using MR11 is an important month-end close activity in any SAP MM implementation.