GLT0 table — Classic G/L Transaction Figures (Legacy)
GLT0 stores classic General Ledger transaction figures and period balances by ledger or record type, company code, account, fiscal year, business-area or related dimensions, and debit/credit context. It is a totals table from the classic FI data model, not a line-item source. In S/4HANA it is not the strategic source for current General Ledger reporting.
A consultant-focused reference for GLT0 covering its purpose, key fields, joins, safe query restrictions, proof steps, release context, ownership and recurring interpretation traps.
Published 20 Sept 2026· 733 words
What it stores
GLT0 stores classic General Ledger balance and period totals by ledger, company code, fiscal year, account and debit or credit dimension. 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
GLT0 represents classic G/L account totals from legacy accounting models. Its fiscal-year, ledger/account and period fields must be interpreted for the target ECC release before being used in reconciliation.
- Company code and G/L account — core accounting dimensions.
- Fiscal year and ledger or record type — define the totals slice.
- Business area and debit/credit context — relevant in the classic model.
- Period amount fields — hold aggregated balances, not source documents.
- S/4HANA — use ACDOCA and released G/L analytical views for new reporting.
How it joins the data model
Correlate totals with the correct company-code and account master dimensions and a consistent fiscal-year/currency context. In S/4HANA, evaluate Universal Journal and supported CDS reporting rather than assuming GLT0 remains the authoritative posting store.
- BUKRS to T001
- RACCT to SKA1 and SKB1
- ledger and fiscal-year totals to classic FI line items for reconciliation
How to read it safely
If a custom account balance disagrees with the standard financial statement, first verify ledger, fiscal year, currency and carryforward handling. Trace postings from accounting documents and use the appropriate S/4HANA reporting source where the classic totals table has compatibility behavior.
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 GLT0 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
S/4HANA uses the Universal Journal ACDOCA as the strategic actual line-item source and derives reporting balances from the new model. GLT0 belongs to the classic totals-table architecture and should be treated as legacy or compatibility-oriented in converted systems rather than used for new reporting design.
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 General Ledger owns balance semantics and ledger setup. ABAP and the conversion team own migration of custom reports that continue to depend on obsolete ECC totals structures.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Learn this properly
Lessons and topics
Source: ERPClimb — https://erpclimb.com/sap-tables/glt0ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.