BPGE table — Overall Values for CO/PS Planning and Budgeting
BPGE stores overall-value totals for Controlling, Project System, Investment Management, and related planning or budgeting objects. The meaning of a row depends on object number, value type, version, currency type, and business process. SAP documentation describes BPGE as the totals table for overall values; it is not specifically a PS cost-planning total per cost element.
BPGE is the totals table underneath PS cost planning documents (Easy Cost Planning and detailed cost element planning), sitting alongside the annual values table BPJA and the period values table BPPE. It is read when a consultant needs to reconcile a planning document total against what shows up in the project's cost report, or to check whether a plan value was posted at all.
Published 20 Sept 2026· 946 words
What it stores
Each record in BPGE represents the total planned amount for one cost element on one object (a WBS element or network activity, identified by object number) within one cost planning document, for one plan version and one value type, summed across the entire planning horizon of that document. It is the aggregate counterpart to BPJA (which splits the same total by fiscal year) and BPPE (which splits it further by period). BPGE does not itself carry any time dimension: if the total in BPGE does not match the sum of the corresponding rows in BPJA, the planning document is internally inconsistent, which normally only happens after a failed mass change, an aborted BAPI call, or a direct table manipulation outside the standard planning transactions.
Key fields
- OBJNR — generic CO, PS, or IM object number.
- WRTTP — value type that determines whether the row represents budget, plan, or another category.
- VERSN — version or planning context.
- Currency and value fields — overall totals in the supported currency types.
- BPJA and BPPE — annual and period-value counterparts for the same value model.
How it joins the data model
- BPGE-POSNR = PRPS-PSPNR to resolve the object number into a WBS element
- BPGE-PLNUM joins to the planning document header table that carries project number, status and creator
- BPGE-PLNUM = BPJA-PLNUM to reconcile the total against the year-by-year breakdown of the same document
- BPGE-POSNR relates through PRPS-PBUKR and PRPS-PSPHI back to PROJ for the project definition and controlling area
- BPGE-KSTAR compares against COSPD or actual cost totals when checking plan against actual for the same object and cost element
How to read it safely
Always restrict by MANDT, PLNUM and POSNR before pulling from BPGE; the table can hold a large number of rows once a project has been re-planned repeatedly across versions and value types, and an unrestricted select by cost element alone returns rows from unrelated projects. VERSN is easy to forget and produces silent mismatches: a plan value looks missing when it is simply sitting under a different version than the one the report is filtering on. WRTTP is the field that separates genuine plan values from commitment-style rows, so a query that ignores it can double count.
How to prove it in the data
A planner reports that a cost planning document total shown in the project report does not match what was entered on screen. Select BPGE by PLNUM, restrict to the relevant POSNR and VERSN, and sum WKGBTR across KSTAR and WRTTP. Compare that figure against the same restriction on BPJA summed across all fiscal years. If the BPGE total and the BPJA sum disagree, the document is internally broken and needs regeneration through the planning transaction rather than a manual correction.
ECC vs S/4HANA
BPGE continues to be used for overall planning and budget values in supported CO, PS, and IM scenarios. SAP documentation pairs BPGE with BPJA annual values and BPPE period values. Interpret WRTTP or value type and object context before calling a value budget or plan.
Common pitfalls
- Treating BPGE as a live, always-current total is wrong when a background job or BAPI has updated BPJA or BPPE but the aggregate in BPGE was not refreshed; the standard planning transactions keep the two in sync, but direct updates outside them do not.
- Comparing BPGE across different VERSN values and concluding a plan was lost, when in fact it sits in a copy version created by a version copy step and was never meant to appear in the version being checked.
- Ignoring WRTTP and summing every row for a cost element, which mixes plan and non-plan value types and inflates the reported total.
- Assuming a zero or missing row in BPGE means no cost was ever planned for that cost element, when the plan may exist in a different planning document (a different PLNUM) tied to a superseded revision of the WBS element.
- Trying to fix a mismatched total by editing WKGBTR directly; this desynchronises BPGE from BPJA and BPPE and produces a document that the standard planning transaction can no longer open cleanly.
- Forgetting that POSNR is a generic object number shared across WBS elements and network activities, and joining to PRPS without checking the object type first, which silently drops network-related rows.
Whose problem this is
A mismatch between BPGE and the reported plan total is a Project System functional consultant question first, since it usually traces back to how the cost planning document was created, versioned or mass-changed. It becomes a technical question only when a custom program or interface has written to the planning tables directly, at which point the developer who built that interface owns the fix.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/bpgeERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.