SAP Cross‑Module Integration (FI ↔ MM ↔ SD) – The Complete Blueprint with Real‑World Scenarios | Part-14 | FreeLearning365

 

SAP Cross‑Module Integration (FI ↔ MM ↔ SD) – The Complete Blueprint with Real‑World Scenarios

You know the transactions. You’ve posted sales orders, purchase orders, goods receipts, invoices, and payments. But can you close your eyes and trace a single customer order all the way from the sales document to the final cash receipt, and in doing so, touch every relevant account in the general ledger without missing a step? That is cross‑module integration – the ability to see SAP not as a collection of silos but as a single, value‑driven organism. This is the article that will rewire your brain.

In this grand finale of the Business Process First series (before we cap it with a real company scenario), we are going to walk through the entire financial and logistics lifecycle of a single product sale inside GlobalTech Innovations (Company Code 1000). We will start with a customer purchase order, run MRP, produce the goods, procure raw materials, deliver, bill, collect cash, and close the books. Every step will be traced through FI, MM, and SD simultaneously. We will expose the exact integration points where these modules shake hands, and we will throw in six catastrophic real‑life problems that can only be solved by understanding those links. By the end, you will no longer be a module consultant – you will be a solutions architect who can design an entire business process end‑to‑end.

Let’s break the silos. It’s time to think across the entire supply chain.

1. The Integration Mindset – Value Moves Across Modules, Not Just Documents

In SAP, a single business event triggers a chain reaction that touches multiple modules. A delivery in SD triggers a goods issue in MM, which reduces inventory and posts COGS to FI. An invoice in SD posts revenue and tax to FI, and debits the customer. A payment in FI clears the customer account. A purchase order in MM, when goods‑received, creates an FI document for inventory and GR/IR, and when invoiced, clears GR/IR and posts to vendor. These are not isolated transactions; they are linked by configuration, master data, and automatic account determination. The consultant who only knows how to execute these steps in isolation is a clerk. The consultant who understands why the GR/IR account must be zero before closing, or why a missing account key stops the billing run, is the one the CFO trusts.

Before you start tracing the flow, you must fix these core questions in your mind:

• What is the value impact of each document – which balance sheet and P&L accounts are hit?
• Which configuration tables (OBYC, VKOA, OB40) translate a material movement or a billing item into a journal entry?
• Where are the handshake points – the moments when data passes from one module to another, and what can go wrong?
• How do you reconcile the inter‑module accounts (GR/IR, stock in transit, revenue, tax) at month‑end?

Now, let’s follow a single order from beginning to end and answer every one of those questions.

2. The Master Data Prerequisites – The Silent Integrators

Before any transaction, the master data that enables integration must exist. This is not a repeat of the master data chapter; it’s a targeted list of the fields that specifically enable FI‑MM‑SD cross‑talk.

• Customer Master (100001): Reconciliation account 140000, tax classification 1 (taxable), customer account assignment group 01, payment terms 0002.
• Material Master (MAT‑IT‑001 – ProSwitch): In SD views: item category group NORM, tax classification 1, account assignment group 01. In Accounting: valuation class 7920 (FG), standard price 3,500 INR. In MRP: MRP type PD, procurement type E. In Plant data: storage location FG01.
• Material Master (MAT‑RM‑001 – Aluminum Enclosure): Valuation class 7920 (raw material), standard price 800 INR, MRP type PD, procurement type F.
• Vendor Master (200001): Reconciliation account 160000, tax classification 1, schema group vendor 01, GR‑Based IV flag ticked, payment terms 0002.
• Pricing Records: PR00 for MAT‑IT‑001 10,000 INR, MWST output tax 18%, etc.
• OBYC Configuration: BSX for valuation class 7920 → Inventory GLs (141000 FG, 142000 RM), WRX → GR/IR 210000, GBB‑AUF → Production cost consumption, GBB‑VBR → Scrap, PRD → Price differences.
• VKOA: For chart INT1, sales org 1000, cust acct grp 01, mat acct grp 01, account key ERL → 800000 (Sales Rev), ERF → 810000 (Freight).
• OB40: Tax code X1, account key MWS → 170000 (Output Tax); tax code J1, account key VST → 150000 (Input Tax).

