Project Budgeting and Availability Control
Control project spending by separating planned costs from formally approved budget and using availability control to compare actual plus commitments against budget tolerances.
Explanation
📌 KEY POINTS
✅ Cost plan (estimate) is not Budget (approved spending authority) — keep them separate.
⚠️ Commitments (POs/PRs) reduce available budget BEFORE the invoice posts — this prevents a false "budget is fine" read.
💡 Control-object granularity is a governance choice, not a technical default.
━━━━━━━━━━━━━━━━━━━━
▶ 1. PLAN VS. BUDGET
- Cost planning = estimated expenditure
- Budget = formally approved spending authority
- A project can have a cost plan without spending authority, or an approved budget that differs from the latest forecast
━━━━━━━━━━━━━━━━━━━━
▶ 2. BUDGET MOVEMENT
- Distributed through the WBS hierarchy
- Adjusted through approved supplements, returns, or transfers per policy
- Availability Control checks consumption against budget, issuing warnings/errors at configured tolerance thresholds
━━━━━━━━━━━━━━━━━━━━
⚠️ 3. WHAT COUNTS AS CONSUMPTION
- Normally actual costs AND commitments relevant to the budget-control design
- A PR or PO reduces available budget before an invoice posts — prevents "budget is fine because actual cost is low" surprises
━━━━━━━━━━━━━━━━━━━━
▶ 4. THE GOVERNANCE TRADE-OFF
- Blocking every low-level WBS creates excessive administration
- Controlling only at a high level can hide overspend in critical work packages
- Tolerance profiles and control objects must match actual governance intent, and period-end change control should reconcile budget, commitments, actuals, and forecast
✅ CHECKPOINT: explain why a PO can reduce "available budget" before any invoice exists.
Real project scenario
A project manager saw only 70% actual spend and raised new POs, but existing commitments already consumed almost all remaining budget. Availability control correctly blocked the new commitment before overspend occurred.
Common mistakes
- Treating cost plan as budget.
- Ignoring commitments.
- Setting tolerances with no business owner.
- Budgeting every WBS without need.
- Bypassing AVC instead of resolving budget governance.
Best practices
- Define budget-control level deliberately.
- Monitor commitments.
- Govern supplements/transfers.
- Test warning/error thresholds.
- Reconcile budget to forecast and actuals.
Interview angle
Explain plan versus budget and how availability control uses commitments and actuals.
Practice this lesson
Quick check
1. Scenario — A project manager saw only 70% actual spend and raised new POs, but existing commitments already consumed almost all remaining budget. For the lesson "Project Budgeting and Availability Control", which response shows the strongest architecture and production judgment?
2. In an Availability Control report for a WBS element, how is the 'available budget' value typically calculated?
3. What is the main function of Availability Control (AVAC) in SAP Project System budgeting?
Interview questions
1. You are the senior consultant/architect responsible for Project Budgeting and Availability Control. The project situation is: A project manager saw only 70% actual spend and raised new POs, but existing commitments already consumed almost all remaining budget. How would you assess the design, identify the highest-risk failure modes, and define the evidence required before approving it for production?
Answer it in your own words first, then compare.
2. A project manager observes that while their project's actual costs are well below the approved budget, the system is blocking the creation of new purchase requisitions with a budget exceeded error. Explain the likely cause of this situation in SAP Project System and the key functionality involved.
Answer it in your own words first, then compare.
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.