ERPClimb logoERPClimb
SAP tableObjectBSIDModuleFI_FICO

BSID table — Customer Open Items (Compatibility View in S/4HANA)

BSID is the classic Accounts Receivable index for customer line items that are still open. In S/4HANA the former physical application index is replaced by an identically named compatibility view over the simplified Finance data model. Existing reports can continue to read BSID, but new extensions should use released customer-line-item or Universal Journal views.

This page covers what BSID actually represents as a customer open item index, the fields worth restricting on, and the joins back to BKPF and BSEG. The pitfalls section focuses on why row counts and balances read from BSID mislead people who forget it only shows one side of the customer ledger at a point in time.

Published 20 Sept 2026· 1,091 words

Diese Seite ist noch nicht auf Deutsch verfügbar.

What it stores

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.

Key fields

  • MANDT - client, always the first restriction
  • BUKRS - company code the item was posted in
  • KUNNR - customer account number
  • GJAHR - fiscal year of the posting
  • BELNR - accounting document number
  • BUZEI - line item number within the document
  • BUDAT - posting date
  • BLDAT - document date
  • SHKZG - debit/credit indicator, D or H
  • DMBTR - amount in local currency
  • WRBTR - amount in document currency
  • WAERS - document currency key
  • ZFBDT - baseline date for cash discount and due date calculation
  • ZTERM - payment terms key
  • AUGDT and AUGBL - clearing date and clearing document, blank while the item remains open
  • ZUONR - assignment field, often used for reference matching

How it joins the data model

  • BSID-BUKRS = BKPF-BUKRS and BSID-BELNR = BKPF-BELNR and BSID-GJAHR = BKPF-GJAHR to reach the document header
  • BSID-BUKRS = BSEG-BUKRS and BSID-BELNR = BSEG-BELNR and BSID-GJAHR = BSEG-GJAHR and BSID-BUZEI = BSEG-BUZEI, since BSID is a filtered copy of the customer lines already sitting in BSEG
  • BSID-KUNNR = BSAD-KUNNR for the same customer's cleared items, needed when reconciling what moved out of open status
  • BSID-KUNNR and BSID-BUKRS join to KNC1 for customer transaction figures by fiscal year, useful for reconciling total balances against the sum of open plus cleared items
  • BSID rows for a payment run can be traced onward through REGUH and REGUP when the clearing document originated from an automatic payment proposal

How to read it safely

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.

How to prove it in the data

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.

ECC vs S/4HANA

SAP's 2025 S/4HANA simplification list explicitly identifies BSID as a compatibility view replacing the former physical index table. New code should not rely on direct update, locking, or index-maintenance behavior.

Common pitfalls

  • Treating a missing row in BSID as proof an invoice was never posted. It may simply have been cleared already and now lives in BSAD; always check both before concluding anything.
  • Summing DMBTR across BSID for a customer and calling it the account balance. That total is only the open portion. The true balance as of a date requires either KNC1 transaction figures or a proper open-item-as-of-date report, not a raw BSID sum.
  • Assuming BSID reflects the current moment when a report was actually generated hours or days earlier. If a screenshot or extract shows an item as open, always check whether AUGDT has since been populated before escalating a collections issue.
  • Editing or deleting rows directly in BSID through table maintenance to fix a stuck item. BSID is a derived index, not the record of truth. Direct changes desynchronize it from BSEG and BKPF and create inconsistencies that surface later as unreconcilable differences.
  • Forgetting that credit memos, down payments, and statistical postings for the same customer all appear as separate lines. Counting rows and assuming each row is one invoice leads to wrong item counts in aging analysis.
  • Ignoring special G/L indicator lines that also route through this table for down payments and guarantees, then double-counting exposure that is already represented elsewhere.

Whose problem this is

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.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tables/bsidERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.