These are the foundation. Every integration moment will rely on them.

3. The Grand Scenario – One Customer Order, Full Cycle

Let’s define the business event: TechMart Retail places a purchase order for 20 units of ProSwitch at 10,000 INR each plus freight and tax. We have zero stock of the finished good. We must manufacture 20 units, which requires 20 Aluminum Enclosures that we purchase from TechSupply. We’ll follow the entire cycle, mapping FI, MM, and SD at each step.

3.1 Demand and MRP – SD to PP/MM

We enter a planned independent requirement for 20 units of MAT‑IT‑001 via MD61. MRP (MD02) runs, sees zero stock, and creates a planned order for 20 units. Simultaneously, it explodes the BOM and sees a demand for 20 MAT‑RM‑001. Since stock is zero and procurement type F, it creates a purchase requisition. This is the first integration: SD demand → PP planned order & MM purchase requisition.

3.2 Procurement of Raw Material – MM to FI

Buyer converts the PR into a purchase order (ME21N) for vendor 200001, 20 pieces at 850 INR. The PO pricing pulls PB00 and tax J1. The goods receipt is posted via MIGO (movement 101). Immediately:

• MM: Stock MAT‑RM‑001 increases by 20 PC in storage location RM01.
• FI: Debit Raw Material Inventory (142000) 16,000 INR (20 x 800 standard), Debit Price Difference (670000) 1,000 INR, Credit GR/IR (210000) 17,000 INR (20 x 850). This FI document is generated automatically via OBYC: BSX, PRD, WRX.

Invoice verification (MIRO) for 17,000 INR + tax 3,060 = 20,060. FI document: Debit GR/IR 17,000, Debit Input Tax (150000) 3,060, Credit Vendor (160000) 20,060. GR/IR clears. This is MM → FI integration.

3.3 Production – PP/MM/FI

Production planner converts the planned order into a production order (CO40) for 20 units. Release. Goods issue of the Aluminum Enclosure to the order (MIGO, movement 261). FI: Debit Production Cost (GBB‑AUF, account 900000) 16,000 INR, Credit Raw Material Inventory 16,000 INR. The production order absorbs this cost. Confirmation (CO15) adds activity costs (labor, machine). Finally, goods receipt of the finished ProSwitch (MIGO 101 for production order). FI: Debit Finished Goods Inventory (141000) 70,000 INR (20 x 3,500), Credit Production Output (offset account) 70,000 INR. Variance settlement (KO88) posts any difference. This is PP → MM → FI.

3.4 Sales Order and Delivery – SD/MM/FI

Sales order (VA01) for customer 100001, 20 units, pricing as configured: PR00 200,000 INR, discount if any, freight 4,000 INR, tax 36,720 INR, total 240,720 INR. No immediate FI impact. Delivery (VL01N) and subsequent goods issue (VL02N). The goods issue:

• MM: Movement 601, stock MAT‑IT‑001 reduces by 20 PC in FG01.
• FI: Debit COGS (620000) 70,000 INR (20 x 3,500), Credit Finished Goods Inventory (141000) 70,000 INR. This uses OBYC: GBB‑VBR for the COGS account, BSX for inventory reduction. This is SD → MM → FI.

3.5 Billing and Payment – SD/FI

Billing (VF01) with reference to delivery creates invoice 90000001. FI document:

• Debit Customer (140000) 240,720 INR
• Credit Sales Revenue (800000) 200,000 INR
• Credit Freight Revenue (810000) 4,000 INR
• Credit Output Tax (170000) 36,720 INR

This uses VKOA (account determination) and OB40 (tax). SD → FI.

Customer pays via bank transfer. F-28 posts: Debit Bank (110000) 240,720 INR, Credit Customer 240,720 INR. AR cleared.

3.6 Period‑End Close – R2R

In FI, we run depreciation, accruals, and then financial statements. The P&L shows revenue 200,000 + 4,000, COGS 70,000, gross profit 134,000, less other expenses. The balance sheet shows inventory changes, bank, AR, AP, tax assets/liabilities. This is R2R, fed by SD and MM.

4. The Integration Touchpoints – A Detailed Reference

Let’s expand each integration point with configuration and real‑world examples.

