BUT020 table — Business Partner Address Assignments
BUT020 links Business Partners to address numbers and address usages with validity. A Business Partner can have multiple addresses and usage assignments, so the correct address depends on partner, usage, and effective date rather than simply taking the first address number. The actual postal address fields are stored in central address management tables such as ADRC.
A consultant-focused reference for BUT020 covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 698 words
What it stores
BUT020 stores address numbers and address usages assigned to Business Partners, including date validity. Each row must be interpreted using the complete technical key and the application process that writes it. A consultant should first establish whether the row represents current state, a dated master-data slice, a document item, a history event, an index entry or a compatibility representation. Organizational levels, validity dates, fiscal years, ledgers, languages, statuses and sequence numbers are part of the grain whenever those dimensions exist. The table should be read as evidence of application behavior, not as an isolated spreadsheet. Confirm the owning business object and configuration before deciding that a value is wrong.
Key fields
PARTNER and address assignment fields identify which address is connected to a Business Partner. A partner can have more than one address and validity/context may matter for a particular business process.
- PARTNER — Business Partner number.
- ADDRNUMBER — central address number, joined to ADRC.
- Address usage or assignment context — determines business purpose.
- Validity dates — determine which assignment is effective.
- Standard/default indicators — do not assume every assigned address is the default.
How it joins the data model
Start with the BP identifier, inspect address assignments in BUT020, and then follow the address reference through supported Business Address Services structures. A one-to-many address relationship should not be collapsed without a defined selection rule.
- PARTNER to BUT000
- ADDRNUMBER to ADRC
- PARTNER to customer or supplier integration links when tracing synchronized addresses
How to read it safely
If a document uses the wrong address, check the BP address usage and the process-specific customer/supplier view before modifying data. An address record's existence does not prove that it is the default for every process.
How to prove it in the data
Take one reproducible example from the relevant SAP screen, report or application log. Record its full displayed key, organizational context, key date, language and status. Locate the matching BUT020 row using those values, then follow the documented parent and child joins without dropping key components. Compare the result using the same key date and ledger. When values differ, test for leading-zero conversion, multiple validity slices, inactive history, parallel ledgers, fiscal-year boundaries, archived data and asynchronous replication. Save the read-only evidence before escalating. If the row is wrong, reproduce the maintenance path in a non-production system and route the fix to the application owner rather than changing the table.
ECC vs S/4HANA
BUT020 remains part of the strategic Business Partner address model in S/4HANA. Use it together with address usage and validity plus ADRC; customer or supplier screens can present synchronized views, but BP address ownership remains central.
Common pitfalls
- Selecting by one convenient identifier and silently mixing organizational units, years, ledgers, languages or validity periods.
- Joining on a partial key or descriptive value and creating duplicates that appear to be legitimate business rows.
- Ignoring inactive, deletion, reversal or status indicators and reporting retained history as current state.
- Assuming this table is authoritative without checking S/4HANA simplification, Business Partner synchronization, Universal Journal, MATDOC, CDS views or an external cloud source.
- Treating a missing row as proof that an event never occurred even though logging, replication, authorization and archiving scope can differ.
- Updating table rows directly instead of correcting data through the supported transaction, app, API or migration process.
Whose problem this is
Business Partner master-data governance owns address correctness and usages. SD, MM or FI application owners determine which address role the document should use; integration teams resolve mapping failures.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/but020ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.