ACDOCA table — Universal Journal Entry Line Items
ACDOCA is the S/4HANA Universal Journal table holding one row per accounting line item per ledger, merging what used to be split across BSEG, the New GL totals tables, CO line items, and material ledger data. It carries FI, CO, and profit-center attributes on the same row, at the grain of ledger, company code, fiscal year, document, and document line.
This page covers what a row in ACDOCA actually represents, the fields worth querying, the joins consultants use to get from a journal line to master data and source documents, and the specific misreadings that cause wrong totals when people treat it like BSEG with extra columns. It also covers where the table sits relative to the classic FI/CO tables it absorbed.
Published 15 Sept 2026· 1,162 words
What it stores
One row in ACDOCA is a single accounting line item as posted into a specific ledger. Because S/4HANA stores FI, CO (including cost center and internal order postings), profit center accounting, and material ledger valuation in one physical table, the same underlying business transaction can produce several ACDOCA rows: one per parallel ledger it is relevant for, and additional rows created by document splitting when a document needs to be balanced by profit center or segment. A row therefore is not always the same thing as a BSEG line item; it is the ledger-specific, split-compliant representation of that line. Real-time CO postings (cost center to cost center reposting, for example) that never touch classic FI also land here as their own rows, distinguished by the reference procedure field.
Key fields
The fields consultants actually use for selection and joins:
- RCLNT - client
- RLDNR - ledger, distinguishes leading ledger from parallel ledgers, mandatory to restrict on before any aggregation
- RBUKRS - company code
- GJAHR - fiscal year
- BELNR - accounting document number
- DOCLN - universal journal line number; this is not the same numbering scheme as BSEG-BUZEI
- RACCT - G/L account number
- KOKRS - controlling area
- KOSTL - cost center
- PRCTR - profit center
- SEGMENT - segment used for segment reporting
- WERKS - plant
- KUNNR - customer number when the line is customer-related
- LIFNR - vendor number when the line is vendor-related
- MATNR - material number on material-related lines
- BUDAT - posting date
- BLDAT - document date
- DRCRK - debit/credit indicator
- HSL - amount in company code (local) currency
- KSL - amount in the currency type used for group or controlling area reporting
- TSL - amount in transaction (document) currency
- AWTYP - reference procedure that generated the line, tells whether it originated as an FI document, a CO document, or another source
- AWKEY - reference key pointing back to the originating source object
How it joins the data model
Joins consultants write day to day:
- ACDOCA-RBUKRS = BKPF-BUKRS and ACDOCA-BELNR = BKPF-BELNR and ACDOCA-GJAHR = BKPF-GJAHR, to get header data such as reversal status and user; note BKPF has no ledger dimension
- ACDOCA-RACCT = SKA1-SAKNR, restricted by the chart of accounts tied to the company code, to get the account's classification
- ACDOCA-RACCT = SKB1-SAKNR and ACDOCA-RBUKRS = SKB1-BUKRS, for company-code-specific account control such as open item management
- ACDOCA-KOSTL = CSKS-KOSTL and ACDOCA-KOKRS = CSKS-KOKRS, for cost center master data, watching the validity period on CSKS
- ACDOCA-RBUKRS = T001-BUKRS, for company code currency and chart of accounts assignment
How to read it safely
ACDOCA is client-dependent and, in a productive landscape, one of the largest tables in the system. Never select without restricting on company code and fiscal year at minimum; add ledger (RLDNR) whenever the query is meant to represent one accounting view, since the leading ledger and parallel ledgers otherwise get summed together and inflate totals silently. Posting date or fiscal period range should be added for anything beyond a single-document lookup. Reference procedure and reference key are the fastest way to jump from a business document (sales order, purchase order, asset) straight to its financial postings without going through BKPF first.
How to prove it in the data
Symptom: a cost center report shows an amount that does not match what FI shows for the same account and period. Select ACDOCA by KOKRS, KOSTL, RACCT, GJAHR, and the relevant posting period, then group by RLDNR. If the two ledgers show different totals, the discrepancy is a parallel ledger valuation difference, not a data error; if a single ledger's total differs from the FI report, check whether the FI report is filtering AWTYP to exclude CO-only postings that also carry the cost center.
ECC vs S/4HANA
ACDOCA exists only in S/4HANA; there is no ECC equivalent. In ECC, the same information was spread across BSEG, the New GL totals tables (FAGLFLEXA and FAGLFLEXT), CO line items (COEP), and material ledger tables. S/4HANA merges all of that into ACDOCA as the single source of postings, and the classic tables are kept as compatibility structures so existing reports and interfaces continue to work, but the authoritative data for financial and profitability reporting lives in ACDOCA.
Common pitfalls
The recurring wrong conclusions drawn from this table:
- Assuming ACDOCA is a one-to-one replacement for BSEG. It is not: one BSEG-equivalent business transaction can generate several ACDOCA rows through ledger multiplication and document splitting, so row counts and even line-level amounts will not match a naive BSEG comparison.
- Summing amount fields across all rows without filtering RLDNR. This double- or triple-counts the same economic event once per parallel ledger and produces balances that look wrong but are actually the sum of leading plus non-leading ledger views.
- Joining ACDOCA-DOCLN to BSEG-BUZEI expecting a one-to-one match. The two are different numbering schemes; the join returns misleading partial matches rather than an obvious error, which is worse than a hard failure.
- Reading HSL or KSL without checking what currency type each represents in the given client configuration. The mapping of currency fields to currency types is configurable and not fixed, so an amount field that means group currency in one system can be configured differently in another.
- Treating every row as an FI document line. Real-time CO-only postings (cost center reposting, internal order settlement) appear in ACDOCA with a different reference procedure and were never in classic BSEG at all; excluding or including them changes totals depending on what the reconciliation is meant to prove.
- Ignoring balance carryforward and year-end technical postings when counting transaction volume for a period, which overstates activity if those rows are not filtered out.
Whose problem this is
A mismatch between ACDOCA and a downstream report is a joint FI and CO design question, usually owned by whoever configured document splitting and the ledger setup, since most discrepancies trace back to splitting rules or which ledgers a company code is assigned to. Pure performance problems on large selections against ACDOCA belong to Basis and the HANA/DB team.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/acdocaERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.