4.1 SD → FI: Billing to Accounting

• Revenue Recognition: When the billing document is saved, the system determines revenue accounts via VKOA. The key fields are sales org, customer account assignment group, material account assignment group, and account key. If any of these are missing, the billing document may save but not post to FI. A common error is “No account defined for account key ERL”. Fix: maintain VKOA record for the specific combination.
• Tax Posting: The tax condition type (e.g., MWST) uses account key MWS. OB40 links tax code X1 to the output tax GL. If the customer tax classification is missing, the tax code cannot be determined, and the FI document fails. This is the top billing issue in real projects.
• Customer Receivable: The reconciliation account is pulled from the customer master (company code view). If it’s blank, billing cannot post.
• Foreign Currency: If the sales order is in a foreign currency, the billing document will post the customer line in that currency, and the revenue in local currency with an exchange rate. The realized/unrealized exchange differences later hit the P&L.

4.2 MM → FI: Goods Movements and Invoice Verification

• Goods Receipt (101): The inventory account is determined by BSX based on valuation class (and optionally account grouping for split valuation). The offsetting credit goes to GR/IR determined by WRX. If a standard price material has a PO price different from the standard, the difference hits PRD. All these are OBYC keys. If any key is missing, the FI document is not generated, and the goods receipt posts only to MM – a terrible situation because the GL is incomplete.
• Goods Issue (261): The production cost (or consumption) account is determined by GBB with the account grouping code (e.g., AUF for production). The credit goes to inventory (BSX).
• Invoice Verification (MIRO): Clears GR/IR (WRX), posts tax (VST), and posts the vendor liability (reconciliation account from vendor master). If the vendor reconciliation account is missing, MIRO fails.
• Scrap (551): GBB‑VBR determines the scrap expense account. Inventory credit.

4.3 SD → MM: Third‑Party and Inter‑Company

• Third‑Party Order (item category TAS): The sales order automatically creates a purchase requisition. The PR number is stored in the sales order schedule line. When the PR is converted to PO, the account assignment is “S” (third‑party). At goods receipt (101), the system does not post to inventory; instead, it posts directly to COGS (GBB‑VAY) and the vendor liability. At billing, the revenue is recognized without a delivery. This is a pure SD‑MM‑FI triangle.
• Stock Transport Order (STO): This is a purchase order (type UB) between two plants. The integration: SD delivery (if using delivery) does not exist; the goods issue is via VL10B or MIGO_GI (351) from the supplying plant. This reduces inventory (BSX) and debits “Stock in Transit” (a GL account from OBYC). At receiving plant, goods receipt (101) debits inventory and credits stock in transit. Any freight is added via condition in the STO and cleared via MIRO.
• Returns and Credit Memos: An SD return delivery (movement 651) increases inventory and credits COGS. The subsequent credit memo (billing type RE) posts Debit Revenue and Credit Customer. In MM, a return to vendor (movement 122) reverses the goods receipt and credits the vendor.

5. Troubleshooting the Integration – Six Real‑Life Scaniors

Scen‑INT‑01: The Phantom GR/IR – Invoice Without Goods Receipt

Situation: At month‑end, the GR/IR account (210000) has a debit balance of 170,000 INR. This means an invoice was posted without a corresponding goods receipt, or the goods receipt was reversed. The AP manager is worried because the balance sheet shows a receivable in a liability account. Investigation reveals that a buyer entered an invoice via MIRO for a PO for which the GR had not yet been posted, but the vendor master’s GR‑Based IV flag was off. The system allowed it.

Diagnosis: Use MB5S to view GR/IR balances per PO line. Identify the PO with a credit balance? Actually, debit GR/IR means invoice posted, GR missing. The FI document shows Dr GR/IR, Cr Vendor. The GR/IR is not cleared.

Fix: Post the missing goods receipt. The GR will Cr GR/IR 170,000 and Dr Inventory, reversing the debit. The GR/IR becomes zero. If the goods will never arrive, reverse the invoice with MR8M and correct the vendor master flag to prevent recurrence. Then run F.19 to regroup the remaining GR/IR if needed.

Scen‑INT‑02: Inter‑Company Sale – Internal Billing Missing

