BSIK table — Vendor Open Items Index Table

Each row in BSIK represents one line item of a financial accounting document that was posted against a vendor reconciliation account and has not yet been cleared. It is not an independent ledger; it is a redundant, synchronously maintained copy of the relevant BSEG rows, filtered to open items only, kept so that open-item reporting and the payment program do not have to scan the full line-item table BSEG with an aggregate condition every time. The moment an item is cleared, whether by payment, credit memo offset, or manual clearing, SAP moves the corresponding row out of BSIK and writes it into BSAK instead. A vendor with heavy activity can have thousands of historical cleared items in BSAK while BSIK stays small and reflects only current exposure.

MANDT is always implicit and rarely needs to be specified manually in a client-bound session. Always restrict on BUKRS and LIFNR together; either one alone on a large productive vendor ledger produces a slow, unselective read. GJAHR narrows further when a fiscal year is known, but be careful: an invoice posted in one year can still be open in a later year, so do not use GJAHR to prove an item does not exist unless the search also covers adjacent years. For aging or due-date work, select on BUDAT or compute due date from ZFBDT plus the payment terms rather than filtering directly on a derived date that is not stored. Avoid selecting on WRBTR or DMBTR ranges as a primary filter; they are not selective and will scan.

Symptom: a vendor invoice is not being picked up by the payment run. Select BSIK where BUKRS equals the company code and LIFNR equals the vendor, no other restriction. Check ZLSPR on the returned row for a payment block, check ZLSCH for a payment method that does not match the run's parameters, and check ZFBDT together with the payment terms to see whether the calculated due date actually falls inside the payment run's date window. If the item is absent from BSIK entirely, check BSAK next; it may already be cleared.

In S/4HANA the line-item detail moves into the universal journal table ACDOCA, and BSIK is no longer populated by new postings. It is retained as a compatibility view that reads open vendor items out of the universal journal on the fly, so existing reports, custom ABAP, and BAPIs that select from BSIK by name generally continue to work without code changes. Consultants relying on direct table dumps or database-level tools should be aware the underlying storage and performance characteristics are different from the classic ECC table, even though the field layout looks the same.

Questions about whether a specific vendor item is open, blocked, or due belong to accounts payable accounting, using standard vendor line item display rather than raw table access. Structural questions, custom reports built directly against BSIK, and any apparent mismatch between BSIK and BSEG belong to the FI technical or ABAP development team supporting accounts payable.

BSAK holds the cleared counterpart of the same vendor items once payment or clearing has occurred. BSEG carries every line item regardless of clearing status and account type, and is the underlying source both BSIK and BSAK index. BKPF supplies the document header context. LFC1 carries vendor transaction figures used to cross-check open item totals. Postings arrive through standard AP transactions such as invoice entry, payment posting, and clearing transactions, all of which write BSEG and, for open vendor items, BSIK simultaneously.