SAP Solution Architecture Advisory
Aerospace & Defense Practice
Aerospace & Defense Practice
A technical and strategic assessment of SAP Project Systems (PS) as the center of the integration universe for US Government Contractors and Aerospace & Defense companies. This paper covers WBS architecture, multi-hierarchy design, integration touchpoints, revenue recognition, and an evaluation of implementation challenges.
For US Government Contractors and Aerospace & Defense companies, SAP Project Systems (PS) is not simply another module. It is the center of the entire ERP landscape. Every major business process (contract management, cost accounting, procurement, production, billing, time entry, and financial reporting) either originates from, passes through, or settles back to a Project System WBS element. Getting PS right is the single most consequential design decision in an A&D SAP implementation.
In project-centric industries, the fundamental unit of work is the project, not the product. Revenue is earned by executing contracts. Costs are collected, burdened, and reported against work breakdown structures. Cash is generated through milestone deliveries or cost-reimbursable billing tied to project progress. This reality makes SAP Project Systems the natural integration hub: the module that every other module must connect to, and the one whose design most directly determines whether the SAP implementation succeeds or fails.
PS provides the WBS hierarchy that serves as the financial and logistic backbone of each project. The WBS is the account assignment object for cost collection, the demand source for procurement and production, the billing element for customer invoicing, the budget control point for funds management, and the settlement object for revenue recognition. No other SAP object carries this breadth of integration responsibility.
SD contracts and sales orders link to PS billing elements, creating the bridge between commercial terms and project execution. Contract line items (CLINs) map to WBS elements for billing and revenue tracking.
WBS elements serve as the primary cost collection object for direct costs under CAS and FAR Part 31. Costing sheets apply FPRA-negotiated burden rates in real time. Cost element detail on the WBS supports DCAA audit requirements.
Historical project data (actuals, rates, resource consumption) feeds future estimates. PS enables "similar-to" project copy functionality, allowing pricing teams to rapidly produce new estimates by leveraging prior program data as a baseline.
Purchase requisitions and purchase orders are account-assigned to WBS elements, connecting procurement spend directly to the program. Material requirements flow from project stock reservations to MRP-driven supply.
Project stock-based demand (individual customer requirements on the WBS) drives MRP planning. Plant stock supply for common materials serves project stock demand, enabling a hybrid model where shared inventory supports project-specific builds.
PS projects integrate with Portfolio & Project Management (PPM) tools for enterprise-level visibility across the project portfolio, including resource capacity, pipeline health, and strategic alignment across programs.
WBS settlement posts to profit centers, enabling contract-level and segment-level P&L reporting. Universal Journal (ACDOCA) entries carry the WBS as an account assignment, providing real-time financial visibility.
Billing events, whether milestone-based (FFP), cost-based (CPFF/T&M), or progress-based, originate from PS billing elements. Add-on solutions like Dassian and Cognitus extend native SD billing with project-driven billing based on cost results and milestone delivery.
CATS time entry charges labor hours directly to WBS elements. Labor distribution drives direct vs. indirect cost classification, supports DCAA timekeeping requirements, and feeds workforce planning for resource-loaded schedules.
Budgeting, baseline management, Estimate at Completion (EAC), Estimate to Complete (ETC), and earned value metrics are managed through PS budget profiles and the project cost forecasting framework.
The integration density around PS is what makes it both indispensable and challenging. A single WBS element simultaneously serves as the account assignment for MM procurement, HR time entry, PP production orders, SD billing, CO overhead allocation, and FI settlement. This is not a theoretical concern; it means that a configuration decision in PS ripples across every integrated module.
For A&D companies with mature unitized programs (where deliverables are discrete, serialized units such as aircraft, satellites, missiles, and engines), SAP PS's integration with Plant Maintenance / Manufacturing Operations (PMMO) provides a powerful architecture. A separate logistic project structure manages the physical units and their associated manufacturing, assembly, and test operations, while the cost WBS structure manages the financial view. The material master, plant assignment, and demand WBS relationship drives costs seamlessly to the cost-collecting WBS elements.
This dual-structure approach allows program management to track physical unit progress independently from financial cost collection, but getting the linkages right is one of the most technically demanding aspects of an A&D PS implementation. The relationship between the logistic unit structure and the financial WBS must be designed with precision to avoid either cost leakage or double-counting.
The WBS structure is the single most impactful design decision in an A&D PS implementation. It must simultaneously satisfy cost accounting requirements (CAS compliance, DCAA auditability), financial reporting needs (ASC 606 revenue recognition), billing mechanics (FFP milestones, cost-reimbursable invoicing), and budget control (AVAC, EVM baseline). No single hierarchy can perfectly serve all of these purposes, which is why understanding the Multi-Hierarchy concept (covered in Section 06) is essential.
The Network and Network Activity structure is the primary mechanism through which material component demand flows to the project. When a material component is assigned to a network activity, SAP generates either a reservation (for plant/warehouse stock) or a purchase requisition (for externally procured items), linking the material demand directly to the project WBS through the activity's account assignment. This is how PS drives MRP: the network activity creates the demand, MRP generates the supply response, and the resulting costs post to the WBS cost collector.
In the standard design, networks are assigned to the lowest-level WBS element (the cost collector). However, for companies with unitized programs or complex logistic structures, networks may be managed on a separate logistic hierarchy (e.g., a PMMO-based structure) while still settling costs to the financial WBS. This separation is discussed further in the Multi-Hierarchy section.
The inclusion of a Performance Obligation (POB) level in the WBS is driven by whether the company has ASC 606-relevant performance obligation-based accounting and revenue recognition. For companies that recognize revenue using the over-time percentage-of-completion method, this level is where Results Analysis (RA) is configured and where earned revenue is calculated. If the company does not recognize revenue on an over-time POC basis, this level may not be needed at all.
A key structural consideration: there is often a many-to-one relationship between billing elements and a single performance obligation. A contract may have multiple CLINs, funding line items, or billing arrangements that all roll up to one performance obligation for revenue recognition purposes. The WBS must reflect this. Multiple Level 3 billing elements can (and frequently do) sit beneath a single Level 2 performance obligation, allowing billing mechanics and revenue recognition to operate independently at the correct level of the hierarchy.
Including the POB level also enables a Performance Obligation ID to be carried as an attribute of the WBS element. This POB ID allows grouping of performance obligations across projects or across company codes into a single Estimate at Completion (EAC), which is particularly relevant for companies that need cross-company performance obligation reporting or that have performance obligations spanning multiple legal entities within a corporate structure.
The inclusion of a control account level in the WBS is optional but strategically significant. Here are the trade-offs:
One of PS's greatest strengths is its flexibility to manage very different project types within a single module. A&D companies require WBS structures for both direct (customer-facing, revenue-generating) and indirect (internal, overhead-supporting) projects. PS accommodates both through project profile configuration, account assignment categories, and settlement rules.
Milestone-based billing, full cost risk on contractor. WBS billing elements link to SD milestone billing plan. Revenue recognized via Results Analysis (RA) at the performance obligation level using POC method.
Cost-reimbursable billing with fixed fee component. Provisional billing rates applied via costing sheets. WBS billing elements drive periodic cost-based invoicing. Fee recognized proportionally to cost incurred.
Billing based on actual hours and material costs plus markup. CATS time entry feeds billing rates. Material costs from MM post to WBS and flow through to invoicing at agreed rates.
Common in government contracting where funding is incremental. PS budget management tracks authorized funding vs. total contract value. AVAC controls prevent spending beyond funded ceiling.
Internal R&D projects tracked as indirect cost, allocated through G&A or dedicated IR&D pool. WBS structure enables project-level cost tracking while costs flow to the appropriate indirect rate pool.
Pre-award proposal effort captured on dedicated WBS structures. Costs accumulate during pursuit phase and are allocated through the B&P cost pool. Supports FAR 31.205-18 cost allowability requirements.
Capital improvement, facilities maintenance, and IT infrastructure projects managed through PS. Settlement to assets (for capex) or to overhead cost centers (for period expense).
Projects focused on the buildout of a fixed asset, where costs are captured in Capital in Process (CIP) or Asset under Construction (AuC) accounts until the asset is placed into service. PS settlement rules direct capitalizable costs to the AuC asset and expense portions to period cost centers. This structure allows both the capitalized cost and the related expense to be managed on the same WBS hierarchy, giving project managers a single view of total project spend while maintaining the accounting separation required for fixed asset capitalization. Upon go-live of the asset, the AuC is settled to the final asset master record.
Shared service delivery, internal training, process improvement initiatives. Cost collection on WBS with settlement to consuming organizations via CO assessment or activity allocation.
For project-centric A&D and GovCon companies, revenue recognition is handled through SAP Project Systems' Results Analysis (RA), not through SAP's RAR (Revenue Accounting & Reporting). RAR is designed for subscription-based, consumption-based, or multi-element arrangement revenue models typical of SaaS, telecom, or media industries. RA is the purpose-built mechanism for project-based, over-time POC revenue recognition that A&D companies require under ASC 606.
Results Analysis is a period-end process within SAP Project Systems that calculates work in process (WIP), reserves for unrealized costs, accrued revenue, and cost of sales based on the relationship between actual costs incurred, planned costs, and contract revenue. For government contractors operating under ASC 606 with over-time revenue recognition, RA is the standard mechanism.
| Dimension | Results Analysis (RA) | RAR (Revenue Accounting & Reporting) |
|---|---|---|
| Revenue Model | Project-based, over-time POC, long-term contracts | Subscription, consumption, license, multi-element arrangements |
| Industry Fit | A&D, GovCon, Construction, Engineering, Professional Services | SaaS, Telecom, Media, High-Tech (product + service bundles) |
| Cost Object | WBS elements within SAP Project System | Performance obligations defined in RAR contract model |
| ASC 606 Method | Over-time recognition (input or output method) | Point-in-time or over-time (typically allocation-based) |
| Integration | Native to PS, tightly coupled with project cost data, EAC, billing plans | Separate module; consumes SD billing documents, applies standalone allocation rules |
| Typical A&D Use | Primary mechanism for project RevRec | Only if the company also has subscription or consumption-based revenue streams alongside project revenue |
For the vast majority of A&D and GovCon companies, Results Analysis is the correct and sufficient tool for revenue recognition. RAR should only be considered if the company has a material revenue stream that is subscription-based, consumption-based, or involves complex multi-element arrangements where standalone selling prices must be allocated across bundled deliverables. Deploying RAR for standard project-based revenue adds unnecessary complexity, licensing cost, and implementation risk with no incremental benefit over RA.
One of the most common and consequential mistakes in A&D SAP implementations is attempting to make the SAP PS WBS hierarchy serve every purpose: cost collection, scheduling, earned value management, customer reporting, and organizational accountability, all in a single structure. It cannot. Understanding what the WBS should be and what it should not be is foundational to a successful PS design, and this understanding leads directly to the Multi-Hierarchy concept that is unique to project-centric industries.
The SAP PS WBS hierarchy is, first and foremost, the financial and logistic backbone of the project within the ERP system. It serves three non-negotiable roles:
The WBS is the primary cost collection and cost control structure. All direct costs (labor, material, subcontract, ODC) post to WBS elements. Overhead burden is applied via costing sheets. Budget control (AVAC) is enforced at WBS levels. Revenue recognition via Results Analysis operates against the WBS. Settlement to FI/profit centers flows from the WBS. This is the core purpose of the WBS.
The WBS is the demand source for procurement (purchase requisitions account-assigned to WBS), production (manufacturing orders account-assigned to WBS), and inventory management (project stock segregation by WBS). MRP planning runs against project stock requirements generated by the WBS hierarchy. This logistic integration is what makes PS the "center of the universe."
The WBS defines what the project needs (labor hours, purchased materials, manufactured assemblies, subcontracted services) and when it needs them. This demand drives the entire supply chain response within SAP: MRP, capacity planning, procurement cycles, and production scheduling all originate from WBS-level requirements.
This is where A&D implementations frequently go wrong. The WBS hierarchy in SAP PS should not necessarily be the structure that drives all project management disciplines. Specifically:
This distinction leads to a concept that is unique to project-centric industries and frequently misunderstood by SAP practitioners who come from non-project environments: the requirement for multiple, co-existing project hierarchies that serve different purposes and different audiences.
In project-centric A&D and GovCon companies, a single project typically requires several hierarchical views:
Lives in SAP Project Systems. Cost collection, demand sourcing, billing, budget control, revenue recognition. The ERP backbone.
Lives in scheduling tools (Primavera P6, MS Project, Deltek Open Plan). Activity-level scheduling, critical path, resource loading, milestone tracking. Integrated with SAP but not resident in PS.
Lives in EVMS tools (Deltek Cobra, MPM, Empower) or custom EVM solutions. Control accounts, work packages, earned value calculations, IPMR/CPR reporting. May map to SAP WBS but is not structurally identical.
The structure in which the customer receives their Contract Data Requirements List (CDRL) deliverables, progress reports, and status information. Often organized by contract CLIN, Statement of Work (SOW) paragraph, or deliverable rather than by the internal WBS structure. Typically managed in external project hierarchy management tools, EVM tools (which often maintain their own customer-facing reporting structures), BI/analytics platforms, or document management systems outside SAP PS.
The structure that defines who is accountable for what: Integrated Product Teams (IPTs), Control Account Managers (CAMs), functional leads. May overlap with the WBS but is often a distinct organizational view managed in workforce planning or EVMS tools.
A critical point for SAP solution architects: these alternative hierarchies typically live outside of SAP Project Systems. They are resident in integrated tools, some within the broader SAP ecosystem and others in best-of-breed third-party solutions:
| Hierarchy | Primary Tooling | Integration with SAP PS |
|---|---|---|
| Financial / Logistic WBS | SAP Project Systems (native) | This is the SAP PS structure |
| Integrated Master Schedule | Primavera P6, MS Project, Deltek Open Plan, and other integrated master scheduling tools | Bi-directional integration via middleware (cProjects, Open PS, or third-party connectors). Schedule dates and milestones map to PS network activities or WBS dates. |
| EVM / Cost Management | Deltek Cobra, MPM, Empower, Forproject, PPM | Actuals pulled from SAP PS/CO. Budgets and EACs may flow bi-directionally. Control account mapping to WBS elements. |
| Customer Reporting | External project hierarchy management tools, EVM tools (which often maintain customer-facing report structures), BI/Analytics (SAC, Tableau, Power BI), document management | Consumes SAP data but presents it in a customer-aligned hierarchy that differs from the internal WBS. The reporting structure is typically maintained in the external tool and mapped back to SAP WBS elements for data extraction. |
| Organizational Accountability | PPM tools, EVMS tools, workforce planning tools | CAM assignments may map to WBS elements but organizational hierarchy is managed externally. |
Many times, multiple hierarchies are needed to successfully execute a project. This is not a deficiency in SAP PS; it is a reality of project-centric industries. The SAP PS WBS should be designed to serve its core role well (financial/logistic backbone and demand source) and should be designed with clean integration points to the other hierarchies that serve scheduling, earned value, customer reporting, and organizational accountability. Attempting to force all of these views into a single SAP PS WBS hierarchy results in a structure that is too deep, too complex, too rigid, and ultimately fails to serve any of its purposes well.
The organizations that get this right design the SAP PS WBS for its financial and logistic purpose first, then establish clear mapping and integration patterns to the external hierarchies. The organizations that get it wrong try to replicate the schedule or the customer reporting structure inside PS and end up with a WBS that is both unmanageable in SAP and inadequate for the external tools.
SAP Project Systems is among the most complex and mature modules in the SAP ecosystem. For production and manufacturing A&D companies in particular, PS implementation carries risks and challenges that are routinely underestimated. These are not reasons to avoid PS; they are reasons to invest in proper design, testing, and change management.
PS has been in the SAP portfolio since R/3. Its configuration surface area is enormous: project profiles, WBS element profiles, network types, activity types, milestone profiles, budget profiles, settlement rules, Results Analysis keys, billing plan types, and dozens of intersecting configuration objects. The permutations create a configuration matrix that takes experienced consultants months to navigate correctly. For A&D companies with both manufacturing and service delivery, the PS/PP/CO intersection is particularly dense.
Companies that build physical products (aircraft, satellites, missile systems) face a materially different PS design challenge than pure services companies. The WBS must accommodate both cost management (financial view) and logistics (demand/supply for production). The interaction between project stock, plant stock, MRP, and production orders creates dependencies that, if misconfigured, result in either unplanned procurement, production shortages, or cost postings to the wrong WBS elements. The PMMO integration for unitized programs adds another layer of complexity.
PS period-end is unforgiving. The sequence (overhead calculation, Results Analysis, settlement) must execute in the correct order with the correct scope. A single missed step or incorrect scope selection can cascade errors through WIP, revenue recognition, and P&L postings. In S/4HANA, the period-end close is tighter and more automated, but the consequences of misconfiguration are equally severe.
Availability Control (AVAC) is PS's mechanism for preventing spending beyond authorized budgets, a critical requirement for partially funded government contracts. However, AVAC is notoriously difficult to configure correctly. Tolerance keys, budget profiles, and the interaction between overall, annual, and distributed budgets create a configuration matrix that frequently results in either over-controlling (blocking legitimate transactions) or under-controlling (failing to prevent overruns). Most organizations require multiple post-go-live iterations to achieve a functioning AVAC configuration.
Because PS sits at the center of the integration landscape, testing is more complex than any other module combination. A single WBS element must be tested as the account assignment object for MM procurement, HR time entry, PP production orders, SD billing, CO overhead allocation, and FI settlement, simultaneously, in sequence, with correct master data. End-to-end scenario testing from contract award through final billing is essential and requires significantly more time than most implementation schedules allow.
PS implementations change how program managers, CAMs, contracts administrators, and cost accountants interact with their work. The transition from spreadsheet-based cost tracking, desktop EVM tools, and manual billing processes to a fully integrated PS-driven model is a significant behavioral change, one routinely underestimated in OCM planning. Adoption failure is more common than technology failure in PS implementations.
None of these challenges are insurmountable. RevTech has designed and implemented PS architectures for some of the most complex GovCon and A&D programs in the country. But enter with clear eyes. Plan for more design time, more integration testing, and more change management than your initial estimate suggests. The cost of getting PS right upfront is a fraction of the cost of fixing a poorly designed implementation on live contracts.
After articulating the complexity and the risks, the question is fair: is SAP Project Systems worth it? For US Government Contractors and Aerospace & Defense companies operating in a CAS/FAR-regulated, EVMS-required, multi-contract environment, the answer is yes.
No other ERP module provides the integrated financial and logistic backbone that PS delivers. The ability to collect costs, control budgets, drive procurement and production demand, recognize revenue, and generate customer billing from a single, auditable WBS hierarchy is a capability that cannot be replicated by any combination of spreadsheets, standalone tools, or alternative ERP modules.
We've seen PS implementations fail, and we've seen them transform how companies manage their programs. The difference is almost never the technology. It's the quality of the design, the depth of the integration testing, the rigor of the change management, and the willingness to invest in getting the WBS architecture right before going live. If you're going to do it, do it right. The ROI is real, but only if the foundation is sound.
Revelation Technologies (RevTech) offers specialized SAP consulting and solution architecture services to Aerospace & Defense and US Government Contractors. Our team of US citizens specializes in complex SAP S/4HANA implementations and business transformations for government contractors operating under CAS, FAR, and DFARS compliance requirements.
Our Aerospace & Defense practice brings deep expertise in SAP Project Systems, Controlling, Production Planning, and the integrated GovCon solution landscape, including Dassian, Cognitus, and the broader ecosystem of SAP-native tools that serve the A&D industry.
For more information, visit revtech.consulting.