Project Procurement, Execution, Billing and Settlement
Project Systemsarchitect

Project System Architecture and Cross-Module Integration

Key takeaway

Design SAP Project System as the project-control backbone integrated with MM, SD, CO, Asset Accounting, capacity and analytics rather than as an isolated scheduling tool.

Explanation

PS architecture should define which project object owns cost, schedule, procurement, billing and settlement. WBS elements are control objects; networks execute detailed work; MM supplies materials/services; SD handles customer commercial documents; CO/FI record cost/revenue; Asset Accounting receives capitalized investment.

Avoid duplicate project structures in each module. The same project identifiers and milestones should connect commercial and operational flows wherever practical.

For large engineering programs, external project-scheduling tools may remain necessary, but integration must define which system owns baseline dates, resource schedule and progress. Bidirectional synchronization without ownership rules creates conflicting schedules.

Use released integration and analytics APIs where available. Clean-core design should avoid custom direct-table replication just to build project dashboards.

Architecture also includes period-end sequencing: results analysis, settlement, billing and financial close need coordinated calendars and error ownership.

Real project scenario

A company maintained one WBS in SAP and a different project hierarchy in a scheduling tool, with no mapping governance. Cost and schedule reports could not reconcile. Defining a controlled mapping and one owner for each level restored consistency.

Common mistakes

  • Duplicating project structures across systems.
  • No owner for schedule baseline.
  • Treating PS as only cost collection.
  • Direct-table integrations for analytics.
  • Ignoring period-end dependencies.

Best practices

  • Assign ownership per project artifact.
  • Reuse stable project identifiers.
  • Integrate commercial and execution milestones.
  • Use released APIs.
  • Govern period-end sequencing.

Interview angle

Design a cross-module PS architecture and explain where WBS, network, MM, SD, CO/FI and external scheduling each fit.

Practice this lesson

Quick check

1. In the lesson "Project System Architecture and Cross-Module Integration", consider this project situation: A company maintained one WBS in SAP and a different project hierarchy in a scheduling tool, with no mapping governance. Which statement is correct?

2. During a multi-country rollout, milestones created on WBS elements are not triggering their assigned billing plan dates in SD, even though the milestone dates are maintained and the milestone usage indicator is set for billing. As the architect, how would you systematically investigate this cross-module failure? Choose the response that best aligns with the expected SAP approach.

3. During period-end, RA results are calculated correctly but the settlement run fails to post WIP to the correct balance sheet account, and asset settlement of AuC-related capitalized costs is also affected. How would you diagnose this cross-area issue? Choose the response that best aligns with the expected SAP approach.

Interview questions

1. Using this SAP project situation — A company maintained one WBS in SAP and a different project hierarchy in a scheduling tool, with no mapping governance — explain Project System Architecture and Cross-Module Integration. What should happen, which concepts or process steps matter, and what common mistake would you avoid?

Answer it in your own words first, then compare.

2. A manufacturing-integrated project uses PP orders linked to WBS elements for capacity-intensive production activities feeding revenue milestones. How does capacity planning integration between PS and PP affect revenue recognition scheduling?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics