SAP Master Data Dependency – Customer, Vendor & Material Integration Hands‑On Guide | Part-13 | FreeLearning365

 

SAP Master Data Dependency – The Hidden Web Connecting Customer, Vendor & Material

You’ve built customers, vendors, and materials a hundred times. But have you ever asked why a single missing checkbox in the vendor master causes a goods receipt to post to the wrong account? Or why the customer’s tax classification, buried three screens deep, can stop an entire billing run dead in its tracks? Master data in SAP is not three separate islands. It’s a single, tightly woven fabric where every thread pulls on the others. If you don’t understand these dependencies, you don’t understand SAP.

In this part of the Business Process First series, we step away from transaction flows and into the foundation that makes them all possible. We will dissect the Customer Master (FD01/XD01), Vendor Master (FK01/XK01), and Material Master (MM01/MM02) field by critical field, mapping exactly how they control sales orders, purchase orders, goods movements, invoices, and financial postings. Then we will walk through seven real‑business “Scaniors” – nightmare scenarios caused by master data misconfiguration – and trace the root cause from the error message back to the exact field that needs fixing. By the end, you will possess a mental map of dependencies that turns you into the go‑to person when anything breaks.

We will operate inside GlobalTech Innovations (Company Code 1000), using the customer TechMart Retail (100001), vendor TechSupply Inc. (200001), and material ProSwitch (MAT‑IT‑001) we’ve already used. Every example is concrete. Every field is in your sandbox right now. Let’s open the black box of master data and turn it into your superpower.

This is the article that finally makes every error message in SAP make sense.

1. The Master Data Mindset – It’s Not a Form, It’s a Contract

In SAP, master data is not just a collection of names and addresses. It is a legally and financially binding set of instructions that tell the system how to behave for a specific business partner or product. A single wrong setting in the customer master can cause an invoice to post with the wrong payment terms, leading to cash flow disruption. A missing valuation class in the material master can prevent any goods movement, halting the entire supply chain. Treat master data with the same seriousness you would treat a signed contract – because that’s exactly what it is to the system.

Before you ever open transaction XD01 or MM01, you must be able to answer:

• Which organizational levels does this master data serve? Company code? Sales area? Plant? Purchasing organization?
• What financial impacts does each view carry – reconciliation account, tax classification, payment terms, valuation class, price control?
• What integration points depend on this data? Pricing, output, account determination, MRP, credit management?
• If a field is left blank, what is the default behavior – and will it break a downstream process?

We will now build a complete field‑level understanding for each master data object, highlighting the dependencies that matter most.

2. Customer Master – The Buyer’s Digital DNA

The customer master is divided into three major segments: General Data, Company Code Data (FI), and Sales Area Data (SD). Each segment controls a different part of the business transaction. We’ll explore the most critical fields and their cross‑module impact.

2.1 General Data – The Identity Layer

Transaction: XD01 → General Data view. Key fields:

• Account Group: Determines the number range, screen layout, and whether the partner is a one‑time customer or a regular. It’s the foundation – choosing the wrong one can hide necessary fields.
• Name & Address: Used for output documents (order confirmation, invoice). A missing name causes blank printouts and communication failures.
• VAT Registration Number: Critical for tax determination in some countries (e.g., EU). In India GST, the GSTIN is used for tax reporting. If it’s missing, the invoice may still print but the tax return will flag an error.
• Search Term: Powers the matchcode search. If blank, users cannot easily find the customer in dropdowns, leading to duplicate master records – a data governance nightmare.

2.2 Company Code Data – The Financial Contract

This view controls how the customer is handled from an accounting perspective.

• Reconciliation Account (GL 140000): This is the single most important FI field. Every AR posting from SD billing flows into this account. If left blank, the billing document will not post to FI – a fatal error that blocks the entire O2C cycle. And if it’s wrong, you’ll see AR in the wrong GL, and the balance sheet will be misstated.
• Payment Terms (e.g., 0002): Determines the due date and cash discount. Misconfigured, and the customer pays late without penalty, or we give a discount when none was agreed. This field also feeds into the payment run (F110).
• Tolerance Group: Controls the allowed payment variance. A blank tolerance might mean no tolerance, causing small differences to block clearing.
• Sort Key: Affects the assignment field in line items. A wrong sort key makes it hard to reconcile open items.

