BSEG table — BSEG Accounting Document Segment Table
BSEG stores the line items of every FI accounting document, one row per posting line, keyed by company code, document number, fiscal year and line item. It carries the amounts, account, and posting key for each line but not the document header data such as posting date or document type, which lives in BKPF. It is a cluster table in classic ECC and a compatibility view over ACDOCA in S/4HANA.
BSEG is the line-item table behind every FI posting, joined to BKPF for header data and to the open/cleared item tables for account-specific reporting. This page covers its key fields, how to select against it without a runtime disaster, and the pitfalls that trip up consultants who treat it as a normal transparent table.
Published 15 Sept 2026· 1,136 words
What it stores
One row in BSEG represents a single line item of an FI accounting document: one debit or credit posting to one G/L account, customer, vendor, or asset within one document. A document with ten lines produces ten BSEG rows sharing the same company code, document number and fiscal year, distinguished by the line item counter. The table holds the posting-level detail: amount in document and local currency, the account posted to, the posting key that defines debit/credit and account type, tax code, cost assignment fields, payment terms, and clearing status. It does not hold anything that lives once per document, such as posting date, document date, document type, or the entry user; those fields sit in BKPF and must be joined in separately.
Key fields
- MANDT - client
- BUKRS - company code, part of the key
- BELNR - accounting document number, part of the key
- GJAHR - fiscal year, part of the key (same document number can recur across years)
- BUZEI - line item number within the document, completes the key
- BSCHL - posting key, determines debit/credit and account type
- KOART - account type: S (G/L), K (vendor), D (customer), A (asset), M (material)
- SHKZG - debit/credit indicator, S or H
- DMBTR - amount in local (company code) currency
- WRBTR - amount in document currency
- HKONT - G/L account posted to
- KUNNR - customer number, populated when KOART is D
- LIFNR - vendor number, populated when KOART is K
- SAKNR - G/L account number on the line, used alongside HKONT
- ZUONR - assignment field, used for matching in clearing
- MWSKZ - tax code
- AUGBL - clearing document number, blank if the item is open
- KOSTL - cost center
- PRCTR - profit center
How it joins the data model
- BSEG-BUKRS = BKPF-BUKRS and BSEG-BELNR = BKPF-BELNR and BSEG-GJAHR = BKPF-GJAHR to pull posting date, document type and reference
- BSEG-HKONT = SKB1-SAKNR (company code segment of the G/L account master)
- BSEG-HKONT = SKA1-SAKNR for the chart-of-accounts segment
- BSEG (KOART = K) rows are mirrored into BSIK (open) or BSAK (cleared) for vendor line reporting
- BSEG (KOART = D) rows are mirrored into BSID (open) or BSAD (cleared) for customer line reporting
- BSEG (KOART = S) rows are mirrored into BSIS (open) or BSAS (cleared) for G/L line reporting
How to read it safely
Never select from BSEG without restricting on BUKRS plus at least one of BELNR, GJAHR range, or account. It is a cluster table in ECC, physically stored across DB tables and reassembled by the database interface, so a broad select without company code and year will scan enormous volumes even where the technical index looks fine. MANDT is implicit in any ABAP select and irrelevant in native SQL access, which is normally blocked on this table anyway. If the requirement is 'all open items for vendor X' or 'all G/L lines on account Y for period Z', go through BSIK/BSID/BSIS or BSAK/BSAD/BSAS instead, since those are proper indexed tables built for that access pattern; BSEG itself is not.
How to prove it in the data
Symptom: a vendor invoice looks posted but does not appear on the vendor line item report. Select BSEG restricted by BUKRS and LIFNR for the vendor, joined to BKPF on BUKRS/BELNR/GJAHR, and check GJAHR and BUZEI exist for the document number the user quotes. If the row exists in BSEG with AUGBL blank but is missing from BSIK, the open-item index is out of sync with the cluster and needs a technical rebuild, not a repost by the user.
ECC vs S/4HANA
In S/4HANA, BSEG is retained as a compatibility view so existing ABAP code, queries and reports that reference it continue to return correct results. The actual data of record is the universal journal table ACDOCA, which unifies FI line items with controlling, asset accounting and material ledger detail in a single row per line. New development should read from ACDOCA directly or through the released CDS views built on it; BSEG remains reliable for read access but is not where new custom reporting should be built.
Common pitfalls
- Assuming BSEG has a posting date field. It does not; posting date, document date and document type live in BKPF and every date-based query needs the join.
- Selecting on HKONT alone without KOART. The same account number range can theoretically appear differently depending on account type context, and reconciliation accounts for vendors/customers show HKONT populated even though the business partner is the real key via LIFNR or KUNNR.
- Running a wide-open BSEG select in a background job without company code and fiscal year restriction. On a live productive system with years of history this can lock up dialog work processes or blow the runtime budget of a batch job.
- Treating AUGBL as proof of full clearing. A partially cleared item still carries a clearing document reference on the applied portion; the open/cleared status per amount requires reading BSIK/BSAK or BSID/BSAD rather than inferring it from BSEG alone.
- Comparing DMBTR across documents in different currencies without checking WAERS. DMBTR is always local currency but the local currency itself is company-code dependent, so summing DMBTR across company codes with different local currencies produces a meaningless total.
- Expecting real-time consistency between BSEG and the open item tables under heavy parallel posting. There have been timing windows historically where a document is visible in BSEG before its BSIK/BSID entry is written; a report reconciliation should always tie back to BKPF status, not assume instantaneous propagation.
Whose problem this is
Data questions on BSEG belong to the FI/CO functional consultant or the accounting team that owns the posting process, since the fix is almost always in how the document was posted, cleared, or reversed. Basis gets involved only when the question is one of index consistency between BSEG and BSIK/BSID/BSIS, or of query performance against the cluster.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/bsegERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.