XD02 — XD02 — Change Customer Centrally (ECC; redirects to BP in S/4HANA)
XD02 is the classic ECC transaction for changing customer general, company-code and sales-area data in one interface. In SAP S/4HANA, the classic XD02 transaction is redirected to BP; customer maintenance is performed through the Business Partner model and Customer/Vendor Integration.
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.
Published 20 Sept 2026· 1,137 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
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
In SAP S/4HANA, SAP redirects XD02 to BP as part of the mandatory Business Partner approach. Do not describe XD02 as a native independent S/4HANA maintenance UI or suggest that BP synchronization is optional. Current guidance should start from transaction BP and the relevant customer roles.
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.