2.3 Sales Area Data – The Commercial Engine

This is where the SD magic happens. The sales area is the combination of Sales Organization, Distribution Channel, and Division. Each customer can have different data for each sales area.

• Customer Pricing Procedure: This field (in SD view) determines which pricing procedure is used. It must align with the document pricing procedure (from the sales document type) and the customer’s pricing procedure to find the right procedure. A mismatch here can cause “no pricing procedure determined” – a classic error.
• Tax Classification: For each tax category (e.g., IN – India GST), you set a tax class (1 = taxable, 0 = exempt). This is the most common cause of billing errors. If it’s left blank, the system cannot determine the tax code from the condition record, and the invoice fails to post to FI. We will see this in Scen‑MD‑01.
• Delivery Priority & Shipping Conditions: Influence the delivery scheduling and route determination. But they also interact with the material master’s transportation group.
• Account Assignment Group (Customer): Used in account determination (VKOA) to map revenue and tax accounts. If this is missing or wrong, the billing document may post revenue to the wrong GL account.

3. Vendor Master – The Supplier’s Financial Footprint

The vendor master is structured similarly: General Data, Company Code Data (FI), and Purchasing Data (MM). Let’s examine the fields that cause the most trouble.

3.1 Company Code Data (FI View)

• Reconciliation Account (GL 160000): Every AP posting from invoice verification hits this account. Wrong account? The GR/IR clearing won’t match, and the balance sheet will have incorrect payables. Missing? Invoice posting fails.
• Payment Terms: As with customer, it controls the due date and discount. Inconsistency with purchase order terms creates payment disputes.
• Withholding Tax Type/Code: If the vendor is subject to TDS, this must be set. Failure leads to incorrect withholding and tax compliance issues.

3.2 Purchasing Data (MM View)

• GR‑Based Invoice Verification: When checked, the system requires a goods receipt before invoice posting for PO‑based invoices. If left unchecked, an invoice can be posted for goods never received – a massive financial risk. We’ll illustrate this in Scen‑MD‑02.
• Order Currency: Must match the purchase order. If blank, currency is defaulted from company code, which may be wrong for foreign vendors.
• Inco Terms: Determines the delivery point and can influence freight conditions and pricing. Missing incoterms can cause freight conditions not to be determined, understating liabilities.
• Schema Group Vendor: This field (in purchasing data) is essential for the MM pricing procedure determination. If it’s blank or mismatched, the purchase order may not find any pricing conditions, and the net price will be zero – a disaster.
• Tax Classification (Vendor): Like the customer, the vendor’s tax classification (e.g., 1 for taxable) is used together with the material tax classification to determine the input tax code in the purchase order. Missing → no tax calculated, wrong input tax account.

4. Material Master – The Central Nervous System of SAP

The material master is the most complex master data object, with dozens of views. Each view is relevant to specific modules, but many fields have cross‑functional impacts. We’ll focus on the fields that form the dependency web with customer and vendor.

4.1 Sales Views (SD)

• Tax Classification (Material): In Sales: Sales Org 1/2, you set the tax category for each tax type. This combines with the customer’s tax classification to determine the tax code. If set incorrectly (e.g., blank or 0 for a taxable product), the output tax will be wrong.
• Account Assignment Group (Material): Used in VKOA to find the revenue account. If different material types need different revenue accounts, this group is the key. Wrong group = revenue in wrong GL.
• Item Category Group: Controls which item category is determined in a sales order (e.g., NORM, BANS, DIEN). Wrong group can cause the sales order to treat a product as a service or third‑party item, leading to incorrect delivery and billing.
• Delivering Plant: Default plant for sales. It must be extended to the sales area. If blank, the order cannot propose a plant, causing a delivery block.

4.2 Purchasing View (MM)

