ADRC table — ADRC - Central Address Table

ADRC stores one physical or postal address per row, identified by an internal address number (ADDRNUMBER) rather than by business partner or customer number. The business address services layer was built so that any object needing an address - a customer, a vendor, a plant, a contact person, a one-time (CPD) partner in a sales order - stores only the address number and looks the actual address up in ADRC. This avoids duplicating address text across master tables and lets one address be shared or time-sliced independently of the object using it. A single ADDRNUMBER can have several rows in ADRC when the address is time-dependent (validity periods) or when country-specific format variants exist, so ADRC is not strictly one row per address number.

Always restrict on MANDT and on ADDRNUMBER; never scan ADRC by name or city fields alone, the table is large and those fields are not primary access paths. Because a single address number can carry several rows for different validity periods or NATION variants, a lookup by ADDRNUMBER alone can return more than one row - filter DATE_TO for the current row (typically the one with the highest or open-ended DATE_TO) and check NATION if the consuming country uses an international address format. Get the address number first from the owning object (KNA1, LFA1, VBPA, T001W) rather than trying to search ADRC directly for a business partner.

Symptom: a delivery or invoice prints the wrong address for a customer even though the customer master looks correct. Pull ADRNR from KNA1 for that customer, then select ADRC by that ADDRNUMBER and MANDT. If more than one row comes back, compare DATE_FROM and DATE_TO across rows and check which one is currently valid; a future-dated address change entered too early, or a stale row with an open DATE_TO, is a common finding. Also check NATION if the print layout is country-specific.

ADRC remains the underlying physical table for postal addresses in S/4HANA; the business address services architecture was not restructured the way finance or sales document tables were. Fiori apps and newer master data UIs read address data through CDS views layered on top, but those views are compatibility and consumption layers, not replacements for ADRC as the table of record. Existing joins written against ADRC in custom reports and forms continue to work unchanged.

Address data quality is a master data governance question, not an SD-specific one, since ADRC is shared across customer, vendor, HR, and plant address records. In practice the master data or MDG team owns creation and change of addresses through the proper maintenance transactions; the SD consultant's job is tracing which address number a document actually resolved and reporting the discrepancy, not editing ADRC directly.

KNA1 and LFA1 hold the ADRNR that anchors customer and vendor addresses respectively; VBPA carries an address number only for one-time partners in a sales document. Delivery and shipping documents pick up addresses through the partner and plant chain rather than storing address text themselves. Customer and vendor master maintenance transactions, and the dedicated address maintenance transaction, are the normal write paths into ADRC; anything else touching the table directly should be treated as suspect.