BSID table — Customer Open Items table

One row in BSID is one open line item posted to a customer account in Financial Accounting, meaning a debit or credit posting that has not yet been matched against an offsetting posting through clearing. It is populated automatically whenever a document is posted to a reconciliation-account customer and removed from BSID the moment that line is cleared, at which point an equivalent row appears in BSAD. BSID is not a primary data source, it is a special G/L index maintained in parallel to BSEG specifically so that open-item reports, dunning, and credit management do not have to scan the full line-item table. It only ever shows customer-line items, never vendor or G/L account lines, and only ever shows the open subset.

Always restrict on MANDT, then BUKRS, then KUNNR or a customer range, then GJAHR if the volume is large. BSID has no built-in date range restriction beyond BUDAT or BLDAT, and neither is indexed as tightly as BUKRS plus KUNNR, so a report scanning all customers across all company codes without a KUNNR restriction will run long on any productive system with real transaction volume. Because it is a live index, a read taken now and a read taken five minutes later during a dunning or payment run can differ, since clearing removes rows in real time. Never select on BSID alone to compute a balance without knowing the reporting date the business actually wants, since open items existing today do not mean they existed on a past cutoff date.

A customer complains an invoice is still showing as unpaid despite payment being received. Select BSID with BUKRS equal to the company code and KUNNR equal to the customer and BELNR equal to the invoice document number. If the row still exists in BSID with AUGDT and AUGBL blank, the item is genuinely still open in the system regardless of what the customer claims about the bank transfer. If no row is returned, check BSAD with the same key; a row there with a populated AUGBL confirms it was cleared and the complaint is about visibility, not posting.

In S/4HANA, BSID is retained as a compatibility view rather than a physically maintained transparent table. The underlying open-item data is now derived from the universal journal in ACDOCA at query time, filtered to unmatched customer lines, so BSID continues to return correct results for existing reports and custom code but is no longer where the data is physically stored. New development should read from ACDOCA directly or use the released reporting views rather than selecting BSID, though existing selects against BSID keep working.

Accounts receivable accounting owns questions about why a specific customer item is or is not open. Basis or the technical team owns performance complaints about BSID selections timing out. A functional FI consultant is the right escalation point for discrepancies between BSID and the customer's own statement of account, since that usually traces back to configuration of clearing rules or payment terms rather than a data bug.

BSAD holds the cleared counterpart for the same customer lines once AUGDT and AUGBL are set. BSEG is the full line-item table BSID is derived from, and BKPF is the document header both join back to. BSIK and BSAK are the equivalent open and cleared tables for vendors. Transactions that write to BSID include standard sales invoice posting, incoming payment posting, and any manual FI document posted with a customer reconciliation account; F110 payment runs and dunning transactions read it heavily but do not write it directly, they trigger the postings that update it.