Situation: GlobalTech India (company code 1000) sells to GlobalTech Germany (company code 2000) using an inter‑company sales order. The delivery and goods issue are posted, and the external invoice is created. However, the inter‑company billing (IV) was not generated because the plant 1100 in India is not linked to the German sales organization via the inter‑company billing setup. Consequently, the revenue from the Indian company’s perspective is missing, and the German entity’s cost is not recorded.

Diagnosis: In the sales order, the delivering plant is in a different company code than the sales organization. The system should automatically create an inter‑company billing request. If not, check OBUP (assign internal customer number to sales organization) and ORBV (assign billing type to inter‑company billing).

Fix: Correct the configuration, then manually create the inter‑company billing via VF01 with the reference to the delivery and select billing type IV. The system will post the internal revenue and cost.

Scen‑INT‑03: Third‑Party Drop‑Ship – Billing Fails After GR

Situation: A third‑party sales order for a router is created. The purchase requisition is converted to a PO for the vendor. The vendor ships directly to the customer. The buyer posts the goods receipt (MIGO 101 with account assignment S). The GR posts COGS directly. But when billing is attempted, the system says “No delivery‑related billing document possible.” The billing clerk is stuck because the third‑party process doesn’t use a delivery; billing is done directly from the sales order. However, the billing type configured in the copy control expects a delivery number. The wrong billing type (F2) was determined.

Diagnosis: The sales order item category TAS must be linked to a billing type that references the sales order directly (e.g., F8). Check copy control VTFA.

Fix: In SPRO, set up the copy control from order type OR, item category TAS to billing type F8. Then recreate the billing document via VF01 with reference to the sales order. It will pick the completed quantity from the GR.

Scen‑INT‑04: COGS Mismatch – Production Variance Not Settled

Situation: After the production order for 20 ProSwitches is completed, the goods receipt posted 70,000 INR to inventory. But the production order actual costs were 75,000 INR because extra raw material was consumed due to scrap. The order shows a debit balance (under‑recovery). The variance was not settled because KO88 was not executed. The COGS on the sales delivery (70,000 INR) is lower than the actual cost, and the P&L margin is overstated. The financial controller spots the issue.

Diagnosis: Check the production order in KOB1. The balance is 5,000 INR debit. Settlement rule is set to material, but settlement not yet posted. Without settlement, the production variance account (PRD) is not hit.

Fix: Execute KO88 for the order, which posts Dr Production Variance (or COGS offset) 5,000, Cr Production Order 5,000. The variance then appears in the P&L. If the sales delivery is already posted, an adjustment entry may be needed to restate COGS. This is a classic PP‑FI‑CO integration point.

Scen‑INT‑05: Stock in Transit – Goods Lost Between Plants

Situation: A stock transport order (STO) was created for 100 units from Plant 1100 to Plant 1200. Goods issue (351) was posted, moving stock to “Stock in Transit” (GL 190000). However, the receiving plant never posted goods receipt. The material is physically lost. Inventory in Plant 1200 is understated, and the stock in transit GL shows a debit balance. Month‑end reconciliation flags the discrepancy.

Diagnosis: Use MB5T to view stock in transit. The STO line shows quantity still in transit. The logistics team confirms the shipment was lost. A reversal of the goods issue and a physical inventory adjustment are needed.

Fix: Reverse the goods issue via MIGO (movement 352) with reference to the STO. This credits Stock in Transit and debits Inventory at Plant 1100. Then adjust inventory at Plant 1100 with a physical inventory document. If insurance claim, handle separately.

Scen‑INT‑06: Tax Discrepancy – SD Output Tax vs. MM Input Tax Mismatch

Situation: The GST return shows output tax from sales (36,720 INR) and input tax from purchases (3,060 INR). But the input tax credit on the Aluminum Enclosure purchase was posted with tax code J1 (18%) on 17,000 INR = 3,060. However, the vendor invoice actually had a different tax rate because the material is subject to 12% GST, not 18%. The material master purchasing view had tax classification 1 (full rate 18%) but should have been 2 (12%). The invoice was posted with the wrong tax code, overstating input tax credit and understating cost.

Diagnosis: Compare the tax code in the PO and the invoice. The PO condition record had J1 with 18%, but the vendor’s invoice showed 12%. The accounts payable team forced the invoice through with a different tax code, creating a variance. The tax GL accounts are misstated.

