BSIM table — Material Account Document Index (Legacy / Compatibility in S/4HANA)
BSIM is a classic secondary index linking material-related accounting document items to material and accounting keys. It was designed to accelerate ECC-style access patterns rather than to be a business document of its own. In S/4HANA the index is part of the simplified Finance and Material Ledger compatibility model, so new reporting should not be designed around direct BSIM persistence.
A consultant-focused reference for BSIM covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 734 words
What it stores
BSIM stores a classic secondary index connecting material-related account document items to material and accounting document keys. 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
BSIM is an ECC-era index concept connecting material-related postings and account line items. Its precise availability and semantics depend on the installed release; do not assume it is the authoritative S/4HANA materials-to-FI reporting source.
- BUKRS — company code.
- BELNR/GJAHR/BUZEI — accounting document, fiscal year, and line item.
- MATNR — material number where relevant.
- Valuation or plant context — interpret with the material/accounting source document.
- S/4HANA — treat BSIM as compatibility-oriented, not a primary new-document store.
How it joins the data model
Verify the actual DDIC object and key structure in the system before joining. For S/4HANA analysis, trace the material document through its supported material-document view and accounting reference instead of copying an ECC-only BSIM join.
- accounting key to BKPF and BSEG
- MATNR to MARA
- material-document references to MKPF and MSEG in ECC or MATDOC in S/4HANA
How to read it safely
When a migration report returns no records from BSIM, first check whether the object is retained, redirected or replaced in that S/4HANA deployment. Reconcile one known material document with standard reports rather than treating an empty legacy index as missing financial postings.
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 BSIM 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
SAP S/4HANA simplification documentation lists BSIM among classic tables replaced by compatibility-view redirection. Current accounting and material information comes from new persistence such as ACDOCA and MATDOC-related models. Legacy SELECTs can be redirected, but new custom code should use released views and the new data model.
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
MM inventory accounting and FI jointly own the reconciliation. ABAP and the S/4HANA conversion team determine whether an old index dependency must be redesigned against a supported data model.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/bsimERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.