Analytics Catalog/SAP S/4HANA/General Ledger/G/L Account Line Items
Explore the catalogReportsModulesEnterprise modelCDS viewsExtraction
SAP S/4HANA · General Ledger (FI-GL)

G/L Account Line Items

Every posting to a G/L account for a period — document, date, amount, and account assignment — straight from ACDOCA, reconciled and traceable to the source journal entry.

Sample build of the G/L Account Line Items report — reconciled to the trial-balance control total, and rendered tool-neutral so it runs in Power BI, SAC, or Tableau.

G/L Account Line Items sample
reconciled · period 04 / 2026
Filters
Ledger
0L · Leading
Company code
1010
Period
04 · 2026
Currency
USD
48.20M
Total debits
48.20M
Total credits
0
Net · balanced
12,480
Documents
AccountDebitsCreditsNetManual %
400000 · Revenue31,001,500(31,001,500)4%
500000 · COGS18,400,00018,400,0006%
113100 · Bank415,020,800414,961,52059,2801%
160000 · Accruals2,813,4002,813,40062%
AI Analyst · active
reading

The report sums every ACDOCA line for the period by account and ledger, splits debits and credits, and ties each line to its BKPF document header.

flag

Account 160000 (Accruals) is 62% manual postings — far above the 3.1% book average. Manual concentration on accruals at close is the classic restatement risk.

root cause & next step

Route the manual accrual postings to a controller before period lock; a single reversing-entry error here flows straight into the financial statements.

Illustrative data · reconciled to the trial-balance control total · runs on your warehouse. See it live →
ACDOCA+BKPF+SKAT────▶G/L Account Line Items

The report's query logic — generic SQL on ACDOCA, the Universal Journal. The same SQL becomes a dbt model in your warehouse, so one definition drives both the report and the analytics layer.

How it interconnects: this reads ACDOCA directly, never the legacy BSIS / BSAS compatibility views. The same data is exposed through the released CDS view I_GLAccountLineItem, and for replication through its extraction-enabled raw view — three lenses on one source.
SQL data set · genericized · parameterized · reads ACDOCA, never compat views
Show / hide SQL
WITH gl_lines AS (
  SELECT a.rldnr, a.rbukrs, a.gjahr, a.belnr, a.docln,
         a.racct, a.rcntr, a.prctr, a.budat, a.drcrk, a.hsl
  FROM   acdoca a
  WHERE  a.rldnr  = :P_LEDGER          -- 0L leading / local / IFRS
    AND  a.rbukrs = :P_COMPANY_CODE
    AND  a.gjahr  = :P_FISCAL_YEAR
    AND  a.budat BETWEEN :P_FROM_DATE AND :P_TO_DATE
)
SELECT l.rbukrs                                          AS company_code,
       l.racct                                           AS gl_account,
       t.txt50                                           AS account_name,
       l.belnr                                           AS document_no,
       l.budat                                           AS posting_date,
       h.blart                                           AS document_type,
       l.rcntr                                           AS cost_center,
       l.prctr                                           AS profit_center,
       SUM(CASE WHEN l.drcrk = 'S' THEN l.hsl ELSE 0 END) AS debit_lc,
       SUM(CASE WHEN l.drcrk = 'H' THEN l.hsl ELSE 0 END) AS credit_lc,
       SUM(l.hsl)                                        AS net_lc
FROM   gl_lines l
JOIN   bkpf  h ON h.rbukrs = l.rbukrs AND h.belnr = l.belnr AND h.gjahr = l.gjahr
LEFT JOIN skat t ON t.ktopl = :P_CHART_OF_ACCOUNTS AND t.saknr = l.racct AND t.spras = 'E'
GROUP BY l.rbukrs, l.racct, t.txt50, l.belnr, l.budat, h.blart, l.rcntr, l.prctr
ORDER BY l.racct, l.budat;
:P_LEDGER :P_COMPANY_CODE :P_FISCAL_YEAR :P_FROM_DATE :P_TO_DATE :P_CHART_OF_ACCOUNTS
Never any customer schema. Ledger and dates are runtime parameters in production. Debit/credit split derives from DRCRK; the document always balances by ledger.

The data-warehouse model — one fact surrounded by conformed dimensions (what you slice by) and measures (what you aggregate), expressed as dbt so it migrates with you. Grain: one row per G/L line item (ledger · document · line).

dim_gl_accountaccount · FS hierarchy dim_cost_centerCO · profit center dim_company_codeledger · segment dim_dateposting · document fct_gl_line_itemsfact · one row per G/L lineamount_lc · amount_gc · dr/cr
●— fact → dimension join
ElementTypeDefinition
dim_gl_accountdimensionAccount & financial-statement hierarchy (SKA1 / SKAT)
dim_cost_centerdimensionCO assignment — cost center / profit center / segment
dim_company_codedimensionCompany code & ledger context (RLDNR)
dim_datedimensionConformed calendar (posting & document date)
amount_localmeasureHSL — company-code (local) currency
amount_groupmeasureKSL — group currency, for consolidation
drcrmeasureDebit / credit signed amount (from DRCRK)
Runs on your cloud warehouse — Snowflake, BigQuery, Redshift, or Synapse on AWS, Google Cloud, or Azure. Reconciled to the trial-balance control total — 0% variance by design. You own the code, the model, and the data.
How the data gets here: a SAP-compliant extract of ACDOCA — released CDS view via SLT, or Table/Table-CDC — never ODP-RFC (prohibited under SAP Note 3255746, blocked June 2026). See the extraction pattern & data flow →
See the complete model
How this report's fact and dimensions fit the full ACDOCA-centered picture, via conformed keys.
General Ledger data model → Enterprise model →

Every source object behind this report. Each linked object has its own page — with its fields and its real S/4HANA status, so you build on the right thing.

ObjectRoleKey fieldsS/4HANA status
ACDOCAUniversal Journal line items — the source of truth6 PK · 360+Transparent table
BKPFAccounting document header — type, dates, posting user4 PKTransparent table
SKA1 / SKATG/L account master & description textSAKNRTransparent table
I_GLAccountLineItemReleased basic CDS view over ACDOCA; extract via its raw-data viewreleasedReleased CDS view
BSIS / BSASLegacy G/L open/cleared index — joined for reference, do not extractCompat view → ACDOCA
Key fields = the primary key plus the columns this report selects; S/4HANA status = whether the object is a live transparent table, a released CDS view, or a compatibility view over ACDOCA. The compat views are referenced by legacy joins but are never the extraction source — that's the point, not a gap.
Want this built & owned?
A reconciled, customer-owned G/L layer on ACDOCA, on your cloud — your team owns the code. Ten-day proof of concept.
Download the GL pack → Talk to us →