ERPClimb logoERPClimb
SAP tableObjectBUT000ModuleSD_O2C

BUT000 table — Business Partner General Data

BUT000 stores central, role-independent Business Partner data. One partner record identifies the BP category and grouping and contains the core person, organization, or group identity used by BP roles. It is the central starting point for S/4HANA customer and supplier master analysis, but role-specific company-code, sales, and purchasing data lives in other tables and synchronized views.

A consultant-focused reference for BUT000 covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.

Published 20 Sept 2026· 711 words

What it stores

BUT000 stores central, role-independent identity data for each SAP Business Partner. 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 PARTNER_GUID identify the Business Partner at the general-master-data level. BP category, grouping and category-dependent name/identity fields are useful for diagnosis, but they do not establish active supplier or customer roles.

  • PARTNER — Business Partner number.
  • TYPE — BP category such as person, organization, or group.
  • BU_GROUP — BP grouping and number-range context.
  • Name/identity fields — vary by BP category.
  • PARTNER_GUID — technical BP identifier used by CVI and integration.
  • Role-specific data — stored outside BUT000.

How it joins the data model

Connect BUT000 to address assignments (BUT020), identification records (BUT0ID) and the appropriate CVI mapping when customer or supplier integration is in scope. A single BP can have several addresses, IDs and organizational extensions.

  • PARTNER to BUT020 for address assignments
  • PARTNER to BUT0ID for identification numbers
  • PARTNER_GUID to CVI_CUST_LINK and CVI_VEND_LINK during customer and supplier integration

How to read it safely

When a supplier or sold-to party appears missing in a transaction, confirm the BP record first, then its role and purchasing/sales/company-code extensions. A BUT000 row alone is insufficient to prove that an organization can create a PO or sales order.

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 BUT000 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

Business Partner is the mandatory leading customer and supplier master object in S/4HANA, making BUT000 a central master-data table. Customer and supplier roles are synchronized through CVI to classic customer/vendor structures where required; do not infer sales-area or company-code data from BUT000 alone.

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

Central BP master-data governance owns core identity and duplicate prevention. FI, MM and SD own role and organizational extensions; CVI integration teams resolve mapping or synchronization failures.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Lessons and topics

Source: ERPClimb — https://erpclimb.com/sap-tables/but000ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.