ACDOCP table — Universal Journal Plan Line Items Table

One row in ACDOCP is a single plan line item: one combination of company code, general ledger account, planning version, fiscal year, period and the relevant controlling object (cost center, profit center, WBS element, internal order, segment) together with the planned amount in local and group currency. It has the same wide, denormalized shape as ACDOCA, the actual-data Universal Journal table, deliberately, so plan and actual figures can be compared field for field without a translation layer. There is no accounting document number on a plan line because it was never posted through FI; it was written by a planning function, a manual entry in an embedded planning app, an upload from SAP Analytics Cloud, or an allocation cycle run against a planning version. The table underpins embedded cost center planning, profit center planning and profitability planning in S/4HANA.

ACDOCP shares its dimensional fields with ACDOCA and with the classic controlling master data tables, so most joins a consultant writes here are the same joins used against actuals, just restricted by planning version instead of document number.

ACDOCP is client-dependent and can be large once several planning versions and multiple replanning cycles have run, so RCLNT is implicit but the real filters that matter are VERSION, RYEAR and RBUKRS, applied together before touching RCNTR or PRCTR. Never scan the table by account alone across all versions; a single account can carry a dozen unrelated plan scenarios in different versions and years. Selectivity improves sharply once POPER is added, because most planning apps write at period or year-bucket granularity, and pulling a single period avoids summing rows that were never meant to be added together.

Symptom: a profit center planning report shows a total that does not match what was uploaded from SAP Analytics Cloud. Select ACDOCP restricted on RBUKRS, VERSION, RYEAR, PRCTR and RACCT for the period in question, sum HSL, and compare that figure directly against the source file or the SAC story export for the same version and period. A mismatch at this level points to a version or period mapping error in the integration, not a reporting layer problem.

ACDOCP exists only in S/4HANA; there is no ECC equivalent because ECC planning ran through separate CO tables such as those behind cost center and profit center planning transactions. Migrating to S/4HANA does not automatically move historical plan data into ACDOCP; older plan versions may remain in the classic tables if the planning process for that scenario was never converted to embedded planning. Where embedded planning is active, ACDOCP is the single source for plan line items across cost center, profit center and profitability planning.

A discrepancy in ACDOCP is a controlling or planning-lead question first, since it depends on which planning function, app or SAC integration wrote the row and under which version definition. FI does not usually own version semantics. Basis or the analytics team is pulled in only if the embedded planning model itself is misconfigured, not for individual data mismatches.

ACDOCA holds the actual-data counterpart with the same dimensional shape, used for every plan-versus-actual comparison. CSKS and related cost center master tables, along with SKA1 and SKB1 for the account master, are the standard lookups for validating the objects referenced in a plan line. Data reaches ACDOCP through embedded planning Fiori apps, planning function execution, and SAP Analytics Cloud upload jobs rather than through a conventional FI posting transaction.