Fix: Correct the material master tax classification. Reverse the incorrect invoice (MR8M) and re‑enter with correct tax code J2 (if defined) and rate 12%. Ensure the vendor master and purchase info record reflect the correct tax. A reconciliation of tax codes monthly prevents this.

6. The Month‑End Reconciliation Battle Plan

Integration errors often surface only at month‑end. Use this checklist to tie everything together before closing.

1. GR/IR Reconciliation: Run MB5S and compare with GL balance for GR/IR account. Clear any open items with F.13 or F.19. Ensure no debit balances from un‑invoiced receipts or credit from un‑received invoices linger without regrouping.
2. MM‑FI Inventory Reconciliation: Execute S_ALR_87012085. This compares MM inventory values (MBEW) with FI inventory GL accounts per material. Differences usually come from manual FI postings, incorrect valuation classes, or missing goods movements. Investigate each difference.
3. AR/AP Sub‑ledger vs. GL: Run FBL5N for customer accounts and compare with GL reconciliation accounts. Same for vendors with FBL1N. Any difference indicates a direct posting to the reconciliation account, which is prohibited.
4. Stock in Transit: MB5T – ensure all in‑transit quantities have a corresponding goods receipt or are reversed.
5. Production Order Status: COOIS – ensure all completed orders are settled (KO88) and no balances remain.
6. Tax Reconciliation: Use tax reports (S_ALR_87012357) to compare output/input tax with GL accounts. Ensure tax codes used match the master data.
7. Accruals: Post any outstanding GR/IR accruals, freight accruals, and unbilled receivables.

7. Consultant Wisdom – The Integration Commandments

• Always design integration from the financial impact backwards. Start with the GL accounts that need to be hit, then define the account determination that makes it happen.
• Test integration scenarios in a sequence that mimics real business cycles. A single test of a sales order without the prior procurement is not enough.
• Maintain a centralized master data governance team. The most common integration failures originate from inconsistent tax classifications, wrong valuation classes, or missing reconciliation accounts.
• Use the condition technique not just for pricing but as a mindset for all integration. Understand that access sequences and condition records are everywhere – account determination, output, tax.
• Never close a period without running the reconciliation reports. If you skip it, you’ll carry errors into the next period, compounding the problem.
• Document the integration points in a simple diagram for your client’s finance team. When they see how a sales order becomes cash and profit, they become your strongest allies.

8. Interactive “Try It Now” Checklist

In your SAP sandbox, perform the full cycle for 5 units of a finished product. Use a material you’ve already set up.

1. Set up a new planned independent requirement for 5 units.
2. Run MRP for the finished product and its components.
3. Procure the raw material via a purchase order, post GR, post invoice, and pay the vendor.
4. Convert the planned order to production order, issue components, confirm, and receive finished goods.
5. Create a sales order for the 5 units, deliver, post goods issue, bill, and receive payment.
6. At every step, immediately check the FI document via FB03 and note the GL accounts hit. Link them to the configuration (OBYC, VKOA).
7. Intentionally break one master data field (e.g., remove customer tax classification) and see how it blocks billing. Fix it and reprocess.
8. Run the reconciliation reports and ensure everything ties.
9. Post a manual FI entry to the GR/IR account and see it appear in the reconciliation report as a difference.
10. Close the period and run financial statements. Explain the P&L to a peer.

9. Closing Thoughts – The Integrated Enterprise Is One System

The line between SD, MM, and FI is an artificial boundary drawn for specialization. In reality, every sales order is a financial event, every purchase order is a liability, and every goods movement is a re‑valuation of assets. When you can trace the entire value flow without hesitation, you’ve transcended the module labels and become the consultant every project needs – the one who can connect the dots and speak the language of business. This article has given you the blueprint. Now go break things in your sandbox, fix them, and build the integrated confidence that will carry your career.

Next up in the series: Real company scenario walkthrough – where we take all the pieces and present a complete business case study, from requirements to solution, for a fictional but realistic manufacturing enterprise.

Integration is not a technical skill; it’s a perspective. Master it, and you master SAP.

– FreeLearning365, in tech partnership with @techbook24