FS00 — GL Account Master Record Maintenance
FS00 is the central transaction for creating, changing and displaying General Ledger account master records. It combines two distinct data segments in one screen: the chart of accounts segment, shared across all company codes using that chart, and the company code segment, which is local to one company code. Most posting errors trace back to one segment existing without the other.
This page covers FS00, the transaction used to maintain GL account master data at both chart-of-accounts and company-code level. It focuses on the diagnostic patterns that produce posting failures: incomplete extension, field status conflicts, currency setup, blocking, reconciliation account misuse, and unsafe changes to open item management or line item display after postings already exist.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,256 words
Purpose
FS00 lets a consultant create, change or display a GL account master record. A GL account master record is not one flat record: it has a chart of accounts segment (account group, account type, short and long text) that is shared by every company code assigned to that chart of accounts, and a company code segment (currency, tax category, reconciliation account indicator, open item management, line item display, field status group, blocking indicators) that is local to a single company code. The structural fact that explains most confusion: an account can exist at chart of accounts level and still be unusable for posting because it was never extended to the company code, or the reverse assumption gets made and someone tries to fix a company-code-level symptom by editing the chart of accounts segment.
When it is used
FS00 is used during chart of accounts design, new company code rollout, and whenever a posting fails with an account-related error and the master data needs inspection or correction. It sits upstream of every FI posting transaction: FB50, FB60, FB70 and the automatic postings from MM and SD all validate against the GL account master before allowing a document to be saved. A consultant reaches for FS00 rather than a posting transaction when the question is about the account itself — is it blocked, does it carry open item management, what field status group governs it — not about a specific document. For bulk creation or mass changes across many accounts or company codes, mass maintenance transactions or the equivalent Fiori app are the practical choice instead of repeating FS00 one account at a time.
How to use it in practice
- Enter the GL account number and the company code (leave company code blank to work only at chart of accounts level).
- Choose Create, Change or Display; for a new account, either enter data manually or use 'create with reference' to copy an existing similar account.
- On the chart of accounts segment, set account group (this drives the field status of the master record screen itself), account type, and the short and long description.
- On the company code segment, set account currency, tax category, whether postings without tax are allowed, reconciliation account type if applicable, open item management, line item display, sort key, field status group, and any blocking indicators.
- Save. Review the account in Display mode afterward to confirm both segments were actually written, especially after a create-with-reference copy.
Key data objects
- SKA1 - chart of accounts segment: account number, chart of accounts, account group, account type, control data shared across company codes.
- SKB1 - company code segment: currency, field status group, open item management flag, line item display flag, blocking indicators, reconciliation account indicator.
- SKAT - account descriptions by language.
- BSEG and BKPF - not written by FS00 itself, but every posting document line references the account maintained here, which is why master data changes on an account with existing line items are risky.
How to prove it in the data
Pull SKB1 filtered on company code (BUKRS) and account number (SAKNR) and check the open item management flag, the line item display flag, the field status group, and the posting block indicator. Cross-check SKA1 filtered on the same account and the chart of accounts (KTOPL) to confirm the account actually exists there and the account type matches expectations. If a posting fails with an account-not-found or account-not-extended message, the account will be present in SKA1 but absent from SKB1 for that company code — that gap is the proof.
ECC vs S/4HANA
FS00 still functions in S/4HANA and the underlying SKA1 and SKB1 structures remain the concept behind the master data, though S/4HANA's data model unifies GL account and, in account-based CO-PA configurations, cost element concepts more tightly than classic ECC did. SAP's recommended entry point going forward is the Fiori app for managing GL account master data or managing the chart of accounts, but FS00 remains available as a compatible transaction and is still the fastest way to check a single account's configuration during an incident.
Common pitfalls and how to diagnose them
- Extension gap: the account exists in the chart of accounts but was never created for the company code that is trying to post. Check SKA1 first, then SKB1 for the exact company code in the error. Fixing this in FS00 is a company-code-segment create, not a chart-of-accounts edit.
- Field status conflict: the field status group on the GL account and the field status defined on the posting key disagree, producing a 'field is a required entry field' or 'field cannot be entered' error at posting time. The GL account's field status group is not the only source — the posting key's field status can override or conflict, so the fix sometimes belongs in the posting key configuration, not the master record.
- Blocked account: someone set the posting block at chart of accounts or company code level, often during a cleanup or migration, and forgot to remove it. This produces a hard stop at posting with no ambiguity in the message; check the blocking indicators on both segments before assuming a field status issue.
- Currency setup mismatch: account currency differs from company code currency and 'only balances in local currency' was not set as intended, so foreign currency postings behave unexpectedly at valuation or clearing time. This is a design decision, not a bug, but it is frequently set once and forgotten.
- Unsafe change to open item management or line item display: switching either flag on an account that already has postings does not retroactively apply to existing line items and can leave balances inconsistent between the account and its line item table. This requires a dedicated conversion step, not a direct field change in FS00, and is one of the most common self-inflicted incidents in a GL cleanup project.
- Reconciliation account misuse: an account flagged as a reconciliation account rejects direct GL postings by design; the fix is almost never to unflag it, since that breaks the vendor or customer subledger link — the real fix is usually posting to the correct subledger transaction instead.
Whose problem this is
GL account master data belongs to the FI functional consultant or GL sub-ledger owner. ABAP involvement is rare and limited to background conversion programs for open item management changes. Basis is not involved unless the issue is an authorization object blocking the transaction. A good handover includes the account number, company code, the exact error message, and whether the account has existing postings.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/fs00ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.