SKB1 table — G/L Account Company Code Segment Table
SKB1 holds the company-code-dependent segment of the general ledger account master, one row per company code and account number. It stores account currency, open item management, posting block, deletion flag, field status group, and sort key. It is joined by chart-of-accounts key to SKA1 for the account itself and to SKAT for the description text.
SKB1 is the company code view of a G/L account, the counterpart to the chart-of-accounts view held in SKA1. This page covers its key fields, the joins consultants actually write against it, and the recurring mistakes made when diagnosing posting blocks, currency mismatches, and open item management errors.
Published 15 Sept 2026· 1,117 words
What it stores
One row in SKB1 represents the company-code-specific control data for a single G/L account: the combination of company code (BUKRS) and account number (SAKNR). Where SKA1 holds attributes shared across every company code that uses a given chart of accounts (account group, account currency indicator flags, control at chart level), SKB1 holds the attributes that can differ per company code: whether the account carries open items, whether it is blocked for posting in that company code, which field status group applies, account currency, and the sort key used to build the assignment field on line items. A G/L account only exists functionally in a company code once its SKB1 row has been created; the SKA1 row alone is not enough to post to it there.
Key fields
- MANDT - client
- BUKRS - company code
- SAKNR - G/L account number, joins to SKA1 and SKAT
- WAERS - account currency; postings in other currencies are only allowed if the account is not restricted to this currency
- XOPVW - open item management indicator; changing this on a live account requires a balance of zero and a technical conversion, not a simple field edit
- XSPEB - account blocked for posting in this company code
- XLOEV - account marked for deletion in this company code
- XINTB - account posts automatically only (blocked for manual/direct posting)
- FSTAG - field status group, controls which fields are mandatory, optional, or suppressed on line item entry
- ZUAWA - sort key, determines the default content of the assignment field on posted line items
- ALTKT - alternative account number for the company code, used in parallel or local reporting
- BEGRU - authorization group restricting who can maintain or display the account
How it joins the data model
- SKB1-SAKNR = SKA1-SAKNR and SKB1-KTOPL implied via SKA1-KTOPL, the chart-of-accounts-level record
- SKB1-SAKNR = SKAT-SAKNR (with SKAT-KTOPL and SKAT-SPRAS) for the language-dependent account description
- SKB1-BUKRS = T001-BUKRS to confirm the company code exists and to read its chart of accounts assignment
- SKB1-BUKRS = BSEG-BUKRS and SKB1-SAKNR = BSEG-HKONT, the join used to check whether an account that appears in postings is actually maintained for that company code
- SKB1-FSTAG links conceptually to the field status group configuration table, not to a table in this list, and controls what BSEG allows during entry
How to read it safely
SKB1 is client-dependent (MANDT) and small relative to line item tables, but it is still a master data table, not a transactional one, so a full scan across all company codes is cheap compared to BSEG or ACDOCA. Always restrict by BUKRS first; SAKNR alone is not selective if the same account number is used across many company codes on the same chart of accounts. When checking whether an account is usable, read SKB1 together with SKA1 in the same query rather than assuming SKA1 existing implies SKB1 exists — the two are maintained in separate steps and can be out of sync.
How to prove it in the data
Symptom: postings to a G/L account fail with a message that the account does not exist in the company code, even though it appears in account master search. Select SKB1 for BUKRS = the company code in question and SAKNR = the account. No row returned confirms the account was created at chart-of-accounts level (SKA1 exists) but never extended to that company code. A row with XSPEB or XLOEV set to 'X' confirms it exists but is blocked or flagged for deletion, a different message and a different fix.
ECC vs S/4HANA
SKB1 continues to exist as a transparent table on S/4HANA and is not merged away by the Universal Journal changes, since it is master data, not the line item layer that ACDOCA replaced. G/L account maintenance on S/4HANA increasingly uses the combined account master view that presents chart-of-accounts and company code data together in one editing screen, but the underlying persistence in SKB1 and SKA1 is unchanged. Reports built directly against SKB1 remain valid.
Common pitfalls
- Assuming an account visible in one company code is usable everywhere. SKA1 is shared across the chart of accounts but SKB1 is per company code; the account must be extended before it can be posted to in a new company code.
- Changing XOPVW (open item management) directly in the field. This is only safe when the account balance is zero; on an account with a balance, SAP requires a load conversion program, and a direct table or transaction change against a non-zero balance corrupts open item reconciliation.
- Reading FSTAG and concluding the field behaviour without checking the field status group configuration itself. SKB1 only stores which group is assigned; the actual mandatory/optional/suppressed rules live in the group's own configuration, and a wrong assumption here leads to fixing the wrong object.
- Confusing XSPEB (blocked for posting in this company code) with a block set at chart-of-accounts level in SKA1. The two flags are independent; an account can be open in SKA1 and blocked in one specific company code's SKB1 row, or vice versa depending on which layer was touched last.
- Forgetting that ZUAWA only sets a default. Users can override the assignment field manually at posting time, so a report built on the assumption that ZUAWA logic always populated the field correctly will miss manually overridden entries.
- Treating a missing SKB1 row as a data error to be fixed by direct table maintenance. It should be fixed through the account maintenance transaction so that dependent checks (currency, chart of accounts consistency, authorization) run correctly.
Whose problem this is
Master data governance for the chart of accounts and its company code extensions typically sits with central FI configuration or a G/L master data team, not with the functional consultant running a specific process. A missing or blocked SKB1 row discovered during testing is a master data request, routed for account extension or unblocking, not a configuration defect to be fixed in customizing.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/skb1ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.