• Valuation Class: (Actually in Accounting 1 view, but linked to purchasing). This determines the inventory and consumption GL accounts via OBYC. It is the single most important field for MM‑FI integration. If the valuation class is set to 7920 for raw materials, then all goods movements for this material will hit the raw material inventory account. If you accidentally assign a finished goods valuation class, the raw material will be posted to finished goods inventory – a valuation disaster.
• Purchasing Group: Defaults the purchasing group responsible. It doesn’t affect accounting, but if not maintained, the PR may not assign a buyer.
• Tax Classification (Material): In the purchasing view, the material tax class determines input tax. Must align with vendor tax classification.

4.3 Accounting 1 View (FI/CO)

• Valuation Class: As mentioned, controls FI accounts for inventory, GR/IR, and consumption. It is vital that the valuation class matches the material type and the business process.
• Price Control (S or V): Determines whether standard or moving average price is used. This choice has massive implications for how price differences are posted. Mixing price controls for similar materials can confuse the GL.

4.4 MRP Views (PP)

• MRP Type: PD (MRP) or ND (no planning). If set to ND, the material will never be planned, causing stockouts or excess manual procurement.
• Procurement Type: E (in‑house), F (external). This drives whether MRP creates planned orders or purchase requisitions. Wrong setting can cause MRP to create a planned order for an externally procured material, which then cannot be converted.
• Lot Size: EX, FX, etc. The lot size can cause planned orders with quantities that don’t match demand, creating confusion.

4.5 Plant Data / Storage Views

• Storage Conditions, Shelf Life: Affect inventory management and potentially batch determination. If shelf life data is missing, the system may not propose a batch during GI, causing manual effort.
• Negative Stock Allowed: A dangerous setting. If checked, it allows goods issues even if stock is zero, leading to credit balances in inventory GL.

5. The Master Data Dependency Matrix – A Cross‑Functional Blueprint

To truly master dependencies, you need a mental map. Below is a textual representation of the matrix I use in blueprint workshops. It shows which master data field drives which process across SD, MM, FI.

Process	Customer Field	Material Field	Vendor Field
Sales Pricing	Customer Pricing Procedure	Material Pricing Group	N/A
Tax Determination (SD)	Tax Classification	Tax Classification (Sales)	N/A
Account Determination (Revenue)	Account Assignment Grp Cust	Account Assignment Grp Mat	N/A
Credit Management	Credit Limit	N/A	N/A
Payment Terms (SD)	Payment Terms	N/A	N/A
Delivery Scheduling	Shipping Conditions	Transportation Group	N/A
Purchase Pricing	N/A	Material Group (etc)	Schema Group Vendor
Tax Determination (MM)	N/A	Tax Classification (Purch.)	Tax Classification
Account Determination (Inventory/COGS)	N/A	Valuation Class	N/A
Invoice Verification GR‑based	N/A	N/A	GR‑Based IV flag
MRP & Procurement	N/A	MRP Type, Procurement Type	N/A
Output Determination	Output Determination Proc.	N/A	N/A (but separate)

This matrix shows that when an integration error occurs, you can trace it back to the specific master data field that is either missing or incorrect. Let’s now apply this with seven real‑world Scaniors.

6. Scen‑MD‑01: The Missing Tax Classification That Killed Billing

Situation: It’s month‑end, and the billing clerk runs VF01 for a batch of deliveries. For one specific customer, the billing document saves, but no FI document is created. The error log says: “Account not defined for tax code X1”. Panic ensues.

Diagnosis: The customer master (100001) was extended to a new sales area, but the tax classification for category IN was left blank. The system could not determine the tax code, so it defaulted to X1 (or none), and no account was maintained for that combination. Even though tax code X1 exists, the system requires the customer tax classification to access the tax condition record. Without it, the tax condition MWST could not find a valid record, but the pricing procedure still expected a tax amount. The conflict blocked FI posting.

Fix: Update customer master (XD02) for the sales area: set Tax classification IN to “1 – Taxable”. Then recreate the billing document or release the blocked invoice via VFX3. The FI document posts immediately.

Lesson: Always include tax classification checks in the customer master creation checklist, especially for new sales areas. This is one of the most common go‑live issues.

7. Scen‑MD‑02: Vendor GR‑Based IV Flag Left Unchecked – A Lakh‑Sized Risk

