BSIS table — G/L Account Secondary Index, Open Items

One row in BSIS represents a single G/L account line item, posted through FI, that has not yet been cleared. It is built as a secondary index derived from BSEG, restricted to accounts and postings that carry open item relevance, most commonly bank sub-accounts, GR/IR clearing accounts, and other technical clearing accounts that are managed on an open item basis even though they sit in the general ledger rather than in AP or AR. Once a line item is cleared, SAP moves its representation from BSIS into BSAS; the underlying BSEG row is untouched, only the index membership changes. BSIS is not a source of truth in itself, it is a read-optimized shadow of BSEG scoped to G/L open items, kept in sync automatically by the posting and clearing programs.

BSIS is a reduced, open-item-only view of the same posting that lives in full in BSEG, joined on the standard four-field document key. It always accompanies a header row in BKPF. The account itself resolves through the company code segment and chart of accounts master data. The relevant joins are listed below.

Always restrict by client, company code, and account number or account range before touching BSIS; it is a cross-company, cross-account table and an unrestricted select against it in a productive system with years of GR/IR or bank clearing history will run long. Fiscal year plus posting date range is the next filter, since BSIS still carries every un-cleared item back to the account's opening balance if nobody has ever cleared it. Do not filter on AUGDT or AUGBL expecting to find open items there, those fields are blank by definition for everything sitting in BSIS; that is a BSAS concern.

To confirm a GR/IR account has a genuine open item backlog rather than a display issue, select BSIS with BUKRS equal to the company code and HKONT equal to the GR/IR account, no date restriction. Sum DMBTR split by SHKZG. If the debit and credit sums are far apart and the count of rows is large, the backlog is real and sits in the ledger, not in a report layer.

On S/4HANA, BSIS is retained as a compatibility view name for existing reports and custom code, but the physical data lives in the universal journal table ACDOCA. The open/cleared split that BSIS and BSAS used to enforce structurally is now derived logic on top of ACDOCA, keyed by clearing document fields rather than by separate physical tables. Custom ABAP written against BSIS generally still runs, but new development should read ACDOCA directly, since that table carries the full line item history including cleared items in one place.

A discrepancy surfaced from BSIS is first a G/L accounting question, owned by the FI team responsible for the affected account, particularly for GR/IR and bank clearing accounts where MM or Treasury processes also post. Technical sync issues between BSIS and BSEG after a data correction are an ABAP/Basis matter, since they usually point to a direct table change bypassing standard posting logic.

BSAS holds the cleared counterpart of the same G/L open items and is the first place to look when a document is missing from BSIS. BKPF and BSEG are the document header and full line item detail that BSIS indexes. SKB1 and SKA1 carry the account master data that determines whether an account even generates BSIS entries. Clearing transactions such as automatic and manual G/L clearing, and postings from MM invoice verification for GR/IR, are what populate and empty this table.