What is PMMO? Grouping, Pegging & Distribution
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.
The Three Pillars: Grouping, Pegging & Distribution
From GPD to PMMO: What Changed
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.
SAP PS, Plant Structures & Project Stock
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.
Grouping WBS Elements
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:
Exception WBS Elements
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.
Project Stock as a Unique Inventory Segment
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:
- Inventory segregation is automatic: Material received against a grouping WBS element's purchase order goes into that group's stock segment. It cannot be consumed against a different group without an explicit transfer posting.
- Costs are demand-driven, not period-average: With non-valuated project stock, costs post at their actual transactional values directly to the WBS element at time of receipt or production confirmation, not at a period-weighted average standard cost. In reality, with Valuated Project Stock Inventory that is not valued using Standard Costing, the cost is in actuality Moving Average. Example: if there are 2 project stock POs for the same part number with the same WBS but with 2 different prices, the system will calculate a MAP for the stock on the WBS as Moving Average. This is done in table QBEW, which is the project stock equivalent of MBEW for plant stock. The goods issue of the material from Project Stock inventory would be at MAP in this scenario.
- MRP planning is group-specific: MRP runs independently for each grouping WBS element. Requirements from all assigned operative WBS elements are aggregated at the group level, and planned orders/purchase requisitions are created account-assigned to the grouping WBS element.
- Actual costs trace to every BOM level: Because procurement and production orders at every level of a multi-level BOM are account-assigned to grouping WBS elements, PMMO provides a continuous cost trace from raw material purchase through finished goods delivery to the demand source, with actuals at every step.
Plant Structure Alignment
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.
Cross-Workstream Integration
The PMMO Data Flow
Getting the Design Right: Grouping Strategy Fundamentals
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.
Key Design Dimensions
What Materials Should Be Plant Stock vs. Group-Managed?
- Plant stock candidates: High-volume consumables (fasteners, adhesives, sealants), standard hardware with no contractual attribution requirements, materials where standard cost is close enough to actual, items with very short lead times and frequent reorder cycles.
- Group-managed candidates: Materials that must be billed to a specific customer or contract, materials with regulatory traceability requirements (e.g., AS9100, ITAR), long-lead procurement items where demand consolidation provides significant cost or lead time benefit, materials where actuals deviate meaningfully from standard cost.
- The billing-eligibility test: A practical decision rule is to ask whether the cost of the material can be claimed as earned or billed before it has been issued to a production order or delivered to a customer. If yes, it likely belongs in a group. If not, plant stock may be more appropriate and simpler to manage.
The Grouping Pyramid: A Practical Framework
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.
Pyramid Considerations by Manufacturing Scenario
Breakpoints: Flexible Cost Routing Across Projects
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.
How Breakpoints Work
- Master data location: Breakpoints are stored in table PMMO_PEG_BPT. They can be maintained individually or via Excel upload through transaction PMMO_BREAKPOINT_UPL. A hierarchy flag allows a breakpoint defined at a parent WBS level to cascade down to all subordinate WBS nodes automatically.
- Execution: When PMMO Distribution runs and encounters a pegging assignment that maps to an operative WBS element with a breakpoint, costs are redirected to the breakpoint target instead of posting to the operative WBS element directly.
- Non-valuated project stock only: Breakpoints cannot be used with valuated project stock. Valuated stock with breakpoints produces incorrect reporting figures due to the standard FI value flow. This constraint must be understood before selecting valuated vs. non-valuated stock in the design.
- Multiple target types: A single breakpoint definition can include a target WBS element, a cost center, or a network activity. This allows costs from manufacturing activities to be routed to financial cost objects that represent billing milestones, performance obligations, or overhead pools as needed.
Illustrative Example: Two Projects, One Common Assembly
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 Design Guidance
Finance & Accounting: Why PMMO Changes the Game
Key Financial Benefits
- Procurement and production costs post at actual transaction values directly to WBS elements, not at period-weighted standard costs.
- Finance receives actual unit costs in real time as production completes, not as end-of-period allocations or variance roll-ups.
- Supply chain retains full flexibility to pool procurement and consolidate production runs. Finance does not see these as undifferentiated costs; PMMO disaggregates them per pegging assignment.
- Eliminates the variance noise inherent in standard-cost-based reporting without requiring a full Material Ledger implementation.
- The Order Cost Rollup Fiori report (PMMO_COSTROLLUP, App F6378) shows true actual rolled-up costs at every level of the production order BOM, without requiring a full pegging or distribution run first.
- Finance can see exactly which sub-assembly or purchased component is causing cost overrun, not just that a production order is over budget.
- Logistical delays (a late part, a scrap event, a supplier rework) are immediately visible in the cost rollup and traceable to their impact on the affected contracts.
- Program finance teams can perform cost-to-complete analysis at the component level with actual rather than estimated costs.
- Each unit delivered under a contract has a traceable, system-derived actual cost, built from the individual procurement and production transactions that supported its build.
- Unit cost history is maintained in PMMO tables and available for analytics, parametric cost modeling, and should-cost analysis on future bids.
- Eliminates the reliance on shadow spreadsheet models that finance teams commonly maintain outside of SAP to compute unit actuals.
- Supports discrete variance analysis: planned vs. actual at the unit or lot level, with drill-through to the underlying transactions.
- Through breakpoints, PMMO can route distributed costs directly to WBS elements that represent revenue performance obligations under ASC 606 or IFRS 15.
- Costs are associated with their performance obligation at the time of distribution, not at period-end through manual journal entries or allocation cycles.
- This supports percentage-of-completion revenue recognition with a direct, system-traceable link between cost incurrence and the performance obligation being satisfied.
- Faster and more defensible revenue recognition: the cost data supporting the revenue claim is in the same system and derived from the same transactions, not assembled from separate reports.
- Costs roll up through the WBS hierarchy in a manner consistent with the Earned Value Management structure, supporting BCWP, BCWS, and ACWP calculations at any level of the WBS.
- Actual costs are available at the control account level without manual data pulls or reconciliation from separate systems.
- The Cost Distribution Fiori report (introduced in S/4HANA 2023) enables program finance teams to analyze committed, actual, and vendor down-payment postings by distribution result in one view.
- Distribution balance check (PMMO_DISTR_BALCHK) provides period-end audit capability, with the ability to set tolerance thresholds that gate month-close progression.
Exception Handling: Excess, Scrap, Loss & Underpeg
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.
The Four Exception Categories
| 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. |
Limitations, Drawbacks & How to Address Them
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.
Structural and Movement Type Constraints
- 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.
- 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.
- 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.
- 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.
- Unit and project assignment automation: In programs with frequent contract additions or configuration changes, manually assigning new units and projects to the appropriate grouping WBS elements is operationally unsustainable. A custom automation that reads contract data and applies a business-rules-based assignment logic dramatically reduces setup time and error rate.
- Breakpoint logic automation: Breakpoint master data grows proportionally with the number of units, contracts, and WBS elements in the program. An automation that generates breakpoint records based on the WBS hierarchy and financial project structure eliminates manual maintenance and ensures consistency.
- Distribution scheduling and error handling: While PMMO_DISTRIBUTION is a standard transaction, production environments benefit from a custom scheduler with integrated error handling, retry logic, and alerting. A distribution run that silently fails because of a locked object or a data exception can leave finance with stale cost data for the entire period.
- Period-end validation routines: Automated pre-close validation that checks exception balances, confirms pegging completeness, and validates that distribution results reconcile to the expected cost postings reduces manual period-end work and closes the audit trail on the distribution process.
Additional Documented Restrictions
- Serial numbers ignored: Serial number information in stock and goods movements is ignored by PMMO. Unit-effective tracking at the serial number level requires supplementary logic outside of PMMO's native pegging and distribution.
- Material interchangeability not supported: Form/fit/function substitutions at the material master level are not automatically recognized by PMMO. If a substitute material is used, it must be explicitly managed through a design change or manual pegging adjustment.
- Effectivity not natively supported: Engineering effectivity (which BOM configuration applies to which unit) is not a native PMMO concept. Unit-effective grouping strategies must be implemented through WBS structure design rather than through an effectivity date mechanism.
- Production order settlement restriction: Production orders account-assigned to grouping WBS elements must never be settled via standard CO88/KO88 transaction. Doing so causes a double-posting of costs and creates negative balances on the WBS element that are extremely difficult to correct after the fact.
PMMO in Commercial Manufacturing
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.
Actual Cost vs. Standard Cost: The Commercial Case
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.
Implications for Planning and Analytics
- Better standards from actuals: Actual cost data accumulated through PMMO provides a more precise input for setting future standards. Instead of relying on engineering estimates or prior-year average costs, planners can set standards from observed actuals segmented by product, customer, or configuration, producing more useful variance analysis and more credible bid pricing.
- Discrete margin visibility: Commercial manufacturers with product mix complexity (multiple customers, contract types, or product configurations running through the same production environment) gain per-order or per-customer margin visibility that is not achievable with pooled standard costing.
- Analytics integration: PMMO's native Fiori reporting (Order Cost Rollup, Cost Distribution report) feeds SAP Analytics Cloud (SAC) and embedded HANA analytics without requiring additional ETL layers. Real-time actual cost data becomes available in planning and reporting tools at the same refresh rate as the underlying transactions.
- Reduced period-end effort: Standard cost environments require significant period-end work to allocate variances, revalue inventory, and reconcile management accounts to statutory accounts. PMMO's direct-cost model reduces this work by posting costs to their final destination at transaction time, not as period-end allocations.
- Contract and customer profitability: For commercial manufacturers selling on long-term supply agreements, blanket orders, or project-based contracts, PMMO provides a direct line from procurement and production transactions to the specific contractual obligation being fulfilled, enabling true contract-level profitability reporting without post-hoc cost allocation gymnastics.
