XD02 — Change Customer Centrally in SD
XD02 changes an existing customer master record across general data, company code data, and sales area data in a single transaction. It only displays segments that already exist for that customer; a missing sales area or company code tab almost always means the customer was never extended there, not a system error or authorization problem.
This page covers XD02, the central customer change transaction in SD, focusing on why segments appear or disappear and what that actually indicates. It walks through the real navigation sequence, the tables the save touches, and how to prove extension, blocking, and lock issues directly in the data rather than guessing.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,183 words
Purpose
XD02 changes an existing customer master record, covering general data, company code (accounting) data, and sales area data in one transaction. The structural fact that explains most confusion around it is that a customer master is not a single record - it is a general data segment plus a variable, independently maintained set of company code segments and sales area segments. XD02 only shows the segments that were already created for that customer via extension. If a customer was never extended to a given sales organization, distribution channel, or division combination, that tab simply does not render - it looks like a missing authorization or a defect, but it is actually a missing extension, and the fix is XD01 (extend with reference), not forcing something in XD02.
When it is used
XD02 is used whenever an existing customer's data needs to change: address, payment terms, tax classification, pricing group, delivery priority, output control, incoterms, partner functions, credit control area assignment, and so on. Consultants reach for XD02 over VD02 (sales-view only) or FD02 (accounting-view only) when the change spans both functional areas, or when it is not yet clear which segments are affected and it is faster to see everything that exists for the customer at once. It also gets used in migration cutover, batch input recordings, and any core-system landscape where customer-vendor integration to Business Partner is not active or not enforced for direct edits.
How to use it in practice
- Call XD02, enter the customer number, and leave company code and sales area blank to reach the segment selection screen showing exactly which company codes and sales areas exist for this customer.
- Select the views needed: general data (address, control, marketing, payment transactions, unloading points), company code data (account management, payment transactions, correspondence, insurance), and sales area data (sales, shipping, billing, partner functions).
- Step through screens with Enter or tab; only sales area combinations already extended appear as selectable lines, everything else is simply not there.
- Change the required field and save with Ctrl+S; the system runs account-group field status checks and mandatory-field checks before the write commits.
- If a change is disputed, pull the change document history to see the old value, new value, user, and timestamp.
Key data objects
- KNA1 - general data: name, search terms, address key, country, industry, central block flags
- KNB1 - company code data: reconciliation account, payment terms, dunning procedure, company-code-level block
- KNVV - sales area data: sales org / distribution channel / division level fields such as pricing procedure determinants, terms of delivery, delivery priority, sales-area-level block
- KNVP - partner functions assigned per sales area
- KNVI - tax classification per sales area
- KNBK - bank details linked to the customer
- ADRC - the linked central address object, since address data is stored separately from KNA1 and referenced by an address number
How to prove it in the data
To confirm whether a sales area is extended, query KNVV filtered on KUNNR, VKORG, VTWEG, SPART and check for a matching row - no row means no extension, regardless of what the tab in XD02 seems to suggest. Join KNA1 on KUNNR to confirm general data exists at all. Check KNB1 filtered on KUNNR and BUKRS for company code extension. For change history, filter change document header by the customer object class and join to the change document item table on the document number to see field-level before/after values, user, and date.
ECC vs S/4HANA
On S/4HANA, customer master is technically represented as a Business Partner with synchronization (customer-vendor integration) writing through to KNA1, KNB1, and KNVV in the background. XD02 may still be available depending on system configuration, but the strategic transaction is Maintain Business Partner in the Fiori environment. When XD02 is used and CVI synchronization is not fully consistent, changes can appear in one view before the other catches up - check synchronization status before assuming the change failed.
Common pitfalls and how to diagnose them
- Segment or tab missing: the customer was never extended to that company code or sales area. The tab is absent, not greyed out. Confirm by checking KNB1 or KNVV directly for the combination before assuming an authorization or configuration bug. Fix by extending through XD01 with reference, not by trying to create it inside XD02.
- Field greyed out: account group field status settings mark the field as display-only for that account group, or a central field is locked for change once it has already been maintained differently in one company code and central field control is active. Check the account group's field status group before assuming a user error.
- Change does not appear to take effect: an open sales order created before the master data change keeps the old pricing and partner data because redetermination only happens on new document creation or an explicit manual re-read. This is expected behavior, not a defect.
- Customer appears blocked but change was just made: central block (KNA1) and sales-area-specific block (KNVV) are separate fields. A central block masks activity everywhere; a sales-area block only stops new sales documents in that specific area. Check both before concluding the block was lifted.
- Authorization failure disguised as missing extension: a missing authorization for the sales organization or company code authorization group can produce a screen with fewer or no fields, closely mimicking a non-extended customer. Run an authorization trace before assuming extension is the root cause.
- Lock errors: the customer master record is locked by another user or a background job (credit management sync, mass change run). XD02 returns a lock message naming the holding user and transaction - resolve the lock at the source, do not retry blindly.
Whose problem this is
Functional SD or master data governance owns the content of the change and which fields should hold which values. Basis owns locks, background job scheduling, and authorization object assignment. ABAP is involved only for custom field status logic or user exits on save. A good handover includes the customer number, the exact segment and field, the error or symptom text verbatim, and the account group in use.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/xd02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.