Situation: GlobalTech’s accounts payable clerk receives an invoice for 200 enclosures from TechSupply (vendor 200001) and posts it via MIRO. The system accepts it without error. However, the goods receipt had not yet been posted because the shipment was delayed. The vendor was paid for goods we hadn’t received. When the shipment later arrived short, it was too late – the payment had been made, and the vendor didn’t respond.

Diagnosis: In the vendor master purchasing view, the checkbox “GR‑Based IV” was not ticked for vendor 200001. This setting is what enforces the three‑way match: invoice can only be posted for quantities already received. Without it, the system trusts the invoice quantity over the actual receipt, breaking the control.

Fix: Check the flag in XK02 for vendor 200001. Also, implement a process rule: never maintain a vendor without this flag unless it’s for services or specific non‑GR scenarios. For the already posted invoice, reverse it via MR8M and re‑enter after goods receipt.

Lesson: This flag is the guardian of your cash. Missing it on a single large vendor can lead to six‑figure losses. Audit vendor master data quarterly.

8. Scen‑MD‑03: Material Valuation Class Misassignment – Inventory in the Wrong GL

Situation: At month‑end, the inventory reconciliation report shows a massive difference between MM stock value and FI inventory GL for raw materials. After investigation, it’s found that the raw material MAT‑RM‑001 was created with valuation class 7920 (finished goods) instead of 7920? Wait, 7920 was the same? Actually, we had set up distinct valuation classes: 7920 for raw materials, 7910 for finished goods. The material MAT‑RM‑001 was mistakenly created with 7910, causing all goods receipts and issues to post to the finished goods inventory account. The raw material inventory account was understated, and finished goods overstated. The COGS on sales delivery was also distorted because the FG inventory value was inflated.

Diagnosis: A junior data entry person selected the wrong valuation class from the dropdown. Since both accounts exist, the system didn’t throw an error at movement, but the financial statements became wrong.

Fix: The valuation class cannot be changed once stock exists, so a multi‑step correction is needed: move stock to a new material with correct valuation class, or perform a manual revaluation with MR21 and adjust the GL via FB50 with auditor approval. Then create a new material with correct data and prevent the error via authorizations or reference material templates.

Lesson: Valuation class is the most dangerous field in the material master. Enforce mandatory reference materials for creation, and never allow free‑text entry.

9. Scen‑MD‑04: Missing Customer‑Material Info Record – EDI Order Failure

Situation: A large retail customer sends an EDI purchase order referencing their own part number “PROSWITCH‑24”. The EDI interface fails to map this to our material MAT‑IT‑001, and the sales order is not created automatically. The customer calls to complain about delayed shipments, and the sales team blames SAP.

Diagnosis: The customer‑material info record (VD51) was not maintained for customer 100001 and material MAT‑IT‑001. The inbound EDI mapping uses this record to translate the customer material number. Without it, the system can’t find the internal material, and the IDoc fails.

Fix: Create the info record via VD51: customer 100001, material MAT‑IT‑001, customer material “PROSWITCH‑24”. Reprocess the IDoc. The sales order is automatically created. To prevent recurrence, include VD51 creation in the customer onboarding process.

Lesson: The customer‑material info record is a small master data element with massive operational impact. Never skip it for customers who place electronic orders.

10. Scen‑MD‑05: Material MRP Type Set to ND – Production Stops

Situation: The production line halts because the Aluminum Enclosure (MAT‑RM‑001) is out of stock. The MRP controller is shocked because they rely on MD04 to show shortages, but no planned order or purchase requisition appears. They have a planned independent requirement for the finished product, but the component didn’t plan.

Diagnosis: The material MAT‑RM‑001 had its MRP type set to “ND” (No planning) in the material master MRP1 view. This means MRP completely ignores this material, even though it’s in the BOM. The system didn’t explode the demand from the finished product because ND materials are excluded from planning.

Fix: Change the MRP type to “PD” (MRP) in MM02. Then run MRP (MD02) for the material. The system will recognize the dependent demand from the planned order and create a planned order or PR. Stock can then be replenished.

Lesson: MRP type is the master switch for procurement. Audit all materials used in BOMs for MRP type PD. Use a mass change tool if needed, but never change without testing the impact on planned orders.

