T001B table — FI Posting Period Intervals
T001B stores Financial Accounting posting-period interval control by posting-period variant, account type, account range, period, and fiscal-year boundaries. The effective posting permission is not simply 'company code open or closed': the company code points to a posting-period variant, and multiple account-type or account-range intervals can allow or block the same posting date differently.
A consultant-focused reference for T001B covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 714 words
Esta página ainda não está disponível em português.
What it stores
T001B stores open and closed FI posting-period intervals by company code, account type and account range. Each row must be interpreted using the complete technical key and the application process that writes it. A consultant should first establish whether the row represents current state, a dated master-data slice, a document item, a history event, an index entry or a compatibility representation. Organizational levels, validity dates, fiscal years, ledgers, languages, statuses and sequence numbers are part of the grain whenever those dimensions exist. The table should be read as evidence of application behavior, not as an isolated spreadsheet. Confirm the owning business object and configuration before deciding that a value is wrong.
Key fields
Posting-period controls depend on the posting-period variant, account type and relevant account interval as well as fiscal year and period boundaries. Company code alone does not identify the complete rule.
- Posting-period variant — assigned from company-code configuration.
- KOART — account type such as G/L, customer, vendor, asset, or material.
- Account from/to range — narrows the interval to specific accounts.
- Open period and fiscal-year interval(s) — define permitted posting dates.
- Company-code assignment to posting-period variant — required to know which T001B rows apply.
How it joins the data model
Relate the company code to its posting-period variant through the appropriate configuration and then inspect the account-type/interval entry in T001B. Do not claim a period is open merely because a different account type can post.
- BUKRS to T001
- account interval to the relevant G/L, customer, vendor or asset master
- period logic to the fiscal-year variant assigned to the company code
How to read it safely
For an FI posting period error, capture company code, posting date, account type and the actual account being posted. Compare those values with the applicable posting-period variant and interval; period-open settings must be changed only through authorized configuration transport/processes.
How to prove it in the data
Take one reproducible example from the relevant SAP screen, report or application log. Record its full displayed key, organizational context, key date, language and status. Locate the matching T001B row using those values, then follow the documented parent and child joins without dropping key components. Compare the result using the same key date and ledger. When values differ, test for leading-zero conversion, multiple validity slices, inactive history, parallel ledgers, fiscal-year boundaries, archived data and asynchronous replication. Save the read-only evidence before escalating. If the row is wrong, reproduce the maintenance path in a non-production system and route the fix to the application owner rather than changing the table.
ECC vs S/4HANA
T001B remains part of S/4HANA FI posting-period control. Universal Journal storage does not remove the posting-period variant and account-type interval checks. Analyze the company code's assigned posting-period variant and the matching interval before changing period configuration.
Common pitfalls
- Selecting by one convenient identifier and silently mixing organizational units, years, ledgers, languages or validity periods.
- Joining on a partial key or descriptive value and creating duplicates that appear to be legitimate business rows.
- Ignoring inactive, deletion, reversal or status indicators and reporting retained history as current state.
- Assuming this table is authoritative without checking S/4HANA simplification, Business Partner synchronization, Universal Journal, MATDOC, CDS views or an external cloud source.
- Treating a missing row as proof that an event never occurred even though logging, replication, authorization and archiving scope can differ.
- Updating table rows directly instead of correcting data through the supported transaction, app, API or migration process.
Whose problem this is
FI configuration owns posting-period authorization and business timing; treasury, procurement or SD may supply the originating document context. Basis does not independently authorize opening accounting periods.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t001bERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.