A technical and strategic guide to SAP Project Manufacturing Management & Optimization (PMMO): the S/4HANA-native successor to GPD. Covers Grouping, Pegging, and Distribution architecture; grouping strategy design; finance and costing integration; exception handling; known limitations; and practical guidance for discrete manufacturers in defense and commercial environments.
SAP Project Manufacturing Management & Optimization (PMMO) is the S/4HANA-native successor to the legacy GPD (Grouping, Pegging, Distribution) component originally developed within SAP's IS-Aerospace & Defense industry solution. PMMO enables organizations to consolidate material requirements from multiple projects into shared procurement and production pools while maintaining precise, traceable, actual-cost assignment to every individual demand source throughout the full BOM lifecycle.
At its core, PMMO solves a fundamental tension in project-based manufacturing: the need to buy and build efficiently in volume while still tracking exactly which costs belong to which contract, unit, or customer. Without a structured approach, manufacturers are forced to choose between operational efficiency (pool procurement, consolidated production runs) and financial traceability (discrete cost assignment per project). PMMO eliminates that tradeoff.
Combines material requirements from multiple WBS elements (across the same or different projects) into one or more grouping WBS elements. A grouping WBS element is a specially flagged WBS that owns the consolidated inventory and drives MRP planning. The result: fewer purchase orders, fewer production orders, and larger economic order quantities without sacrificing cost traceability.
Establishes a quantity-based assignment between grouped replenishment objects (purchase orders, production orders) and the individual operative WBS elements that generated the demand. Pegging creates the traceable chain from supply to demand and determines what share of each replenishment belongs to each project or contract. This is the engine that makes collective procurement financially defensible.
Uses pegging assignments to move actual costs from grouping WBS elements to individual operative WBS elements in proportion to their pegged quantities. Distribution reads actual cost postings on the account-assigned WBS in the order hierarchy and allocates them accordingly. It runs as a batch process (transaction PMMO_DISTRIBUTION) and is the mechanism by which actuals find their correct cost destination.
GPD (Grouping, Pegging, Distribution) was delivered as part of SAP's IS-A&D industry add-on and ran on top of ECC. PMMO is its S/4HANA-native replacement, rebuilt from the ground up with Fiori-based reporting, expanded industry applicability, and a standard migration path (transaction PMMO_MIGRATION). GPD is deprecated and will not be supported on S/4HANA. Organizations running GPD on ECC face a design decision point: migrate PMMO as-is, redesign grouping strategy, or delay and accept accumulated technical debt.
PMMO with non-valuated project stock means material is managed on a quantity basis only at the inventory level. Costs are not posted to inventory accounts at Goods Receipt. Instead, external procurement costs are posted directly to the Group WBS at receipt and production costs post directly to production orders. Distribution then moves those costs to the operative project WBS elements as either direct material or labor expense. Understanding this cost flow is critical before designing any PMMO implementation.
PMMO does not stand alone. Its entire operating model is built on top of SAP Project Systems (PS) and the standard MM plant/organizational structure. Getting this foundation right is a prerequisite for a successful PMMO implementation. Gaps in PS design or organizational structure will surface as cost routing failures, pegging errors, and exception balances in PMMO.
The grouping WBS element is the central structural object in PMMO. It is a WBS element with a specific characteristic value that marks it as the account assignment target for grouped procurement and production. There are two configuration modes:
All material components assigned to the operative WBS elements beneath this group are consolidated at this single grouping WBS element, regardless of plant or MRP group. This is the simplest configuration and is appropriate when all materials in a project follow the same grouping strategy.
Allows different materials within the same operative WBS elements to be routed to different grouping WBS elements based on plant/MRP group combinations. This enables a mixed strategy where some material types (e.g., customer-furnished material) group differently than standard production parts within the same project.
Exception WBS elements serve as the designated cost collectors for costs that cannot be resolved through normal pegging and distribution. They are maintained in transaction PMMO_PEGEXC and are required for four exception categories: Excess, Scrap, Loss, and Underpeg. Exception WBS elements are not automatically created by the system; they must be explicitly designed and maintained as part of the PMMO configuration. Period-end close processes should include a review of balances on exception WBS elements before proceeding with settlement runs.
In PMMO, each grouping WBS element manages its own stock segment using SAP's special stock indicator Q (project stock). This creates a physically and financially distinct inventory pool separate from unrestricted plant stock and from other project stock segments. The implications are significant:
PMMO operates within a single company code. Cross-company-code grouping is not supported. Plant structure decisions (which plants participate in which groups, how MRP areas are defined, whether separate plants are needed for customer-specific inventory segregation) must be made explicitly during design. The assignment of WBS elements to grouping WBS elements is maintained at the plant/MRP group level when using Type 2 grouping, meaning that MRP group configuration in the material master directly influences how materials flow through the PMMO grouping hierarchy.
PMMO is not an isolated module. Its value compounds as it touches more workstreams. An organization that uses PMMO only for procurement consolidation captures perhaps 30% of the available value. Full integration across supply chain, production planning, finance, inventory management, and program management unlocks the complete picture: actual costs tied to demand sources at every point in the BOM's lifecycle.
MRP aggregates requirements from all assigned operative WBS elements at the grouping WBS element level. The result is fewer, larger purchase requisitions and orders. Planners work against a single demand signal per group rather than individual project demands. Make-to-Project (MTP) and Engineer-to-Order (ETO) scenarios are natively supported.
Production orders are account-assigned to grouping WBS elements. Multi-level BOM structures are fully supported, with each sub-assembly level tracked in PMMO_CONSUMPTION. Subcontracting (components sent to external vendors for rework, assembly, or refurbishment) is supported, with components tracked through vendor-held project stock.
PMMO Distribution (PMMO_DISTRIBUTION) moves actual costs from grouping WBS elements to operative WBS elements using business transaction RKL. Production orders on grouping WBS elements must NOT be settled via standard CO88/KO88 settlement, as this causes double-posting. PMMO replaces the standard settlement mechanism for these objects.
Costs roll up through the WBS hierarchy to support Earned Value Management (EVM) and program-level financial reporting. Breakpoints redirect distributed costs to financial performance obligation WBS elements, enabling proper revenue recognition alignment with program milestones and contract billing events.
PMMO_STOCK tracks current inventory positions per grouping WBS element. PMMO_STOCK_CHECK validates that PMMO stock records are in sync with core Inventory Management. Physical inventory adjustments, transfer postings, and scrap movements all feed back into PMMO's cost tracking through defined movement type mappings.
Pegging relationships create a continuous chain of traceability from initial procurement through production and final delivery. The Order Cost Rollup Fiori report (App F6378, transaction PMMO_COSTROLLUP) provides real-time visibility into costs and quantities at every BOM level, enabling schedule performance analysis against contract delivery commitments.
The grouping strategy is the single most consequential design decision in a PMMO implementation. Get it right, and PMMO becomes a force multiplier for both operational efficiency and financial transparency. Get it wrong, and teams spend the life of the program resolving pegging exceptions, explaining cost anomalies, and managing manual corrections at month-end.
A grouping strategy is not just a technical configuration. It is a statement of how your organization wants to see costs, how your supply chain wants to procure, and how your finance organization wants to report. These three perspectives must be aligned before finalizing the design. Misalignment surfaces as exception balances, underpeg conditions, and audit findings.
The grouping strategy must reflect the material management strategy. Materials planned as Make-to-Stock should not be pulled into PMMO grouping unless there is a specific contractual or financial reason. The decision about which materials belong to plant stock versus which should be group-managed is a fundamental design choice that affects MRP behavior, procurement execution, and cost visibility.
Each grouping WBS element is a distinct stock segment. If there is a regulatory, contractual, or operational requirement to physically or financially segregate inventory (e.g., government-furnished material, customer-owned tooling, export-controlled items), the grouping structure must reflect that requirement. Trying to retrofit segregation after go-live is extremely disruptive.
Not all material types are equal in PMMO. Trading goods, raw materials, semi-finished, and finished goods behave differently across movement types and cost postings. The grouping strategy should explicitly define which material types are assigned to which grouping levels, and those assignments should be enforced through MRP group configuration and MM master data governance.
More granular grouping provides better cost traceability but reduces the procurement and production consolidation benefit. Coarser grouping maximizes efficiency but sacrifices direct cost attribution. The right balance depends on contract type, billing basis, customer reporting requirements, and the organization's cost accounting maturity. There is no universally correct answer.
The most effective grouping strategies follow a pyramid model, where the base represents the broadest, most commoditized inventory and each tier up the pyramid narrows to more specific, contractually or technically distinct material pools. The right pyramid design depends heavily on production type, contract structure, and customer requirements. The example below illustrates a mature discrete manufacturing program in low-rate or production-phase.
The full five-tier pyramid is typically appropriate for discrete manufacturers in a low-rate production phase (e.g., defense platforms, aerospace systems). High unit value and strong contract attribution requirements justify the additional complexity at the upper tiers.
Early-stage or development programs often benefit from a simpler, two-to-three tier structure. BOM stability is low, design change frequency is high, and the overhead of managing unit-effective groups often exceeds the benefit until the design matures. Migrate to a fuller pyramid at the production phase gate.
High-volume commercial environments typically use a much simpler grouping model, often collapsing to one or two tiers. The emphasis shifts from discrete cost traceability to throughput efficiency, and standard costing may adequately meet reporting needs without the full PMMO apparatus.
Define the pyramid design before any WBS structure is built in the system. The grouping hierarchy must be aligned with the project hierarchy, the material master MRP group assignments, and the costing structure from day one. Retrofitting a grouping strategy onto an existing WBS structure is technically possible but operationally disruptive and carries significant risk of cost misallocation during the transition period.
PMMO Breakpoints are one of the most powerful and least understood features in the solution. They allow costs that would normally distribute to an operative WBS element to be redirected to an alternative cost object: a different WBS element, a network activity, or a cost center. This capability is what makes PMMO practical in complex program environments where logistics and finance use different structures to represent the same work.
Consider two defense contracts: Project Alpha (Unit 001-005) and Project Bravo (Unit 006-010), both requiring the same avionics line-replaceable unit (LRU). The LRU is produced in a single production run of 10 units to achieve favorable learning curve and subcontractor pricing.
Under PMMO: Both projects' requirements for the LRU group under a single Common LRU Grouping WBS. MRP generates one production order for 10 units account-assigned to the grouping WBS. Production costs (labor, components, overhead) accumulate on the grouping WBS element throughout the build cycle.
When the build completes, PMMO Pegging assigns 5 units to Project Alpha and 5 units to Project Bravo based on their relative demand. PMMO Distribution moves 50% of actual production costs to each project's operative WBS elements.
Breakpoints then take over: Rather than posting costs to the individual unit delivery WBS elements (which represent logistics milestones), breakpoints redirect the distributed costs to a Financial Performance Obligation WBS for each project. This financial WBS rolls up to the billing element and program-level cost collector, enabling:
(1) Revenue recognition tied directly to the performance obligation, not the logistics event.
(2) EVM reporting against the financial WBS hierarchy without disrupting logistics execution.
(3) Clean separation between how operations tracks delivery (unit-level WBS) and how finance reports margin (performance obligation WBS).
Breakpoint targets should map to the WBS elements that finance uses for cost reporting, revenue recognition, and EVM. These are typically a separate "financial project" structure maintained in parallel to the logistics project structure. The financial structure should be designed before breakpoints are configured.
In programs with many units and projects, manual breakpoint maintenance is impractical. Organizations should plan for a custom automation that generates breakpoint master data when new units or projects are added to the system. The hierarchy flag provides partial relief for stable hierarchies, but dynamic programs require a more systematic approach.
Traditional project manufacturing approaches force a choice between logistical efficiency and financial precision. PMMO collapses that tradeoff. Finance gets actual cost attribution to every demand source without requiring discrete procurement and production per contract. The result is more defensible cost reporting, faster revenue recognition, and real-time insight into which parts of the program are driving cost performance.
No program runs perfectly. Material is scrapped. Quantities arrive that exceed what was needed. Inventory counts reveal losses. Supply falls short of demand. PMMO provides a structured exception management framework for each of these scenarios, but the framework must be configured correctly and monitored actively. Unresolved exception balances are one of the most common sources of cost reporting anomalies in PMMO-managed programs.
| Exception Type | Trigger Scenario | System Behavior | Resolution Path |
|---|---|---|---|
| Excess | More supply is available at the grouping WBS than can be pegged to existing demand. Common in programs where schedules slip but procurement has already delivered. | Costs that cannot be assigned to an operative WBS element are routed to the Excess exception WBS element during the pegging and distribution run. | Manually reassign pegging in PMMO_PEGGING to redirect excess to an appropriate operative WBS, or assign to future demand if additional units are planned. If truly excess, manage through a surplus/disposition process. |
| Scrap | Material from grouped project stock is scrapped (movement type 551/Q). The scrapped quantity and its associated cost no longer represent value deliverable to any demand source. | Scrap costs post to the Scrap exception WBS. The scrapped quantity is removed from PMMO_STOCK and PMMO_CONSUMPTION records. | Review whether scrap is contractually recoverable. If billable (e.g., T&M contract), move costs to the appropriate operative WBS. If not recoverable, close out the scrap exception WBS balance at period-end settlement. |
| Loss | Physical inventory differences identified through cycle count or annual physical inventory (movement type 701/Q). Material that should be in project stock is not physically present. | Cost of the inventory difference posts to the Loss exception WBS. PMMO_STOCK is updated to reflect the corrected quantity. | Investigate root cause. If recoverable from a supplier or subcontractor, reverse and repost after recovery. If unrecoverable, determine contractual treatment and settle the exception WBS accordingly. |
| Underpeg | PMMO cannot find sufficient supply to peg against all demands. Costs have posted to the grouping WBS element but cannot be distributed to operative WBS elements because the pegging assignment is incomplete. | Undistributed costs accumulate on the grouping WBS element. PMMO_DISTR_BALCHK identifies and reports these balances. Costs flow to Underpeg exception WBS where the system cannot self-resolve. | Investigate the pegging gap: missing purchase orders, production orders not yet confirmed, or manual pegging adjustments needed. The 2023 S/4HANA release added the ability to restore pegging assignments from history, enabling faster correction without manual reconstruction. |
Exception WBS balances should be reviewed and resolved as part of every period-end close cycle. Unresolved balances that carry forward compound in subsequent periods and make root cause analysis progressively harder. Configure tolerance thresholds in PMMO_DISTR_BALCHK to automatically flag material exception balances before the distribution run completes, so the close team can address issues before they roll forward.
PMMO is a sophisticated tool, and its power comes with genuine constraints. Understanding these limitations in advance is not a reason to avoid PMMO; it is a prerequisite for designing an implementation that works in production. Organizations that discover these constraints at go-live rather than during design typically spend months resolving them through costly workarounds or process exceptions.
Supported and Unsupported Movements
PMMO only supports goods movements that can be configured through standard Materials Management. Key supported movement types include: 101/Q (GR to project stock), 221/Q and 222/Q (GI/reversal for project), 261/Q and 262/Q (GI/reversal from project stock to order), 309/Q (material-to-material transfer), 411/Q and 412/Q (transfer between project and company stock), 415/Q (transfer to project stock from other segments), 551/Q (scrap), and 701/Q (physical inventory difference).
Stock transfers between grouping WBS elements and individual operative WBS elements in either direction are not supported without explicit design. Such movements risk creating residual costs on grouping WBS elements that distribution cannot resolve.
Negative stock quantities are not supported. Processes that would result in negative project stock require process redesign before PMMO go-live.
RTV Requires Original Document References
Returning material from project stock to a vendor requires identification of the original Purchase Order number, line item, and Goods Receipt document number. This is because project stock is tracked with specific PO references and the return must reverse a specific GR, not a generic stock position.
In high-volume environments or when time has elapsed since original receipt, locating the correct GR reference is operationally burdensome and error-prone.
A practical solution is to build a system automation that programmatically identifies and presents the appropriate GR document when a user initiates a return, eliminating the need for manual document lookup. This is a moderate-complexity ABAP or BTP enhancement that pays for itself quickly in environments with regular supplier returns.
Project Stock and MRP Reorder Logic
This is technically a limitation of project stock (special stock Q) rather than PMMO specifically, but it has direct operational impact on PMMO implementations.
Standard MRP reorder point and forecast-based replenishment strategies do not natively account for project stock quantities returned from production or transferred between projects. MRP "sees" the return as a supply, but the planning logic may not correctly incorporate it into future demand netting for project stock segments.
The standard resolution is to develop a custom algorithm that generates Planned Independent Requirements (PIRs) for materials that need replenishment, effectively creating a demand signal that MRP can plan against in the project stock context. This is a common enhancement in mature PMMO implementations and is well-understood from a technical standpoint.
Single Company Code Boundary
PMMO does not support cross-company-code grouping. Both the grouping WBS element and all assigned operative WBS elements must reside within the same company code. This is a hard architectural constraint, not a configuration option.
In multi-entity defense contractors or commercial manufacturers with manufacturing subsidiaries, intercompany transfer pricing creates a fundamental conflict with PMMO's actual-cost distribution model. Transfer prices between entities are established prices, not actual costs, and PMMO cannot distribute across the company code boundary.
Addressing this requires explicit intercompany design work before PMMO go-live: determining which entities participate in PMMO, how intercompany transactions are represented in the WBS structure, and where transfer pricing adjustments occur relative to the PMMO distribution boundary. This design should be treated as a hard dependency, not an item to be resolved post-implementation.
Delivery costs (freight, handling) for stock transfers between plants are also not supported by PMMO and require separate handling.
Where Custom Development Adds Value
While PMMO has its deepest roots in Aerospace & Defense, its applicability to commercial discrete manufacturing environments is increasingly recognized. SAP's deliberate move from GPD as an IS-A&D add-on to PMMO as a broadly available S/4HANA capability reflects a recognition that the cost traceability and demand-driven costing problems PMMO solves are not unique to defense. Any manufacturer that produces against projects, contracts, or customer orders at a meaningful scale has something to gain from PMMO's architecture.
The dominant cost accounting model in commercial manufacturing has historically been standard costing. Standards are set once per period (or annually), procurement and production costs are absorbed at standard, and variances are analyzed in aggregate. This model works when production is highly repetitive, BOM structures are stable, and material prices are predictable. It works less well when any of those conditions break down, which describes the reality facing most commercial manufacturers today: volatile input costs, supply chain disruptions, and increasing product customization.
A commercial manufacturer is a strong candidate for PMMO if: (1) production is organized around customer orders, projects, or contracts rather than anonymous stock replenishment; (2) product customization or configuration variation makes standard costing imprecise; (3) contract profitability is a key management metric; or (4) the organization is moving to S/4HANA and has the opportunity to adopt PMMO without a legacy GPD migration burden. For manufacturers meeting two or more of these criteria, PMMO deserves serious evaluation alongside the standard costing and Material Ledger options.