11. Scen‑MD‑06: Vendor Inco Terms Blank – Freight Condition Not Pulled

Situation: A purchase order for raw materials is created, but the expected freight charge of 2% is missing from the pricing. The buyer manually adds it, but later the invoice comes in with a different freight, creating a variance that blocks payment. The manual addition was a workaround, but the root cause was that the freight condition FRA1 for the vendor/material combination required the Inco terms as part of the key combination. Because the vendor master had no Inco terms maintained, the condition record wasn’t accessed, and the system didn’t propose freight.

Diagnosis: The purchasing condition type FRA1 used an access sequence that included Inco terms. The condition record had Inco terms “FOB”, but the PO header had no Inco terms because the vendor master didn’t specify one. The default from the vendor master was blank, so no match.

Fix: Maintain Inco terms in the vendor master (XK02) and in the condition record if needed. Then recreate the PO. The system now finds the freight condition and adds it automatically.

Lesson: Every field in the access sequence must be populated in the master data and the transaction. Missing a single field can silently drop a condition, leading to manual work and errors.

12. Scen‑MD‑07: Material Account Assignment Group Mismatch – Revenue in Wrong GL

Situation: The finance director notices that the revenue for a new product line is posting to the “Miscellaneous Sales” GL account instead of “Domestic Product Sales”. This causes segment reporting to be wrong, and the auditors question the classification. The material was set up by the engineering team without consulting finance.

Diagnosis: In the material master sales view, the “Account Assignment Group for Material” was set to “01” (Trading goods) even though the product is manufactured (should be “02”). The account determination in VKOA uses this group to decide the revenue GL. Since “01” maps to the miscellaneous account, all invoices for this material hit the wrong line.

Fix: Determine the correct account assignment group with the finance team. Change it in MM02. However, if open sales orders exist, they may retain the old determination; test billing. After change, future invoices will use the correct GL. If needed, reassign the account mapping in VKOA temporarily to shift existing invoices.

Lesson: Master data governance must involve the business process owners. The material account assignment group is a purely financial field in the sales view – always coordinate with the FI team.

13. The Master Data Debugging Toolkit – Tracing Errors to Their Source

When a transaction fails, don’t guess – follow the trail. Here are the exact steps and T‑codes I use to pinpoint which master data field is the culprit.

• Sales Order Pricing Error: VA01 → Item → Extras → Pricing → Analysis. It shows which condition types were accessed and not found. If a condition type appears but with zero, drill down to see which access step failed. The missing table key tells you what field was missing (e.g., customer pricing group). Then check the customer master (XD03) or material master (MM03) for that field.
• Billing Account Determination Error: VF02 → Environment → Acc. determination analysis. It lists the combination used: chart of accounts, sales org, customer account assignment group, material account assignment group, account key. If a record is missing in VKOA, you’ll see exactly which combination failed. Check each master data record to ensure the groups are populated.
• Tax Determination Error: In the sales order, go to item conditions, locate MWST, and see the tax code. If it’s blank, the condition record wasn’t found. Note the access sequence used (usually country, customer tax class, material tax class). Verify that the customer master (tax classification) and material master (tax classification) are set and that a corresponding MWST condition record exists for that combination in VK11.
• MM Pricing Error: In the PO, select item, Conditions. If PB00 is zero, check the info record condition or the condition record in MEK1. Also check the vendor master schema group and the purchasing organization schema group. The access sequence will reveal the missing field.
• FI Posting Error from Material Movement: If a goods movement posts but the FI document is missing or incorrect, go to MIGO, display the document, and use “Doc. info” to see the FI document if it exists. If missing, the account determination in OBYC may be incomplete. Check the valuation class of the material, and then check OBYC for that valuation class and the relevant transaction key (BSX, WRX, etc.).

This systematic approach turns a panic situation into a logical investigation that impresses everyone in the war room.

14. Integration Blueprint – How Master Data Fields Activate the System

To truly internalize the dependencies, let’s trace a single sales order from creation to billing, mapping every master data field used along the way.

