JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

June 27, 2026 · 15 min read

SAP PS WBS Hierarchy

The WBS Hierarchy is the structural backbone of every SAP Project System project. It captures the parent-child relationships between WBS Elements within a Project Definition, forming the hierarchical breakdown structure that drives cost aggregation, budget distribution, and status reporting up and down the project tree. This article covers the hierarchy’s conceptual role, its database representation in table PRHI, the organizational dimensions it spans, and the field-level detail that PS consultants must understand when designing and maintaining project structures in S/4HANA.

Part 1: WBS Hierarchy — Core Concepts (All Modules)#

1.1 What Is the WBS Hierarchy?#

The WBS Hierarchy is not a standalone master data record in the conventional sense. It is the set of parent-child linkages between individual WBS Elements, persisted in table PRHI, that collectively define the tree-shaped breakdown structure of a project. While WBS Elements (table PRPS) carry the cost, revenue, and status data, the WBS Hierarchy carries the structural relationships — which element is the parent of which, and at what level in the tree each element sits.

1.2 Hierarchy Levels and Structure Patterns#

The WBS Hierarchy can take any tree shape that the Project Profile allows, but real-world PS implementations converge on a small number of structural patterns. Choosing the right depth and branching strategy at blueprint time is critical — hierarchy changes after project execution begins (actual costs posted) require careful CJFN (restructure) steps and can trigger cost re-assignment workflows.

Design principle: Hierarchy depth should reflect the actual reporting and cost-collection needs — not organizational vanity. Each additional level multiplies settlement rules, budget distribution steps, and period-end processing time. Limit depth to what the controlling and finance teams can realistically maintain.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

Project Definition PROJ-2026-002
   Automotive Line Retooling
   │
   └── WBS Element PROJ-2026-002 (Level 1 — Summary)
          │
          ├── WBS Element PROJ-2026-002-DESIGN (Level 2)
          │      Design Phase
          │      │
          │      └── WBS Element PROJ-2026-002-DESIGN-BASIC (Level 3)
          │             Basic Engineering
          │
          └── WBS Element PROJ-2026-002-BUILD (Level 2)
                 Build Phase

1.4 Integration with Other Master Data Objects#

The WBS Hierarchy is structurally coupled to nearly every other PS master data object. Changes to the hierarchy ripple through cost aggregation, budget management, and settlement processing.

Part 2: PS-Specific Field Details#

2.0 Scope of PS Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Hierarchy Structure (PRHI)#

Table PRHI is the relational backbone of the WBS Hierarchy. Every parent-child relationship in the project structure is represented as exactly one PRHI record. PS consultants do not edit PRHI directly — it is maintained by CJ20N, CJ11, and CJ12 — but understanding its structure is essential for hierarchy reports and custom ABAP queries.

2.2 WBS Level and Sequence (PRPS Hierarchy Fields)#

Although the hierarchy structure is held in PRHI, several fields in the WBS Element table PRPS directly reflect and govern the hierarchy position. These fields are set automatically as the hierarchy is built in CJ20N, but PS consultants must understand them for reporting design and hierarchy restructuring.

2.3 Account Assignment Indicators#

The three account assignment indicators on each WBS Element determine its role in the project hierarchy. PS consultants must assign these deliberately at each hierarchy level — incorrect flag combinations are a leading root cause of posting errors and budget availability check failures in live projects.

Prerequisite: The Account Assignment Element flag requires that the WBS Element’s status profile (set in the Project Profile) allows account assignment. If the system status AVAI (available for account assignment) is not active, postings are blocked even when the flag is set.

2.4 Responsible Cost Center and Profit Center#

The Responsible Cost Center and Profit Center fields on each WBS Element define the organizational anchors for overhead allocation and profit center accounting. In S/4HANA these are no longer optional — the Profit Center is mandatory on every WBS Element that posts actual values, and the Responsible Cost Center is required for overhead surcharge calculation via CO costing sheets.

2.5 Project Currency and Controlling Area#

Project Currency and Controlling Area are defined at the Project Definition level and inherited by every WBS Element in the hierarchy. PS consultants must understand how these inherited values interact with the WBS Hierarchy to avoid currency and area mismatches during cost reporting and period-end processing.

Key design decision: If a project spans multiple company codes (cross-company projects), each company code must belong to the same Controlling Area. The Project Definition’s company code is the primary code — cross-company postings are settled via intercompany clearing accounts. Validate this with FI at blueprint before hierarchy design is finalized.

2.6 Settlement Rules#

Settlement rules determine where the costs and revenues collected on each WBS Element are transferred at period-end (typically via transaction CJ88 or CJB1). The WBS Hierarchy position of an element directly determines the settlement sequence — leaf elements settle first, then summary elements settle the aggregated balance. PS consultants define settlement rules in CJ20N or CJ11; CO/FI-AA review the rules for compliance with asset accounting and cost center policies.

Prerequisite: Settlement rules reference the Settlement Profile assigned in the Project Profile (OPSA). The Settlement Profile defines which receiver categories are allowed and whether manual or automatic creation is required. If the settlement receiver category is not permitted by the Settlement Profile, the rule cannot be saved.

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction