BUT0ID table — Business Partner Identification Numbers
BUT0ID stores identification numbers assigned to Business Partners by identification type, for example external registration or tax-related identifiers depending on configuration. Multiple identification types and validity rules can exist for one partner, so the identification category is part of the business meaning and an ID value should never be interpreted without its type.
A consultant-focused reference for BUT0ID covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 682 words
What it stores
BUT0ID stores external identification numbers assigned to Business Partners by identification type and 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
Identification type and identification number must be evaluated alongside the Business Partner key. Different identification types have different business and regulatory meaning; a matching number alone does not establish a duplicate BP.
- PARTNER — Business Partner number.
- TYPE — identification type/category.
- IDNUMBER — identification value.
- Validity or issue context — where configured for the identification type.
- Configuration of identification categories — determines validation and business meaning.
How it joins the data model
Join BUT0ID to the Business Partner by the partner identity and retain the identification type where the business process requires it. Avoid a broad join on IDNUMBER alone when different schemes or partner types are possible.
- PARTNER to BUT000
- identification type to Business Partner customizing
- PARTNER to CVI link tables when reconciling customer or supplier identity
How to read it safely
For a failed customer onboarding or compliance check, verify the expected ID type, issuing context and partner master maintenance history in the supported BP application. Do not expose national IDs or other sensitive numbers in diagnostic output.
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 BUT0ID 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
BUT0ID remains part of the S/4HANA Business Partner model. Customer and supplier integrations can consume BP identification data, but validation and mandatory rules depend on identification-category configuration and country/process requirements.
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
Master-data governance and the owning compliance team validate identification requirements. Integration engineers investigate mapping and validation errors while protecting personally identifying data.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/but0idERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.