1. Sales Order Creation (VA01): System reads customer master (sold‑to) to get sales area, customer pricing procedure, tax classification, payment terms. It reads material master to get item category group, tax classification, delivering plant, account assignment group, pricing group. Using these, it determines pricing procedure (from customer pricing procedure, document pricing procedure, sales area) and tax procedure.
2. Pricing: The access sequences for PR00, K004, etc., pull condition records based on the keys that combine customer and material master fields (e.g., customer number, material number, customer group, material group).
3. Delivery (VL01N): Uses shipping conditions from customer master and transportation group from material master to determine route and shipping point. Plant from material master or customer‑material info record.
4. Goods Issue: Movement 601. The system reads valuation class from material master to determine the inventory and COGS accounts via OBYC.
5. Billing (VF01): Tax classification from both masters is used to determine tax code. The customer account assignment group and material account assignment group are used to determine revenue GL via VKOA. Payment terms from customer master flow to invoice due date.
6. FI Posting: Customer reconciliation account from customer master is debited. Revenue GL from account determination is credited. Tax GL from OB40 is credited.

Every step rests on master data. If any field is wrong, the chain breaks. This is why master data is 80% of the configuration effort.

15. Consultant Wisdom – The Master Data Governance Commandments

• Thou shalt not create a customer or vendor without a completed checklist. The checklist must include all critical fields: reconciliation account, tax classification, payment terms, GR‑Based IV flag (vendor), etc. The person who creates the master data must sign off that they’ve verified each field against the business request.
• Thou shalt never change a valuation class on a material with existing stock. It requires a migration project. Block changes via authorization and enforce a material creation workflow that includes finance approval.
• Thou shalt always test a new master data record in a quality system before production. Even a simple material extension can reveal missing views or account determination entries.
• Thou shalt use reference materials and templates. This reduces the chance of human error in critical fields like valuation class, price control, and account assignment groups.
• Thou shalt run the reconciliation reports monthly. S_ALR_87012085 (MM vs FI inventory) and FBL5N/FBL1N (sub‑ledger vs GL) will expose master data errors before they become audit findings.
• Thou shalt maintain a data dictionary of allowed values. For example, which valuation classes are valid for which material types. This prevents the misassignment seen in Scen‑MD‑03.

16. Interactive “Try It Now” Checklist

In your SAP sandbox, perform these exercises to internalize master data dependencies:

1. Display a customer master (XD03). Navigate to each view and note the fields that affect pricing, tax, and account determination. Change one field (like tax classification) and observe the effect on a new sales order.
2. Display a vendor master (XK03). Check the GR‑Based IV flag, schema group, and tax classification. Create a PO with this vendor and see pricing.
3. Display a material master (MM03). Focus on sales, purchasing, accounting, and MRP views. Change the valuation class and try to post a goods movement (you may need to create a new material). Observe the error or different GL posting.
4. Create a customer‑material info record (VD51) and then use VA01 with the customer material number (in the “Customer Material” field) to see it convert to your internal material.
5. Simulate Scen‑MD‑01: remove the tax classification from a customer used in a sales order, create the order, and try to bill. Observe the error. Fix it and re‑bill.
6. Use V/03, V/06, V/07, V/08 to explore the condition technique and see how master data fields appear in condition tables.
7. Run the pricing analysis in a sales order and trace each condition type back to the master data fields used in the access.
8. Use SE16 to view tables A003 (tax) and KONP (condition records) to understand how master data is stored.
9. Create a material with a wrong MRP type, run MRP, and see that no planned order is created.
10. Document the master data fields required for your own company’s processes in a similar matrix.

17. Closing Thoughts – Master Data Is the Silent Architect

Every great SAP solution stands on a foundation of flawless master data. When you truly understand that a single tax classification in the customer master can ripple into a billing failure, a broken FI posting, and an auditor’s query, you stop treating master data as a clerical task and start treating it as configuration. The scenarios in this article are not invented – they are collected from real projects where I was called in to fix what a wrong master data field had broken. Now you have the map to diagnose and prevent them.

Next up in the series: Cross‑module integration (FI ↔ MM ↔ SD) – the grand finale where we trace a single transaction from sales order to production, procurement, payment, and closing, proving that all these modules are one.

Master your master data. The system will reward you with silence – the sound of everything working perfectly.

– FreeLearning365, in tech partnership with @techbook24