BSAS table — Accounting Cleared Items GL Accounts

One row in BSAS represents a single G/L account line item, originally posted through BKPF/BSEG, that has since been cleared. It only contains items belonging to G/L accounts that carry the open item management indicator on the account master (SKB1). Every field that exists on BSEG for that line is duplicated here as a secondary index, plus the clearing document number and clearing date. BSAS exists purely for reporting performance: instead of scanning the full BSEG table and filtering by account type and clearing status, a report can go straight to BSAS for cleared G/L items. It is populated and cleared out of sync with BSEG only in the sense that it is a derived index; the authoritative posting data always lives in BSEG.

MANDT is the leading key field and is handled automatically by the client filter, but every custom read should still restrict on BUKRS and HKONT before anything else; those two together are the practical entry point into the table's index. GJAHR narrows further and is worth adding even though clearing can technically span years for the original posting year. Never select on BSAS without at least company code, since the table can be very large in long-running company codes with heavy G/L clearing volume such as bank sub-accounts or GR/IR-style accounts. Avoid selecting on AUGDT alone across all company codes; it is not the leading part of the index and will force a full or near-full table scan.

Symptom: a G/L reconciliation shows an item was cleared but the business user cannot find it on the open item list. Selection: BSAS where BUKRS = <company code> and HKONT = <account> and BELNR = <document number> and GJAHR = <fiscal year>. If the row exists, the item is cleared, and AUGBL and AUGDT on that row give the clearing document and date; cross-check that clearing document in BKPF to see what it actually did. If no row exists in BSAS, check BSIS instead, since the item may still be open.

In S/4HANA, BSAS is implemented as a compatibility view over the universal journal table ACDOCA rather than as an independently persisted table. Existing reports and custom code that select from BSAS continue to work, but the underlying source of truth is ACDOCA. On a brownfield conversion, historical cleared items posted before the conversion may still physically reside in the classic table structure depending on how the conversion handled that data, so older postings and post-conversion postings can technically be served from different underlying storage even though the BSAS interface looks unchanged.

Questions about what a specific cleared G/L item means belong to the FI general ledger accounting team, since clearing logic and account determination are configured there. Questions about why the index itself looks inconsistent with BSEG belong to Basis or the FI technical team, since that points at an index rebuild or upgrade artifact rather than a business posting issue.

BSIS holds the open counterpart for the same G/L accounts and is the first place to check when an expected row is missing from BSAS. BSEG and BKPF are the authoritative source tables behind both indexes. SKB1 and SKA1 confirm whether an account is open-item managed in the first place, which determines whether it appears in these index tables at all. Clearing transactions such as the automatic clearing program, manual G/L clearing, and document display/change transactions are what actually move an item from BSIS into BSAS.